Qual é a diferença de comportamento entre caminho de regresso, reply-to e de?

Question

Em nosso aplicativo de correio eletrônico que está enviando e-mails com o seguinte cabeçalho:

FROM: marketing@customer.com
TO: subscriber1@domain1.com
Return-PATH: bouncemgmt@ourcompany.com

O problema que estamos enfrentando é que alguns servidores de e-mail será devolvida uma mensagem imediatamente e usar a partir de ou inversa caminho (marketing@customer.com) em vez para o nosso servidor salto MGMT. Queremos saber se modificar no cabeçalho o reply-to para ser o mesmo que o caminho de regresso se vai ser capaz de capturar todos os saltos.

Quaisquer outras ideias são bem-vindas?

Estamos usando os seguintes documentos como referências: VERP RFC rejeição mensagens

SMTP análise de log para obter Bounces

EDIT 1: A mais alguns pedaços de informação para ver se podemos obter essa determinação.

Queremos saber em que ponto retransmitindo a mensagem vai optar por usar o reply-to versus o retorno-path do servidor de e-mail. Temos aviso de que quando o primeiro servidor SMTP retransmitir a mensagem é rejeitada ele envia-lo para o reply-to, mas quando isso acontece depois de um salto ele envia-lo para o caminho de regresso.

Answer 1

início Vamos com um exemplo simples. Vamos dizer que você tem uma lista de e-mail, que vai enviar o seguinte RFC2822 conteúdo.

From: <coolstuff@mymailinglist.com>
To: <you@yourcompany.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123@mymailinglist.com>

This is a very simple body.

Agora, vamos dizer que você está indo para enviá-lo a partir de uma lista de discussão, que implementa VERP (ou algum outro mecanismo de controlo de rejeição que utiliza um caminho de regresso diferente). Vamos dizer que ele terá um caminho de retorno coolstuff-you=yourcompany.com@mymailinglist.com. A sessão SMTP pode parecer:

{S}220 workstation1 Microsoft ESMTP MAIL Service
{C}HELO workstation1
{S}250 workstation1 Hello [127.0.0.1]
{C}MAIL FROM:<coolstuff-you=yourcompany.com@mymailinglist.com>
{S}250 2.1.0 me@mycompany.com....Sender OK
{C}RCPT TO:<you@yourcompany.com>
{S}250 2.1.5 you@yourcompany.com 
{C}DATA
{S}354 Start mail input; end with <CRLF>.<CRLF>
{C}From: <coolstuff@mymailinglist.com>
To: <you@yourcompany.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123@mymailinglist.com>

This is a very simple body.
.

{S}250 Queued mail for delivery
{C}QUIT
{S}221 Service closing transmission channel

Onde comandos {C} e {S} representam cliente e servidor, respectivamente.

mail do destinatário seria parecido com:

Return-Path: coolstuff-you=yourcompany.com@mymailinglist.com
From: <coolstuff@mymailinglist.com>
To: <you@yourcompany.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123@mymailinglist.com>

This is a very simple body.

Agora, vamos descrever o diferente "de" s.

1. O caminho de retorno (às vezes chamado o caminho inverso, remetente envelope ou envelope - todos esses termos podem ser usados ??alternadamente) é o valor usado na sessão SMTP no comando MAIL FROM. Como você pode ver, isso não precisa ser o mesmo valor que é encontrado nos cabeçalhos de mensagens. Apenas servidor de correio do destinatário é suposto para adicionar um cabeçalho Return-Path ao topo do e-mail. Isso registra o remetente Return-Path real durante a sessão SMTP. Se um cabeçalho Return-Path já existe na mensagem, em seguida, esse cabeçalho é removido e substituído pelo servidor de correio do destinatário.

Todos os saltos que ocorrem durante a sessão SMTP deve voltar para o endereço Return-Path. Alguns servidores podem aceitar todos os emails, e depois a fila-lo localmente, até que ele tem um fio livre para entregá-lo para a caixa postal do destinatário. Se o destinatário não existir, ele deve saltar de volta para o valor Return-Path gravado.

Note, nem todos os servidores de correio obedecer a essa regra; Alguns servidores de correio vai saltar de volta para o endereço DE.

2. O endereço é o valor encontrado na DE cabeçalho. Este é suposto ser que a mensagem é de. Isto é o que você vê como o "de" na maioria dos clientes de email. Se um e-mail não tem um cabeçalho Reply-To, em seguida, todos humanos (cliente de email) respostas devem voltar para o endereço DE.

3. O cabeçalho Reply-To é adicionado pelo remetente (ou software do remetente). É onde todas as respostas humanas devem ser abordadas também. Basicamente, quando o usuário clica em "resposta", o valor Reply-To deve ser o valor usado como o destinatário do e-mail recém-composta. O valor Reply-To não deve ser usado por qualquer servidor. Ele é destinado a do lado do cliente (MUA) usar somente.

No entanto, como você pode dizer, nem todos os servidores de correio obedecem às normas ou recomendações RFC.

Esperamos que isso deve ajudar a esclarecer as coisas. No entanto, se eu perdi alguma coisa, avise-me, e eu vou tentar responder.

Answer 2

Outra maneira de pensar sobre Return-Path vs Reply-To é compará-lo ao correio tradicional.

Quando você envia um envelope no correio, você especificar um endereço de retorno . Se o destinatário não existe ou recusa seu e-mail, o postmaster retorna a parte de trás do envelope para o endereço de retorno. Por e-mail, o endereço de retorno é o Return-Path.

Dentro do envelope pode ser uma letra e no interior da carta de orientar o destinatário "Enviar correspondência para exemplo de endereço ". Por e-mail, o exemplo de endereço é o Reply-To.

Em essência, um selo de endereço é comparável ao cabeçalho Return-Path de SMTP e cabeçalho Reply-To de SMTP é semelhante às instruções respondendo contidas em uma carta.

Answer 3

para aqueles que cheguei aqui, porque o título da pergunta:

Eu uso endereço Reply-To: com webforms. quando alguém preenche o formulário, a página envia um e-mail automático para o proprietário da página. o From: é o endereço do remetente e-mail automático, assim que o proprietário sabe que é do formulário Web. mas o endereço Reply-To: é aquele preenchido no formulário pelo usuário, de modo que o proprietário pode simplesmente clicar em responder para contatá-los.

Answer 4

Eu tive que adicionar um cabeçalho Return-Path em e-mails enviados por uma instância de Redmine. Concordo com greatwolf apenas o remetente pode determinar uma correta (não padrão) Return-Path. O caso é o seguinte: E-mails são enviados com o endereço de e-mail padrão: admin@yourcompany.com Mas queremos que o usuário real de iniciar a ação recebe os e-mails de rejeição, porque ele será o único saber como corrigir errados destinatários e-mails (e não os administradores de aplicativos que têm outros gatos para chicote :-)). Nós usamos isso e ele funciona perfeitamente bem com exim no servidor de aplicativos e Zimbra como servidor de empresa final.