Лучшие практики? Отправить почту из веб-приложения
У нас есть веб-приложение, которое похоже на приложение CRM. Люди могут войти и управлять своим бизнесом с другими людьми. Как часть этого управления, наше приложение может отправлять электронные письма людям, которым управляют. Проблема заключается в том, что нашим клиентам нравится, чтобы адрес отправителя этих писем был их собственным. Таким образом, получатель получает электронную почту от кого-то, кого он знает, а не от адреса "не отвечать" на нашем собственном домене.
Со многими почтовыми серверами это не проблема, однако есть несколько, которые перенаправляют эти письма. Из любопытства мне отправили тестовое электронное письмо и проверили заголовки. Вот что добавили приложения Google:
Received-SPF: softfail (google.com: best guess record for domain of transitioning client@clientdomain.com does not designate 99.99.184.164 as permitted sender) client-ip=99.99.184.164;
Authentication-Results: mx.google.com; spf=softfail (google.com: best guess record for domain of transitioning client@clientdomain.com does not designate 99.99.184.164 as permitted sender) smtp.mail=client@clientdomain.com
(Я заменил реальный адрес "от" на client@clientdomain.com)
Таким образом, хотя письмо было доставлено мне, я могу понять, почему другие серверы могут его отклонить. Наше приложение никогда не будет разрешено на clientdomain.com.
Какие у меня есть варианты?
1) Я мог бы предложить, чтобы все адреса "от" были установлены на понятное имя клиента, но у нас был свой собственный адрес электронной почты "без ответа". Тогда я мог бы получить SPF и все, что связано.
2) Я мог бы предложить, чтобы клиент настраивал spf / reverse dns, чтобы он соответствовал IP-адресу моего сервера (это кажется ужасным вариантом...)
Что-то еще. Каковы лучшие практики для такого рода вещей?
6 ответов
Одна вещь, которую вы можете сделать, это установить "имя" отправителя в качестве имени вашего клиента, а затем установить заголовок Reply-To, чтобы перейти на его адрес электронной почты.
Таким образом, похоже, что они получают электронное письмо от "Боба Джонсона", которого они знают, и когда они нажимают "Ответить", оно будет адресовано bjohnson@clientcompany.com
Хотя я знаю, что такие компании, как Paypal, могут получать электронные письма с вашего фактического адреса электронной почты, я не уверен, что это обман с заголовками или что все провайдеры электронной почты "доверяют" почтовым серверам PayPal.
Все ключи SPF/ домена работают с адресами конверта "От", а не с адреса "От" в электронном письме, увиденном получателем.
Поэтому вы можете просто использовать Envelope From в качестве действительного идентификатора электронной почты в своем домене и оставить From в качестве идентификатора электронной почты своего клиента.
Таким образом, ключи SPF/ домена все равно будут проходить.
Что касается других лучших практик, ознакомьтесь с этим тестом почтового сервера.
См. http://www.openspf.org/Best_Practices/Webgenerated
egreetings.com делает это следующим образом:
Выберите общий адрес в своем домене (service@egreetings.com).
Измените "ПОЧТА ОТ" на этот адрес.
Добавьте заголовок "Отправитель", чтобы показать получателю, отправившему сообщение. "Отправитель" - стандартное поле; см. RFC 5322.evite.com делает это следующим образом:
Выберите общий адрес в своем домене (info@evite.com).
Измените "ПОЧТА ОТ" на этот адрес.
Измените заголовок "От" на этот адрес.
Добавьте заголовок "Ответить", который содержит адрес электронной почты вашего пользователя.
Как я понимаю, по крайней мере для SPF они должны добавить ваш почтовый сервер в список разрешенных серверов.
В этом весь смысл того, что владелец foo.com говорит, что вы являетесь авторизованным почтовым сервером для foo.com.
Вам не нужно иметь обратный DNS к их почтовому серверу, но ваш почтовый сервер должен HELO правильно, и этот обратный DNS должен быть правильным. Так что HELO приемлемо как bar.com, имеет реверс bar.com и отправляет почту для foo.com, если SPF foo.com разрешает bar.com в качестве реле.
SPF и DomainKeys предназначены для того, чтобы предотвратить то, что вы делаете - отправлять почту с использованием адреса, который вам не принадлежит.
Я не верю, что вы многое можете сделать, чтобы обойти это, так как этого не избежать.
Вы можете назначить каждому пользователю локальный адрес электронной почты, который просто перенаправляется в соответствующую учетную запись gmail или другую учетную запись, чтобы ответы работали, и использовать его в качестве адреса отправителя. Это больше работы с вашей стороны.
Кроме того, вы можете использовать заголовок "resent from".
См. http://blogs.crsw.com/mark/archive/2006/07/06/2032.aspx.
Содержимое "MAIL FROM" - это конверт из, и оно используется для проверки SPF. Получатель видит то, что ему дают команда ПОСЛЕ ДАННЫХ.
Они не должны быть одинаковыми.