Основной компонент нашего приложения отправляет электронное письмо участникам от имени других участников. В настоящее время мы устанавливаем адрес «От» для нашего системного адреса и используем заголовок «Ответить» с адресом участника. Проблема в том, что ответы от некоторых почтовых клиентов (и автоответы / откаты) не учитывают заголовок «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, даже если указан путь возврата.