Потенциальные проблемы с использованием адреса "из" и "отправителя"

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

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


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

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

От: "Мэри Смит" <[email protected]>

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

Ответ на: "Мэри Смит" <[email protected]>

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

Отправитель: <[email protected]>

Все работает нормально, но оказывается, что на практике некоторые почтовые клиенты и большинство MTA не уважают заголовок "Reply-To". Из-за этого многие участники отправляют сообщения [email protected] вместо желаемого члена.

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

От: "Мэри Смит" <[email protected]>

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

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

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

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

Ответ 1

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

В итоге мы делаем следующее:

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

From: "Mary Smith" <[email protected]>

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

Sender: <[email protected]>

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

Return Path: "Mary Smith" <[email protected]>

Это позволяет программе, запущенной на [email protected], перехватывать эти автоответчики и перенаправлять их на человека, из которого они первоначально предназначались. Большинство реальных почтовых клиентов будут отвечать на заголовок From:. Я не видел проблем с пользователями Blackberry и другими пользователями на системной учетной записи.

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

Заголовок отправителя добавляет небольшую заметку в клиентах Microsoft Outlook о "On Behalf Of", но это подходит для нашего использования. Не было никаких проблем с 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" <[email protected]>
Reply-To: "Mary Smith" <[email protected]>
Return Path: "Mary Smith" <[email protected]>

ELSE

From: "Mary Smith" <[email protected]>
Sender: <[email protected]>
Return Path: "Mary Smith" <[email protected]>

END