@node Maillist headers @section Заголовки почтовых рассылок @strong{Reply-To поле} Когда я пишу что-то в рассылку, то поле @strong{Reply-To}, которое создаётся почтовым клиентом содержит обычный адрес с которого я пишу. При публикации письма в рассылку это поле не меняется. БОльшая часть всех людей когда отвечают на мои письма из рассылки, похоже нажимают кнопку "Reply". Безусловно почтовый клиент в качестве получателя имеет адрес не рассылки, а мой личный. Ответа его другие подписчики не увидят. Это безусловно их право и выбор отправлять ответ лично мне, без возможности его обсуждения другими в дальнейшем. Лично я бы мог вручную прописывать в письмах в рассылку поле Reply-To в котором указать её адрес. До этого, когда у меня был Mailman и SmartList я их специально настраивал на принудительную подмену данного поля. Чтобы люди нажимая кнопку ответа писали в рассылку. Однако задумался -- а правильно ли это всё? Должна ли рассылка делать подмену Reply-To? Или это задача отправителя письма? Или вообще не надо? Нашёл такую статью: @url{http://www.unicom.com/pw/reply-to-harmful.html} которая считает подмену Reply-To крайне плохой штукой: @itemize @item Во-первых, она советует всегда следовать принципу минимальных изменений email-заголовков. Собственно это и так понятно и всегда хорошо. Если изменять, то чётко осознаваемый минимум; @item Во-вторых, она говорит что часто Reply-To подменяют чтобы люди при нажатии на кнопку ответа писали сразу же в рассылку (чего я и хотел). Но, здесь же сразу же напоминается и подчёркивается что уже несколько десятилетий даже в самых простых текстовых почтовых клиентах с командной строкой имеется команда "группового" ответа. И ведь верно. В большинстве известных мне клиентах есть команда ответа автору ("r") и отдельно команда группового ответа всем ("g"). Иногда это называется "Reply to all". Даже в графических клиентах это рядом располагающиеся кнопки. Вопрос ответа автору или всем доступно для обсуждения -- вопрос нажатия "r" или "g" (кнопочки чуть левее/правее). @item Учитывая предыдущий пункт, изменение поля Reply-To наоборот уничтожает возможность ответа автору! То есть обычный ответ и групповой приведут к одному и тому же результату -- а это ограничение того чего хотят подписчики рассылок. @item Более того, если Reply-To не совпадает с тем, что находится в @strong{From}, то желаемый адрес ответа пропадёт полностью. Что если отправитель не является как-таковым автором письма? Этого уже никто не узнает, так как Reply-To перетёрто. @end itemize В итоге, подмена Reply-To: @itemize @item нарушает принцип минимального изменения служебной метаинформации; @item абсолютно ничего полезного пользователям не даёт; @item ограничивает свободу выбора получателя ответа; @item ограничивает функционал почтового клиента; @item уничтожает важную информацию, утеря которой возможно приведёт к невозможности нахождения автора; @item нарушает принцип совершения наименьшего количества работы, так как ответ может стать более ёмкой процедурой; @item нарушает принцип наименьшего наносимого вреда, так как безвозвратно уничтожается служебная метаинформация. @end itemize @strong{Mail-Followup-To и Mail-Reply-To поля} Но, что же делать когда происходит нажатие кнопки группового ответа? Письмо фактически отправляется и автору и в рассылку. Не каждая почтовая рассылка умеет понимать такие ситуации и избегать отправки письма автору, если оно уже было отправлено сторонним отправителем. То есть, здесь безусловно может "помочь" только программное обеспечение рассылки. Как мне, автору письма в рассылке, сказать что ответ стоит отправлять в неё? Наверное можно Reply-To подправить и указать рассылку. А что если письмо адресовано не только в рассылку, но @strong{To} содержит ещё что-либо, или @strong{Cc} поле не пусто? Как сказать что ответ стоит, при нажатии кнопки группового ответа, отправлять всем, но допустим кроме меня? Если я всё-время буду присутствовать в To/Cc полях, то запросто могут приходить дубляжи сообщений. Даже если я отпишусь от рассылки, то из-за постоянного нажатия группового ответа я всё-равно буду получать сообщения обсуждения. Дубляжи можно "резать" на стороне локального почтового сервера (по идентичным @strong{Message-ID}), но это устранение последствий проблемы, а не корня её. Де-юре решения этой проблемы нет, но де-факто это использование поля @strong{Mail-Followup-To}. Поддержка данного поля должна присутствовать в почтовом клиенте. Его короткое и ясное объяснение есть здесь: @url{http://cr.yp.to/proto/replyto.html}. Поле содержит просто список адресатов кому следует отправить ответ. Если человек подписан на какую-либо рассылку из перечисленных адресов, то в Mail-Followup-To он свой собственный адрес не указывает. Если человек не подписан, то ответ само собой ему однозначно необходимо будет также направить и он себя включит в Mail-Followup-To. Почтовый клиент должен уметь понимать данное поле и создавать соответствующие поля To/Cc при ответе. Соответственно и при ответе в рассылку почтовый клиент может корректно заполнить данное поле. Например Mutt-у можно сказать что данный или данный адрес является рассылкой и он может автоматически генерировать Mail-Followup-To поле. Также Mutt-у можно сказать подписан ли автор на рассылку или нет -- что сыграет роль на его включение в поле. Кроме решения проблемы с групповыми ответами и дубляжом писем, данное поле позволит "увести" обсуждение за пределы какой-либо рассылки. Безусловно это поле можно и редактировать и просматривать руками, без поддержки его в клиенте. Кстати состояние его поддержки в различных клиентах имеется здесь: @url{http://www.leptonite.org/mft/software.html}. Кроме того, для "симметричности" ввели ещё одно поле: @strong{Mail-Reply-To}. Оно содержит адрес отправителя. То есть автора. Его поддержка тоже должна иметься в почтовом клиенте. Его роль проста: если рассылка перезаписывает оригинальное Reply-To поле, то его хотя бы можно будет "отыскать" здесь. Mail-Reply-To = Reply-To. Почтовый клиент должен в первую очередь будет посмотреть на Mail-Reply-To, потом уже на Reply-To, ну а потом уже только на From, если ни одного из этих полей нет. Есть доводы против использования данных заголовков, однако лично мне их примеры несостоятельности показались слишком надуманными и в целом всё сводится к тому, что мол все эти RFC относящиеся к почте -- дерьмо и два вышеуказанных заголовка лишь костыли. Безусловно несколько десятилетий назад люди не предполагали насколько email будет использован и как. Но если перейти на IPv6 ещё реально, то сменить SMTP... @copyright{} Сергей Матвеев