Thu, Oct 02, 2003 at 23:14:43, andyo wrote about "[uanog] Re: PGP-signer and uanog. Ne bejte nogami - po drugomu ne proveriajetsa":
Но по стандарту \r\n. Значит, имеют право. Собственно о каком стандарте идет речь?
RFC2045. (OK, не стандарт. Но спецификация MIME.) (4) (Line Breaks) A line break in a text body, represented as a CRLF sequence in the text canonical form, must be represented by a (RFC 822) line break, which is also a CRLF sequence, in the Quoted-Printable encoding. Далее: In particular, text line breaks must be converted into CRLF sequences prior to base64 encoding.
в неком (причем совершенно неважно каком - за рупь десяток найду) редакторе создается сообщение в котором <ENTER> заменяется не на \r\n а на \n Какой здесь стандарт нарушается? Правильно - никакой - программа имеет право не знать для чего она готовит текст :О)
Перед преобразованием в quoted-printable или base64 разделители строк должны быть представлены как CRLF. Точка. Не имеет значения, какой локальный разделитель, для чего готовиться текст, и вообще какая операционка, кодировка и вообще компьютер ли это. Не имеет значения.
Далее некий мэйлер запускает внешнюю криптографическую программу, которая подписывает тело ничего из него не удаляя. Здесь ничего не нарушается? Правильно - ничего. Более того - если бы подпись предусматривала изменение семантики (а на этом этапе удаление переводов строки было бы именно изменением семантики) - играли бы в разведчиков на каждом шагу. Далее этот мэйлер в соответствии с промышленным стандартом Base64 кодирует сообщение опять же ничего из него не удаляя.
Энди, не морочь голову. KMail НАРУШАЕТ правила кодирования Base64 в письмах. Результат - нечитаемые письма, и мне пофиг, какая тому причина.
Здесь тоже ничего не нарушается
Нет.
- на выходе имеем совершенно корректно кодированный блок. Далее мэйлер снабжает тело хидерами и пуляет его его в цепочку МТА. Я не наблюдаю здесь нарушения стандартов :О)
Сочувствую. Вынужден просить посмотреть снова и снова, пока не увидишь.
C другой стороны я еще не видел ни одного нормального редактора под унихом который бы заменял <ENTER> на \r\n А в SMTP, telnet, POP3, NNTP и прочих разделитель строк - \r\n. И что, требовать от всех поддерживать локальный юниксовый стандарт? Спорный вопрос - с одной стороны когда передается Base64-кодированный блок о \r\n или \n как компонентах тела говорить не приходится - во время транспорта их просто нет. Декодирование и изменение трансфер-инкодинга происходит уже после приема сообщения. С другой стороны хост юникс со своими стандартами старше всех вышеуказанных rfc :О) А если вернуться к теме, я сильно подозреваю, что \n удаляются в такие вот трагические моменты: X-MIME-Autoconverted: from base64 to 8bit by geddar.km.ua id и мне жутко интересно в соответствии с каким стандартом :О)
OK, начни с устранения всех sendmail'ов. Только учти, что этот хоть в случае корректных писем производит правильные конверсии между семи- и восьмибитными CTE, а все эти новомодные хвалёные экзимы, постфиксы и кумылы даже не пытаются сделать это. А на закуску прочитай RFC1847 и его запрет конверсии из QP или B64 для multipart/encrypted и multipart/signed. -netch- =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message