Заголовки почтовых рассылок

Reply-To поле

Когда я пишу что-то в рассылку, то поле *Reply-To*, которое
создаётся почтовым клиентом содержит обычный адрес с которого я пишу.
При публикации письма в рассылку это поле не меняется. БОльшая часть
всех людей когда отвечают на мои письма из рассылки, похоже нажимают
кнопку "Reply". Безусловно почтовый клиент в качестве получателя имеет
адрес не рассылки, а мой личный. Ответа его другие подписчики не увидят.

Это безусловно их право и выбор отправлять ответ лично мне, без
возможности его обсуждения другими в дальнейшем. Лично я бы мог вручную
прописывать в письмах в рассылку поле Reply-To в котором указать её
адрес. До этого, когда у меня был Mailman и SmartList я их специально
настраивал на принудительную подмену данного поля. Чтобы люди нажимая
кнопку ответа писали в рассылку.

Однако задумался -- а правильно ли это всё? Должна ли рассылка делать
подмену Reply-To? Или это задача отправителя письма? Или вообще не надо?

Нашёл такую статью:
=> http://www.unicom.com/pw/reply-to-harmful.html
которая считает подмену Reply-To крайне плохой штукой:

* Во-первых, она советует всегда следовать принципу минимальных изменений
  email-заголовков. Собственно это и так понятно и всегда хорошо. Если
  изменять, то чётко осознаваемый минимум;
* Во-вторых, она говорит что часто Reply-To подменяют чтобы люди при нажатии на
  кнопку ответа писали сразу же в рассылку (чего я и хотел). Но, здесь же сразу
  же напоминается и подчёркивается что уже несколько десятилетий даже в самых
  простых текстовых почтовых клиентах с командной строкой имеется команда
  "группового" ответа. И ведь верно. В большинстве известных мне клиентах есть
  команда ответа автору ("r") и отдельно команда группового ответа всем ("g").
  Иногда это называется "Reply to all". Даже в графических клиентах это рядом
  располагающиеся кнопки. Вопрос ответа автору или всем доступно для обсуждения
  -- вопрос нажатия "r" или "g" (кнопочки чуть левее/правее).
* Учитывая предыдущий пункт, изменение поля Reply-To наоборот уничтожает
  возможность ответа автору! То есть обычный ответ и групповой приведут к
  одному и тому же результату -- а это ограничение того чего хотят подписчики
  рассылок.
* Более того, если Reply-To не совпадает с тем, что находится в *From*, то
  желаемый адрес ответа пропадёт полностью. Что если отправитель не является
  как-таковым автором письма? Этого уже никто не узнает, так как Reply-To
  перетёрто.

В итоге, подмена Reply-To:

* нарушает принцип минимального изменения служебной метаинформации;
* абсолютно ничего полезного пользователям не даёт;
* ограничивает свободу выбора получателя ответа;
* ограничивает функционал почтового клиента;
* уничтожает важную информацию, утеря которой возможно приведёт к невозможности
  нахождения автора;
* нарушает принцип совершения наименьшего количества работы, так как ответ
  может стать более ёмкой процедурой;
* нарушает принцип наименьшего наносимого вреда, так как безвозвратно
  уничтожается служебная метаинформация.

Mail-Followup-To и Mail-Reply-To поля

Но, что же делать когда происходит нажатие кнопки группового ответа?
Письмо фактически отправляется и автору и в рассылку. Не каждая почтовая
рассылка умеет понимать такие ситуации и избегать отправки письма
автору, если оно уже было отправлено сторонним отправителем. То есть,
здесь безусловно может "помочь" только программное обеспечение рассылки.

Как мне, автору письма в рассылке, сказать что ответ стоит отправлять в
неё? Наверное можно Reply-To подправить и указать рассылку. А что если
письмо адресовано не только в рассылку, но *To* содержит ещё что-либо,
или *Cc* поле не пусто? Как сказать что ответ стоит, при нажатии кнопки
группового ответа, отправлять всем, но допустим кроме меня?

Если я всё-время буду присутствовать в To/Cc полях, то запросто могут
приходить дубляжи сообщений. Даже если я отпишусь от рассылки, то из-за
постоянного нажатия группового ответа я всё равно буду получать
сообщения обсуждения. Дубляжи можно "резать" на стороне локального
почтового сервера (по идентичным *Message-ID*), но это устранение
последствий проблемы, а не корня её.

Де-юре решения этой проблемы нет, но де-факто это использование поля
*Mail-Followup-To*. Поддержка данного поля должна присутствовать
в почтовом клиенте. Его короткое и ясное объяснение есть здесь:
=> http://cr.yp.to/proto/replyto.html

Поле содержит просто список адресатов кому следует отправить ответ. Если
человек подписан на какую-либо рассылку из перечисленных адресов, то в
Mail-Followup-To он свой собственный адрес не указывает. Если человек не
подписан, то ответ само собой ему однозначно необходимо будет также
направить и он себя включит в Mail-Followup-To.

Почтовый клиент должен уметь понимать данное поле и создавать
соответствующие поля To/Cc при ответе. Соответственно и при ответе в
рассылку почтовый клиент может корректно заполнить данное поле. Например
Mutt-у можно сказать что данный или данный адрес является рассылкой и он
может автоматически генерировать Mail-Followup-To поле. Также Mutt-у
можно сказать подписан ли автор на рассылку или нет -- что сыграет роль
на его включение в поле.

Кроме решения проблемы с групповыми ответами и дубляжом писем, данное
поле позволит "увести" обсуждение за пределы какой-либо рассылки.
Безусловно это поле можно и редактировать и просматривать руками, без
поддержки его в клиенте.

Кроме того, для "симметричности" ввели ещё одно поле: *Mail-Reply-To*.
Оно содержит адрес отправителя. То есть автора. Его поддержка тоже
должна иметься в почтовом клиенте. Его роль проста: если рассылка
перезаписывает оригинальное Reply-To поле, то его хотя бы можно будет
"отыскать" здесь. Mail-Reply-To = Reply-To. Почтовый клиент должен в
первую очередь будет посмотреть на Mail-Reply-To, потом уже на Reply-To,
ну а потом уже только на From, если ни одного из этих полей нет.

Есть доводы против использования данных заголовков, однако лично мне их
примеры несостоятельности показались слишком надуманными и в целом всё
сводится к тому, что мол все эти RFC относящиеся к почте -- дерьмо и два
вышеуказанных заголовка лишь костыли. Безусловно несколько десятилетий
назад люди не предполагали насколько email будет использован и как. Но
если перейти на IPv6 ещё реально, то сменить SMTP...

© Сергей Матвеев