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

Question

Eu queria saber a melhor maneira de fazer com que meu servidor de e-mails enviasse e-mails em nome dos domínios dos meus clientes, sem ser cinza e também evitando problemas de devolução.

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

A.

HELO mymailserver.com
MAIL FROM<[email protected]>  # mymailserver.com same IP as myapp.com
DATA
  From: <[email protected]>
  Sender: <[email protected]>

Pergunta : Isso é o que o Gmail faz. É o cabeçalho msg "From:" que tem um domínio diferente, não o remetente do envelope.
emailclients mostrará "De: [email protected] via [email protected]" ou "De: [email protected] Em nome de [email protected]" , que não é um problema para mim.
Agora, isso afetará negativamente a reputação do meu domínio, o fato de o cabeçalho "From:" ter um domínio diferente? (e se não é o Google que está fazendo isso ..)

B.

HELO mymailserver.com
MAIL FROM<[email protected]>
DATA
   From: <[email protected]>
   # same as A, but no "Sender:"

Parece que o Google fez isso e chamou de erro link
Um bug removeu o "Remetente:" de suas mensagens e o "via" não apareceu no emailclient. (O RFC diz que deve estar presente, se não é o mesmo que o "From:")

C.

HELO mymailserver.com
MAIL FROM<[email protected]>
DATA 
  From: <[email protected]>

É 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 em seu DNS, eu teria que alterar seu DNS, permitindo que o mymailserver.com envie uma mensagem em seu nome ... (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 o @ gmail.com por conta própria)

D.

HELO mymailserver.com    
MAIL FROM<[email protected]>
DATA 
  From: <[email protected]>
  Reply-to: <[email protected]>

Pergunta : Este é o mais simples, eu adicionaria apenas um cabeçalho "Responder para:". Isso é realmente levado em conta o tempo todo por clientes de email? Isso pode ser percebido como spoof também, adicionando domínios diferentes ao cabeçalho "Responder a" e tendo uma influência ruim na reputação do meu domínio?
- O RFC diz apenas que "se o campo Reply-To existir, então a resposta DEVE vai para os endereços indicados naquele campo e não para o (s) endereço (s) indicado (s) no campo" De ". ".
- Apenas o rótulo de cabeçalho "De:" seria "falsificado":
"De: myclient.com (via myapp.com) < [email protected]>".

    

Answer 1

Excelente pergunta. Acabei de passar várias horas pesquisando a mesma coisa.

Eu já havia implantado inúmeros sites que usam Opção C para formulários de e-mail (principalmente por ingenuidade), mas estamos enfrentando um número crescente de problemas de exibição. Provedores de e-mail estão gradualmente apertando as coisas. Por exemplo, o Yahoo alterou recentemente sua política DMARC para solicitar que os destinatários rejeitem todos os emails From: [email protected] sem um válido Assinatura DKIM . Receber servidores SMTP que sigam o DMARC (que inclui o Gmail e provavelmente o Hotmail / Outlook.com e o Yahoo) irá ressaltar strongmente essas mensagens. O eBay e o Paypal têm políticas estritas similares, acredito, na tentativa de reduzir o phishing. Infelizmente, especificar um cabeçalho "Remetente" não ajuda.

(Eu me pergunto como o Gmail funciona ao enviar "From" um alias do Yahoo ?!)

A opção A seria uma opção melhor se você souber que o e-mail "De" não possui uma política DMARC rígida (você poderia confirmar isso por meio de uma simples consulta DNS).

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

Para ganhar credibilidade adicional e aumentar as chances de entrega, gostaria de ver a implementação de SPF e / ou DKIM. Essas e outras coisas são mencionadas nas Diretrizes para remetentes em massa do Google , que eu considerado útil.

    

Answer 2

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, adicionaria registros SPF. Mas como eu disse, isso não é mais seguro ou inseguro do que os outros (o que você quer dizer com isso).

O cabeçalho Reply-To não afeta a reputação de nenhuma forma. Apenas aconselha o cliente a usar esse endereço para respostas (Duh, talvez seja de onde vem o nome ?!). Se o cliente segue esta recomendação não é garantida.