Uso correto do cabeçalho SMTP "Sender"?

Question

Nosso aplicativo da web envia mensagens de e-mail para as pessoas quando alguém publica novos conteúdos. Tanto o remetente quanto o destinatário optaram por receber mensagens de e-mail de nosso aplicativo. Ao preparar essa mensagem, definimos os seguintes cabeçalhos SMTP:

FROM: [email protected]
TO: [email protected]
SENDER: [email protected]

Optamos por usar o endereço de e-mail do autor no cabeçalho FROM em uma tentativa de fornecer a melhor experiência para o destinatário; quando eles vêem a mensagem em seu cliente de email, o autor é claro. Para evitar a aparência de spoofing, adicionamos o cabeçalho SENDER (com nosso próprio endereço de e-mail corporativo) para deixar claro que enviamos a mensagem em nome do autor. Depois de ler as RFCs 822 e 2822, isso parece ser um uso intencional do cabeçalho do remetente.

A maioria dos servidores de email de recebimento parece lidar com isso bem; a mensagem de e-mail é entregue normalmente (supondo que a caixa de correio do destinatário exista, não esteja acima da cota, etc). No entanto, ao enviar uma mensagem DE um endereço em um domínio para um endereço no mesmo domínio, alguns domínios de recebimento rejeitam as mensagens com uma resposta como:

571 incorrect IP - psmtp (in reply to RCPT TO command)

Acho que isso significa que o servidor de recebimento só viu que o endereço do cabeçalho FROM estava em seu próprio domínio e que a mensagem foi originada em um servidor que ele não considerou autorizado a enviar mensagens para esse domínio. Em outras palavras, o servidor de recebimento ignorou o cabeçalho SENDER.

Temos uma solução alternativa: o webapp mantém uma lista de domínios que parecem ignorar o cabeçalho SENDER, e quando os cabeçalhos FROM e TO estão em tal domínio, ele define o cabeçalho FROM como nosso próprio endereço de e-mail em vez de. Mas esta lista requer manutenção.

Existe uma maneira melhor de alcançar a experiência desejada? Gostaríamos de ser um "bom cidadão" da rede, e todas as partes envolvidas - remetentes e destinatários - querem participar e receber essas mensagens. Uma alternativa é sempre usar o endereço de e-mail de nossa empresa no cabeçalho FROM e adicionar o nome / endereço do autor ao assunto, mas isso parece um pouco desajeitado.

    

Answer 1

Você está olhando para as coisas erradas. Essas são as mensagens cabeçalhos . Você deve estar olhando para o envelope SMTP . (Como o envelope é especificado depende de como exatamente o seu aplicativo está enviando mensagens para o sistema de correio. Em muitos sistemas, o envelope é especificado pelos argumentos da linha de comando para o programa utilitário de envio de correspondência.) ele decide emitir essa resposta 571, o servidor de retransmissão SMTP pode não ter sequer visto os cabeçalhos da mensagem.

O texto de resposta está dizendo que o administrador do servidor de retransmissão SMTP em questão com o qual você está falando restringiu o que você pode colocar no envelope SMTP. Parece estar reclamando da parte do destinatário do envelope. Mas pode estar adiando a validação do remetente do envelope até a especificação do primeiro destinatário, por isso pode estar reclamando do remetente.

Observe que o remetente do envelope é para onde as mensagens de status de entrega são enviadas e você não quer direcionar as mensagens para pessoas aleatórias em todo o mundo. (Além do fato de que muitas pessoas não gostam disso, não faz sentido que as mensagens de status de entrega para seu e-mail sejam retornadas para qualquer pessoa, exceto você.) Especifique-se como remetente do envelope.

É errado requerer MX registros de recursos, a propósito. Um servidor de retransmissão SMTP pode ser localizado pelos registros de recursos A e AAAA na ausência de nenhum registro de recurso MX . Veja RFC 5321 § 5.1.

    

Answer 2

Posso estar errado, mas a causa mais provável do erro acima, especialmente no caso do Postini, é que os domínios em que você está sendo rejeitado têm uma política de SPF estrita. A maioria dos servidores de e-mail com verificação de SPF verifica apenas o cabeçalho De:, eles não se importam com o cabeçalho do Remetente.

Para verificar se esse é o caso, execute "dig + short TXT domain.com", em que domain.com é o que está lhe dando a mensagem de erro. Você deve receber algo como:

"v=spf1 mx -all"

A parte importante é o -all. Isso significa que o proprietário do domínio afirmou que só enviará e-mails dos servidores que atuam como servidores de e-mail. Todos os outros e-mails serão rejeitados.

Felizmente, se este for o caso, você pode verificar ativamente antes de enviar o e-mail! Faça o WebApp fazer uma verificação de SPF quando o usuário inserir seu endereço de e-mail. Se houver uma política rígida em vigor, adicione o domínio à sua lista. Não há escassez de bibliotecas para todos os idiomas que podem fazer verificações de SPF.