Qual é o melhor método para enviar email em nome dos domínios dos meus clientes?


15

Eu queria saber a melhor maneira de fazer meu servidor de e-mail enviar e-mails em nome dos domínios de meus clientes, sem estar na lista de espera e também evitar problemas de rejeição.

Estive lendo algumas outras perguntas aqui , aqui e aqui, mas nenhuma explora todas as soluções possíveis. Aqui estão algumas possibilidades que eu gostaria de comparar:

UMA.

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>

Pergunta : É isso que o Gmail faz. É o cabeçalho da mensagem "De:" que possui um domínio diferente, não o remetente do envelope.
emailclients mostrará "De: res@client.com via do-not-reply@myapp.com" ou "De: do-not-reply@myapp.com Em nome de res@client.com" , o que não é um problema para mim.
Agora, isso afetará muito a reputação do meu domínio, o fato de o cabeçalho "De:" ter um domínio diferente? (e se não é o Google quem está fazendo isso ..)

B.

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

Parece que o Google fez isso uma vez e chamou de erro http://groups.google.com/group/Gmail-Help-Message-Delivery-en/browse_thread/thread/f651cb1db5d9dd23/3a8bcd0548487863?lnk=gst&q=%22on+behalf + of% 22 & pli = 1
Um bug removeu o "Remetente:" de suas mensagens e o "via" não apareceu no cliente de email. (O RFC diz que DEVE estar presente se não for o mesmo que o "De:")

C.

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

É como se o client.com estivesse enviando a mensagem (o MAIL FROM também é "falsificado"). Mas se o domínio client.com for bem conhecido ou tiver uma entrada SPF no DNS, eu precisaria alterá-lo, permitindo que o mymailserver.com envie mensagens em nome deles. (Isso é impossível para mim por causa do nb . de clientes e também alguns dos meus clientes não têm controle sobre seus domínios, ou seja, estão usando @ gmail.com eles mesmos)

D.

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

Pergunta : Este é o mais simples, eu adicionaria apenas um cabeçalho "Responder para:". Isso é realmente levado em consideração o tempo todo pelos clientes de email? Isso também pode ser percebido como falsificação, adicionando domínios diferentes ao cabeçalho "Responder para" e ter uma má influência na reputação do meu domínio?
- O RFC apenas diz que "se o campo Responder para existir, a resposta DEVE ir para os endereços indicados nesse campo e não para os endereços indicados no campo De".
- Somente o rótulo do cabeçalho "De:" seria "falsificado":
"De: myclient.com (via myapp.com) <do-not-reply@myapp.com>".


Ao ler RFC, 'DEVE' significa que é uma recomendação muito forte. A única razão pela qual um cliente não faria na maioria dos casos é porque é antigo e não foi atualizado desde que o RFC foi gravado. Consulte o RFC 2119 para obter as definições padrão: ietf.org/rfc/rfc2119.txt
Matthew Scharley 16/16


Infelizmente, a partir de 2018, muitos clientes de email ainda ignoram o cabeçalho de resposta. meta.discourse.org/t/…
Martin Meixger 12/02/19

Respostas:


2

Excelente pergunta. Passei várias horas pesquisando a mesma coisa.

Eu já havia implantado vários sites que usam a opção C para formulários de email (principalmente por ingenuidade), mas estamos enfrentando um número crescente de problemas de entrega. Os provedores de e-mail estão gradualmente se fortalecendo. Por exemplo, o Yahoo mudou recentemente sua política de DMARC para solicitar que os destinatários rejeitem todos os emails From: ____@yahoo.comsem uma assinatura DKIM válida . O recebimento de servidores SMTP que seguem o DMARC (que inclui o Gmail e provavelmente o Hotmail / Outlook.com e Yahoo) fará com que essas mensagens sejam rejeitadas. O eBay e o Paypal têm políticas rígidas semelhantes, acredito, na tentativa de reduzir o phishing. Infelizmente, especificar um cabeçalho "Remetente" não ajuda.

(Eu me pergunto como o Gmail soluciona isso ao enviar "De" um apelido do Yahoo ?!)

A opção A seria uma opção melhor se você souber que o email "De" não possui uma política rigorosa do DMARC (você pode confirmar isso por meio de uma simples consulta DNS).

Apesar de ser a menos atraente visualmente, a Opção D é realmente a mais segura e é o que eu recomendarei para a maioria dos nossos projetos futuros. É importante notar que o PayPal usado anteriormente Opção A, mas agora mudou para Opção D .

Para ganhar credibilidade adicional e aumentar a chance de entrega, gostaria de implementar o SPF e / ou o DKIM. Essas e outras coisas são mencionadas nas Diretrizes para remetentes em massa do Google, que achei úteis.


1

Não tenho certeza do que você quer. Não existe uma maneira "segura" ou "insegura" de fazer o que você deseja.

Eu sempre preferiria D). Além disso, eu adicionaria registros SPF. Mas como eu disse, isso não é mais seguro do que os outros (o que você quer dizer com isso).

O cabeçalho de resposta a não influencia a reputação de nenhuma maneira. Apenas aconselha o cliente a usar esse endereço para obter respostas (duh, talvez seja daí que o nome vem ?!). Se o cliente seguir esta recomendação, não será garantido.


Por "seguro", quero dizer minimizar as chances de ter meu domínio na lista de espera, considerado por engano como um spoofer / spammer por causa da solução que escolhi. Sim, se eu for com D, posso considerar adicionar uma entrada SPF ao meu domínio e assinar as mensagens usando o DKIM.
dgaspar 17/09/11

Eu editei a minha pergunta e tentou esclarecer isso ..
dgaspar

@dgaspar Greylisting é baseado em envelope. Portanto, seu conteúdo (De :, Remetente :, ...) é totalmente ignorado. Como todos podem escrever qualquer endereço de email como remetente, todo endereço de remetente é considerado falsificado. Exceto que você assina seus e-mails com SPF ou DKIM.
mailq

0

Duas soluções confiáveis:

  1. peça aos clientes para adicionar seu servidor de correio no registro de domínio SPF
  2. solicite aos clientes que forneçam credenciais de uma conta de email (IP do servidor de email, nome de usuário, senha) e use-as dentro do aplicativo para conectar-se ao servidor de email e enviar email (na verdade, você cria um cliente de email dentro do aplicativo).
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.