Каков наилучший способ отправки электронной почты от имени доменов моих клиентов?


15

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

Я читал некоторые другие вопросы здесь , здесь и здесь, но ни один не рассматривает все возможные решения. Вот некоторые возможности, которые я хотел бы сравнить:

A.

HELO mymailserver.com
MAIL FROM<do-not-reply@myapp.com>  # mymailserver.com same IP as myapp.com
DATA
  From: <res@client.com>
  Sender: <do-not-reply@myapp.com>

Вопрос : это то, что делает Gmail. Это заголовок сообщения «От:» имеет другой домен, а не отправителя конверта.
emailclients будет отображать «От: res@client.com через do-not-reply@myapp.com» или «От: do-not-reply@myapp.com от имени res@client.com» , что не является проблемой для меня.
Теперь, это плохо повлияет на репутацию моего домена, тот факт, что заголовок «От:» имеет другой домен? (и если это не Google, кто делает это ..)

B.

HELO mymailserver.com
MAIL FROM<do-not-reply@myapp.com>
DATA
   From: <res@client.com>
   # same as A, but no "Sender:"

Похоже , что Google когда - то сделал это , и назвал это ошибкой http://groups.google.com/group/Gmail-Help-Message-Delivery-en/browse_thread/thread/f651cb1db5d9dd23/3a8bcd0548487863?lnk=gst&q=%22on+behalf + из% 22 & pli = 1
Ошибка удалила «Отправитель:» из их сообщений, и «через» не появился в почтовом клиенте. (RFC говорит, что он ДОЛЖЕН присутствовать, если он не совпадает с "From:")

C.

HELO mymailserver.com
MAIL FROM<res@client.com>
DATA 
  From: <res@client.com>

Это как если бы client.com отправлял сообщение (MAIL FROM тоже «подделан»). Но если домен client.com хорошо известен или в его DNS есть запись SPF, мне придется изменить его DNS, чтобы mymailserver.com мог отправлять сообщения от их имени. (Это невозможно для меня из-за . клиентов, а также некоторые из моих клиентов не имеют контроля над своими доменами, т. е. используют @ gmail.com сами)

D.

HELO mymailserver.com    
MAIL FROM<do-not-reply@myapp.com>
DATA 
  From: <do-not-reply@myapp.com>
  Reply-to: <res@myclient.com>

Вопрос : Это самый простой, я бы добавил заголовок «Reply-to:». Действительно ли это учитывается ВСЕ ВРЕМЯ почтовыми клиентами? Может ли это быть также воспринято как подделка, добавление разных доменов в заголовок «Ответить» и негативно повлиять на репутацию моего домена?
- RFC только говорит, что «если поле Reply-To существует, то ответ ДОЛЖЕН идти по адресам, указанным в этом поле, а не по адресам, указанным в поле From».
- Только метка заголовка «From:» будет «подделана»:
«From: myclient.com (через myapp.com) <do-not-reply@myapp.com>».


При чтении RFC «СЛЕДУЕТ» означает, что это очень сильная рекомендация. Единственная причина, по которой клиент в большинстве случаев этого не делает, заключается в том, что он старый и не обновлялся с момента написания RFC. См. RFC 2119 для стандартных определений: ietf.org/rfc/rfc2119.txt
Мэтью Шарли,


К сожалению, с 2018 года многие почтовые клиенты по-прежнему игнорируют заголовок Reply-To. meta.discourse.org/t/…
Мартин Мейксгер

Ответы:


2

Отличный вопрос. Я только что провел несколько часов, исследуя одно и то же.

Ранее я развернул множество веб-сайтов, которые используют Вариант C для форм электронной почты (в основном из наивности), но у нас все больше проблем с доставкой. Почтовые провайдеры постепенно сужаются. Например, Yahoo недавно изменила свою политику DMARC, чтобы попросить получателей отклонять все электронные письма From: ____@yahoo.comбез действительной подписи DKIM . Прием SMTP-серверов, которые следуют DMARC (который включает в себя Gmail и, возможно, Hotmail / Outlook.com и Yahoo), будет сильно отклонять эти сообщения. Я полагаю, что eBay и Paypal придерживаются схожих строгих правил, пытаясь уменьшить фишинг. К сожалению, указание заголовка «Отправитель» не помогает.

(Интересно, как работает Gmail при отправке псевдонима Yahoo "From" ?!)

Вариант А будет лучшим вариантом, если вы знаете, что электронная почта «От» не имеет строгой политики DMARC (вы можете подтвердить это с помощью простого запроса DNS).

Несмотря на то, что вариант D выглядит наименее привлекательным, он действительно самый безопасный и я рекомендую для большинства наших будущих проектов. Стоит отметить , что PayPal ранее использовали вариант А, но теперь переключился на Option D .

Чтобы получить дополнительный авторитет и повысить вероятность доставки, я бы посмотрел на реализацию SPF и / или DKIM. Эти и другие вещи упоминаются в Руководстве Google для массовых отправителей, которое я считаю полезным.


1

Я не уверен, что вы хотите. Не существует «безопасного» или «небезопасного» способа делать то, что вы хотите.

Я бы всегда предпочел D). Дополнительно я бы добавил записи SPF. Но, как я уже сказал, это не безопаснее и не безопаснее, чем другие (что бы вы ни имели ввиду).

Заголовок Reply-To никак не влияет на репутацию. Это только советует клиенту использовать этот адрес для ответов (Дух, может быть, отсюда и имя ?!). Если клиент следует этой рекомендации, это не гарантируется.


Под «безопасным» я подразумеваю минимизацию шансов на то, что мой домен будет занесен в серый список, который по ошибке считается спуфером / спамером из-за решения, которое я выбрал. Да, если я использую D, я могу рассмотреть возможность добавления записи SPF в мой домен и подписать сообщения с помощью DKIM.
dgaspar

Я отредактировал свой вопрос и попытался уточнить его ...
dgaspar

@dgaspar Greylisting основан на конвертах. Таким образом, ваш контент (From :, Sender :, ...) полностью игнорируется. Поскольку каждый может написать любой почтовый адрес в качестве отправителя, каждый адрес отправителя считается поддельным. За исключением того, что вы подписываете свои письма с SPF или DKIM.
mailq

0

Два надежных решения:

  1. попросите клиентов добавить ваш почтовый сервер в запись домена SPF
  2. попросите клиентов предоставить вам учетные данные электронной почты (их IP-адрес почтового сервера, имя пользователя, пароль) и использовать их в вашем приложении для подключения к своему почтовому серверу и отправки электронной почты (вы фактически создаете почтовый клиент внутри своего приложения).
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.