maillist_headers.texi

   1 @node Maillist headers
   2 @section Заголовки почтовых рассылок
   3
   4 @strong{Reply-To поле}
   5
   6 Когда я пишу что-то в рассылку, то поле @strong{Reply-To}, которое
   7 создаётся почтовым клиентом содержит обычный адрес с которого я пишу.
   8 При публикации письма в рассылку это поле не меняется. БОльшая часть
   9 всех людей когда отвечают на мои письма из рассылки, похоже нажимают
  10 кнопку "Reply". Безусловно почтовый клиент в качестве получателя имеет
  11 адрес не рассылки, а мой личный. Ответа его другие подписчики не увидят.
  12
  13 Это безусловно их право и выбор отправлять ответ лично мне, без
  14 возможности его обсуждения другими в дальнейшем. Лично я бы мог вручную
  15 прописывать в письмах в рассылку поле Reply-To в котором указать её
  16 адрес. До этого, когда у меня был Mailman и SmartList я их специально
  17 настраивал на принудительную подмену данного поля. Чтобы люди нажимая
  18 кнопку ответа писали в рассылку.
  19
  20 Однако задумался -- а правильно ли это всё? Должна ли рассылка делать
  21 подмену Reply-To? Или это задача отправителя письма? Или вообще не надо?
  22
  23 Нашёл такую статью: @url{http://www.unicom.com/pw/reply-to-harmful.html}
  24 которая считает подмену Reply-To крайне плохой штукой:
  25
  26 @itemize
  27 @item
  28 Во-первых, она советует всегда следовать принципу минимальных
  29 изменений email-заголовков. Собственно это и так понятно и всегда
  30 хорошо. Если изменять, то чётко осознаваемый минимум;
  31 @item
  32 Во-вторых, она говорит что часто Reply-To подменяют чтобы люди при
  33 нажатии на кнопку ответа писали сразу же в рассылку (чего я и хотел).
  34 Но, здесь же сразу же напоминается и подчёркивается что уже несколько
  35 десятилетий даже в самых простых текстовых почтовых клиентах с
  36 командной строкой имеется команда "группового" ответа. И ведь верно. В
  37 большинстве известных мне клиентах есть команда ответа автору ("r") и
  38 отдельно команда группового ответа всем ("g"). Иногда это называется
  39 "Reply to all". Даже в графических клиентах это рядом располагающиеся
  40 кнопки. Вопрос ответа автору или всем доступно для обсуждения -- вопрос
  41 нажатия "r" или "g" (кнопочки чуть левее/правее).
  42 @item
  43 Учитывая предыдущий пункт, изменение поля Reply-To наоборот уничтожает
  44 возможность ответа автору! То есть обычный ответ и групповой приведут
  45 к одному и тому же результату -- а это ограничение того чего хотят
  46 подписчики рассылок.
  47 @item
  48 Более того, если Reply-To не совпадает с тем, что находится в
  49 @strong{From}, то желаемый адрес ответа пропадёт полностью. Что если
  50 отправитель не является как-таковым автором письма? Этого уже никто не
  51 узнает, так как Reply-To перетёрто.
  52 @end itemize
  53
  54 В итоге, подмена Reply-To:
  55
  56 @itemize
  57 @item нарушает принцип минимального изменения служебной метаинформации;
  58 @item абсолютно ничего полезного пользователям не даёт;
  59 @item ограничивает свободу выбора получателя ответа;
  60 @item ограничивает функционал почтового клиента;
  61 @item
  62 уничтожает важную информацию, утеря которой возможно приведёт к
  63 невозможности нахождения автора;
  64 @item
  65 нарушает принцип совершения наименьшего количества работы, так как
  66 ответ может стать более ёмкой процедурой;
  67 @item
  68 нарушает принцип наименьшего наносимого вреда, так как безвозвратно
  69 уничтожается служебная метаинформация.
  70 @end itemize
  71
  72 @strong{Mail-Followup-To и Mail-Reply-To поля}
  73
  74 Но, что же делать когда происходит нажатие кнопки группового ответа?
  75 Письмо фактически отправляется и автору и в рассылку. Не каждая почтовая
  76 рассылка умеет понимать такие ситуации и избегать отправки письма
  77 автору, если оно уже было отправлено сторонним отправителем. То есть,
  78 здесь безусловно может "помочь" только программное обеспечение рассылки.
  79
  80 Как мне, автору письма в рассылке, сказать что ответ стоит отправлять в
  81 неё? Наверное можно Reply-To подправить и указать рассылку. А что если
  82 письмо адресовано не только в рассылку, но @strong{To} содержит ещё что-либо,
  83 или @strong{Cc} поле не пусто? Как сказать что ответ стоит, при нажатии кнопки
  84 группового ответа, отправлять всем, но допустим кроме меня?
  85
  86 Если я всё-время буду присутствовать в To/Cc полях, то запросто могут
  87 приходить дубляжи сообщений. Даже если я отпишусь от рассылки, то из-за
  88 постоянного нажатия группового ответа я всё-равно буду получать
  89 сообщения обсуждения. Дубляжи можно "резать" на стороне локального
  90 почтового сервера (по идентичным @strong{Message-ID}), но это устранение
  91 последствий проблемы, а не корня её.
  92
  93 Де-юре решения этой проблемы нет, но де-факто это использование поля
  94 @strong{Mail-Followup-To}. Поддержка данного поля должна присутствовать
  95 в почтовом клиенте. Его короткое и ясное объяснение есть здесь:
  96 @url{http://cr.yp.to/proto/replyto.html}.
  97
  98 Поле содержит просто список адресатов кому следует отправить ответ. Если
  99 человек подписан на какую-либо рассылку из перечисленных адресов, то в
 100 Mail-Followup-To он свой собственный адрес не указывает. Если человек не
 101 подписан, то ответ само собой ему однозначно необходимо будет также
 102 направить и он себя включит в Mail-Followup-To.
 103
 104 Почтовый клиент должен уметь понимать данное поле и создавать
 105 соответствующие поля To/Cc при ответе. Соответственно и при ответе в
 106 рассылку почтовый клиент может корректно заполнить данное поле. Например
 107 Mutt-у можно сказать что данный или данный адрес является рассылкой и он
 108 может автоматически генерировать Mail-Followup-To поле. Также Mutt-у
 109 можно сказать подписан ли автор на рассылку или нет -- что сыграет роль
 110 на его включение в поле.
 111
 112 Кроме решения проблемы с групповыми ответами и дубляжом писем, данное
 113 поле позволит "увести" обсуждение за пределы какой-либо рассылки.
 114 Безусловно это поле можно и редактировать и просматривать руками, без
 115 поддержки его в клиенте. Кстати состояние его поддержки в различных
 116 клиентах имеется здесь: @url{http://www.leptonite.org/mft/software.html}.
 117
 118 Кроме того, для "симметричности" ввели ещё одно поле: @strong{Mail-Reply-To}.
 119 Оно содержит адрес отправителя. То есть автора. Его поддержка тоже
 120 должна иметься в почтовом клиенте. Его роль проста: если рассылка
 121 перезаписывает оригинальное Reply-To поле, то его хотя бы можно будет
 122 "отыскать" здесь. Mail-Reply-To = Reply-To. Почтовый клиент должен в
 123 первую очередь будет посмотреть на Mail-Reply-To, потом уже на Reply-To,
 124 ну а потом уже только на From, если ни одного из этих полей нет.
 125
 126 Есть доводы против использования данных заголовков, однако лично мне их
 127 примеры несостоятельности показались слишком надуманными и в целом всё
 128 сводится к тому, что мол все эти RFC относящиеся к почте -- дерьмо и два
 129 вышеуказанных заголовка лишь костыли. Безусловно несколько десятилетий
 130 назад люди не предполагали насколько email будет использован и как. Но
 131 если перейти на IPv6 ещё реально, то сменить SMTP...
 132
 133 @copyright{} Сергей Матвеев