
Este artigo (https://www.sparkpost.com/resources/email-explained/return-path-explained/) explica "Return-Path" da seguinte forma:
Quando um e-mail não chega ao destino pretendido, o caminho de retorno indica para onde os recibos de não entrega – ou mensagens devolvidas – devem ser enviados.
e
Muitos remetentes incorporarão identificadores no endereço do caminho de retorno para facilitar o manuseio do tráfego de resposta e devolução, conhecido como Variable Envelope Return Path (VERP).
Entendo isso como: "Como remetente do email, você especifica o cabeçalho Return-Path".
No entanto, dada a seguinte resposta (https://stackoverflow.com/a/28494070/9878135), parece que o servidor receptor sempre substitui o Return-Path:
Definir o cabeçalho Return-Path: no email de saída é inútil porque será substituído pelo MTA do destinatário. Se você quiser controlar o que é escrito lá, defina o remetente do envelope (tradicionalmente, sendmail -f[e-mail protegido])
Atualmente estou tentando construir um servidor de e-mail que use VERP para e-mails. Digamos "[e-mail protegido]" deseja enviar um e-mail para o exterior. "De" deveria ser "[e-mail protegido]" enquanto "Return-Path" deveria ser algo completamente diferente (como "[e-mail protegido]"). Quando o serviço de e-mail externo não puder entregar o e-mail, ele deverá enviar um e-mail de volta para "[e-mail protegido]". Meu servidor agora pode pesquisar esse e-mail devolvido no banco de dados e informar[e-mail protegido]sobre a falha na entrega.
Estou usando o Postfix para enviar e receber e-mails (e Python para construí-los). No entanto, parece que o Return-Path nunca é recebido por outros serviços de e-mail (como Google Mail ou ProtonMail). O Google Mail não mostra o cabeçalho enquanto o ProtonMail o substitui pelo endereço "De".
Então, quem define o cabeçalho Return-Path e por que outros serviços de email não podem receber o meu?
Responder1
Return-Path:
cabeçalho contém uma cópia do endereço do "remetente do envelope". Return-Path:
O cabeçalho geralmente é (re)gerado pelo SMTP/MTA fazendo a entrega diretamente na caixa de correio do destinatário (após o salto SMTP final).
"Remetente do envelope" é um endereço usado em MAIL FROM:
comando na sessão SMTP.
Portanto, seu software cliente de envio deve definir "envelope sender" => Ele será (normalmente) copiado para Return-Path:
.
https://en.wikipedia.org/wiki/Bounce_address#Terminologia
caminho de retorno- Quando o email é colocado na caixa de email do destinatário, um novo cabeçalho de email é criado com o nome "Return-Path:" contendo o endereço no comando MAIL FROM. Formas anteriores de e-mail (como UUCP) exigiriam informações sobre cada "salto" ao longo do caminho que o e-mail percorreu para chegar ao destino, daí a parte "caminho" do nome. Usado emRFC 2821,RFC 3834,RFC 4409.
Responder2
O Return-Path
cabeçalho do e-mail deve conter o último endereço de devolução conhecido do último handshake SMTP no caminho de entrega. Ao contrário, por exemplo, Received
dos cabeçalhos, os cabeçalhos existentes Return-Path
no correio podem ser eliminados por servidores posteriores. Observe que as devoluções serão enviadas de acordo com MAIL FROM
os dados SMTP, e não de acordo com Return-Path
os dados caso esses valores discordem.
Na realidade, deve-se considerar o cabeceamento Return-Path
apenas como um acidente histórico. Pode ou não conter um endereço utilizável e oficialmente não é usado para nada e deve ser considerado apenas como informação de depuração. Os dados SMTP MAIL FROM
são o endereço de devolução realmente usado que pode ou não ser copiado Return-Path
para depuração. Os Return-Path
dados deveriam ser mais confiáveis porque são definidos pelo servidor receptor, mas como são apenas uma cópia oculta, MAIL FROM
podem conter literalmente qualquer coisa.
DR: Return-Path
está depurando informações definidas pelorecebendoservidor para uma transação SMTP ou ESMTP. Quaisquer Return-Path
cabeçalhos existentes no e-mail real podem ou não ser excluídos antes de adicionar o Return-Path
cabeçalho.