Quando um e-mail é rejeitado pelo servidor receptor?

Quando um e-mail é rejeitado pelo servidor receptor?

Atualmente, estou trabalhando em um aplicativo da web e queria criar um formulário da web para permitir que os usuários escrevessem e-mails por meio dele. Assim, eles teriam que definir seu endereço de e-mail e a mensagem e após clicar em “Enviar” meu aplicativo web enviaria o e-mail aos destinatários usando seu endereço de e-mail no FROMcabeçalho. O processo de envio é, obviamente, feito através do meu próprio serviço SMTP porque não tenho acesso aos servidores de e-mail dos visitantes do meu site.

Ouvi dizer que provavelmente é uma má ideia porque esses e-mails provavelmente serão rejeitados pelos servidores dos destinatários. No entanto, ainda não compreendo completamente por que isso acontece e como funciona esse processo. Aprendi que as duas tecnologias anti-spam e de falsificação mais utilizadas atualmente para e-mail sãoDKIMeFPS.

Então, gostaria de entender por que exatamente os e-mails serão rejeitados e como o DKIM/SPF ajudará nisso.

Então, vamos começar com FPS:

Pelo que entendi, o servidor do destinatário verificará os endereços IP que têm permissão para enviar e-mails usando o domínio no MAIL_FROMcabeçalho e o sistema DNS. Agora, com meu exemplo acima, quando envio e-mails no aplicativo da web com o FROMcabeçalho definido como, por exemplo, [email protected](esse é o endereço definido pelo visitante do site), isso (?) não deve afetar o MAIL_FROMcabeçalho. Como o email será enviado através do meu serviço de email, o MAIL_FROMcabeçalho conterá meu domínio e pelo que entendi deverá ser possível enviar o email passando SPF.

A outra tecnologia anti-spam é DKIM:

Ele assinará o e-mail e o servidor destinatário procurará no DNS a chave pública correta para verificar a assinatura. Aqui, não tenho certeza de como isso é feito exatamente. Eu sei que o FROMcabeçalho fará parte da assinatura, mas como o servidor destinatário verifica o DKIM? Ele está olhando novamente para o DNS no MAIL_FROMcabeçalho? Se sim, eu também poderia passar o DKIM com meu exemplo acima, certo? Ou o domínio está inserido MAIL_FROMe FROMé idêntico? Estou meio perdido.

Depois de tudo que entendi agora, tanto o DKIM quanto o SPF não devem ser um problema para minha aplicação web. Por que, porém, ainda é considerado uma má ideia e os e-mails provavelmente serão rejeitados? Ou não entendi o DKIM corretamente?

Minha pergunta geral: como exatamente o servidor destinatário determinará se o email foi rejeitado?

Responder1

Não há como você ter certeza. Você só pode adivinhar, a menos que o administrador do MX lhe diga o que há de errado.

A rejeição de mensagens pode ser baseada em qualquer informação encontrada dentro da mensagem, na transmissão ou em qualquer lugar da Internet, incluindo:

  • Endereço IP/sub-rede do MTA
  • MTA rDNS e FCrDNS
  • MTA FQDN de rDNS ou HELO
  • Listagem DNSBL do MTA
  • outras informações sobre o FQDN do MTA ou domínio do remetente disponíveis na Internet
  • histórico de conexões e falhas anteriores
  • MAIL FROM endereço ou domínio
  • cabeçalho DO endereço ou domínio
  • métodos de autorização como SPF, DKIM, DMARC
  • palavras-chave ou sequências no assunto ou corpo do e-mail
  • pontuação heurística do corpo e cabeçalhos do e-mail

A configuração de um MX/MTA ativo não deve ser feita de maneira despreocupada. Devido ao spam substancial e contínuo, há muitas práticas que você precisa obedecer ou você receberá rejeições ou acabará na pilha de spam. A maneira mais fácil é usar o servidor do seu ISP como smarthost - você precisará primeiro verificar suas políticas.

Além disso, você não pode usar domínios de remetentes "alienígenas" do seu sistema, a menos que tenha sido autorizado a fazê-lo. Forjar endereços de remetentes coloca você imediatamente no canto dos spammers maliciosos. Além disso, você não pode simplesmente confiar em nada que seus usuários enviem no momento do registro ou em qualquer outro momento. Se você não verificar o endereço de e-mail, seu serviço sofrerá abusos após apenas algumas horas.

informação relacionada