Потенциальные проблемы с использованием адреса участника "from" и заголовка отправителя - PullRequest
26 голосов
/ 09 февраля 2010

Основной компонент нашего приложения отправляет электронное письмо участникам от имени других участников. В настоящее время мы устанавливаем адрес «От» для нашего системного адреса и используем заголовок «Ответить» с адресом участника. Проблема в том, что ответы от некоторых почтовых клиентов (и автоответы / откаты) не учитывают заголовок «Reply-to», поэтому отправляются на наш системный адрес, фактически отправляя их в черную дыру. Мы рассматриваем возможность установки адреса «От» для адреса нашего участника, а адреса «Отправитель» - для адреса нашей системы. Похоже, что этот путь пройдет проверку SPF и Sender-ID.

Есть ли причины не переходить на этот метод? Есть ли другие потенциальные проблемы?


Вот более подробная информация, чем вам, вероятно, нужно:

Когда приложение было впервые разработано, мы просто изменили адрес «с» на адрес отправителя, поскольку это было обычной практикой в ​​то время (это было много лет назад). Позже мы изменили это, чтобы адрес «от» был именем участника и нашим адресом, то есть

От: "Мэри Смит" <messages@company.example>

С заголовком "reply-to", установленным на адрес участника:

Ответить: "Мэри Смит" <marysmith@memberisp.example>

Это помогло ошибочно классифицировать сообщения как спам. Поскольку SPF стал более популярным, мы добавили дополнительный заголовок, который будет работать вместе с нашими записями SPF:

Отправитель: <messages@company.example>

Все работает хорошо, но оказывается, что на практике некоторые почтовые клиенты и большинство MTA не уважают заголовок «Reply-To». Из-за этого многие участники отправляют сообщения на messages@company.example вместо желаемого участника.

Итак, я начал предусматривать различные схемы добавления данных об отправителе в заголовки электронной почты или их кодирования в адресе электронной почты «от», чтобы мы могли обработать ответ и перенаправить соответствующим образом. Например,

От: "Мэри Смит" <messages+ca54bb7482ace09f@company.example>

где строка после "messages" - это хеш, представляющий члена Мэри Смит в нашей системе. Конечно, этот путь может привести к большим трудностям, так как нам необходимо разработать функциональные возможности MTA для нашего системного адреса. Я снова посмотрел документацию SPF и нашел эту страницу интересной:

http://www.openspf.org/Best_Practices/Webgenerated

Они показывают два примера: evite.com и egreetings.com. По сути, evite.com делает это так, как мы. Пример egreetings.com использует адрес участника с добавленным заголовком «Отправитель».

Итак, вопрос в том, есть ли потенциальные проблемы с использованием метода egreetings для адреса участника с адреса с заголовком отправителя? Это исключит ответы, которые плохие клиенты отправляют на системный адрес. Я не верю, что это решает проблему отказов / отпуска / белого списка, поскольку они часто отправляются в MAIL FROM, даже если указан путь возврата.

1 Ответ

41 голосов
/ 22 апреля 2010

Поэтому я решил ответить на свой вопрос, так как никто не ответил. Возможно, другие найдут эту запись при поиске.

То, что мы наконец-то делаем, это:

Установите в заголовке From фактический адрес электронной почты пользователя.

From: "Mary Smith" <marysmith@memberisp.example>

Используйте заголовок отправителя с адресом электронной почты всей системы.

Sender: <messages@company.example>

Наконец, фактический отправитель, который отображается в заголовке MAIL FROM / Return Path, указанном на сервере, устанавливается с уникальным идентификатором, т.е.

Return Path: "Mary Smith" <messages+ca54bb7482ace09f@company.example>

Это позволяет программе, работающей по адресу messages@company.example, перехватывать эти автоответы и пересылать их человеку, которому они изначально предназначались. Большинство реальных почтовых клиентов будут отвечать на заголовок From :. Я не видел проблем ни у пользователей ежевики, ни у других, отвечающих на системную учетную запись.

Через месяц или около того у нас было меньше проблем с этим, чем в предыдущем методе, который мы использовали.

В заголовке Sender добавлена ​​небольшая заметка в клиентах Microsoft Outlook о «От имени», но она подходит для нашего использования. С этой настройкой не было проблем с SPF в общих клиентах / mta (Gmail, Yahoo, SpamAssassin и т. Д.)

Обновление: В апреле 2014 года Yahoo и AOL изменили свои настройки DMARC, чтобы отбрасывать подобные сообщения без уведомления. (Они переключились на p = отклонить; см. https://wordtothewise.com/2014/04/brief-dmarc-primer/ для получения дополнительной информации.) Наше решение было для этих особых случаев, поскольку необходимая функциональность по-прежнему работает с подавляющим большинством доменов.

IF ISP MATCHES YAHOO OR AOL

From: "Mary Smith" <messages+ca54bb7482ace09f@company.example>
Reply-To: "Mary Smith" <marysmith@memberisp.example>
Return Path: "Mary Smith" <messages+ca54bb7482ace09f@company.example>

ELSE

From: "Mary Smith" <marysmith@memberisp.example>
Sender: <messages@company.example>
Return Path: "Mary Smith" <messages+ca54bb7482ace09f@company.example>

END
...