У нас есть веб-приложение, похожее на приложение 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-адресом моего сервера (это кажется ужасным вариантом ...)
Что еще. Каковы лучшие практики для такого рода вещей?
Все ключи SPF / Domain работают с адресами Envelope From, а не с адресом From в электронном письме, которое видит получатель.
Таким образом, вы можете просто использовать Envelope From в качестве действительного идентификатора электронной почты в своем домене и оставить From в качестве идентификатора электронной почты вашего клиента.
Таким образом, ключи SPF / домена все равно будут проходить.
Что касается других лучших практик, ознакомьтесь с этим Тест почтового сервера.
Видеть http://www.openspf.org/Best_Practices/Webgenerated
egreetings.com делает это следующим образом:
Выберите общий адрес в своем домене (service@egreetings.com).
Измените «ПОЧТА ОТ» на этот адрес.
Добавьте заголовок «Отправитель», чтобы показать получателю, который отправил сообщение. «Отправитель» - стандартное поле; см. RFC 5322.evite.com делает это следующим образом:
Выберите общий адрес в своем домене (info@evite.com).
Измените «ПОЧТА ОТ» на этот адрес.
Измените заголовок «От» на этот адрес.
Добавьте заголовок «Reply-To», содержащий адрес электронной почты вашего пользователя.
Одна вещь, которую вы можете сделать, - это установить «имя» отправителя в качестве имени вашего клиента, а затем установить заголовок Reply-To для перехода на его адрес электронной почты.
Таким образом, создается впечатление, что они получают электронное письмо от знакомого им "Боба Джонсона", и когда они нажимают "Ответить", оно будет отправлено на bjohnson@clientcompany.com.
Хотя я знаю, что такие компании, как Paypal, могут получать электронные письма с вашего реального адреса электронной почты, я не уверен, что это обман с заголовками или все провайдеры электронной почты «доверяют» почтовым серверам PayPal.
SPF и DomainKeys предназначены только для предотвращения того, что вы делаете - отправки почты с адреса, который вам не принадлежит.
Я не верю, что вы можете многое сделать, чтобы обойти это, поскольку это не предназначено для того, чтобы обойти это стороной.
Вы можете дать каждому пользователю локальный адрес электронной почты, который будет просто перенаправлять на соответствующую учетную запись Gmail или другую учетную запись, чтобы ответы работали, и использовать его как адрес отправителя. С вашей стороны больше работы.
Кроме того, вы можете использовать заголовок «повторно отправлено из».
Я так понимаю хотя бы для SPF нужно добавить свой почтовый сервер в список разрешенных серверов.
Все дело в том, что владелец foo.com утверждает, что вы являетесь авторизованным почтовым сервером для foo.com.
Вам не нужно иметь обратный DNS для их почтового сервера, но ваш почтовый сервер должен правильно HELO и этот обратный DNS должен быть правильным. Таким образом, HELO можно использовать как bar.com, иметь обратную сторону bar.com и отправлять почту на foo.com, если SPF foo.com разрешает bar.com в качестве ретранслятора.
Видеть http://blogs.crsw.com/mark/archive/2006/07/06/2032.aspx.
Содержимое «MAIL FROM» - это конверт из, и он используется для проверки SPF. Получатель видит то, что дается команде ПОСЛЕ ДАННЫХ.
Они не обязательно должны быть одинаковыми.