Domanda

Sulla nostra applicazione di mailing stiamo inviando e-mail con la seguente intestazione:

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

Il problema che stiamo affrontando è che alcuni server e-mail rispediranno immediatamente un messaggio e utilizzeranno il percorso from o reverse (marketing@customer.com) invece del nostro server mgmt di rimbalzo. Vogliamo sapere se modifichiamo nell'intestazione la risposta in modo che sia uguale al percorso di ritorno se saremo in grado di catturare tutti i rimbalzi.

Altre idee sono benvenute?

Stiamo usando i seguenti documenti come riferimenti: VERP RFC Messaggi di rimbalzo

Analisi del log SMTP per ottenere rimbalzi

MODIFICA 1: qualche altra informazione per vedere se possiamo ottenere questa risoluzione.

Vogliamo sapere a che punto il server di posta elettronica che inoltra il messaggio sceglierà di utilizzare la risposta a contro il percorso di ritorno. Abbiamo notato che quando il primo server smtp inoltra il messaggio viene rifiutato, lo invia alla risposta, ma quando succede dopo un hop, lo invia al percorso di ritorno.

È stato utile?

Soluzione

Cominciamo con un semplice esempio. Supponiamo che tu abbia una mailing list che invierà i seguenti RFC2822 .

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.

Ora, supponiamo che lo invierai da una mailing list, che implementa VERP (o qualche altro meccanismo di tracciamento del rimbalzo che utilizza un percorso di ritorno diverso). Diciamo che avrà un percorso di ritorno di coolstuff-you=yourcompany.com@mymailinglist.com . La sessione SMTP potrebbe apparire come:

{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

Dove {C} e {S} rappresentano rispettivamente i comandi Client e Server.

La posta del destinatario sarebbe simile a:

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.

Ora, descriviamo le diverse " FROM " s.

  1. Il percorso di ritorno (a volte chiamato percorso inverso, mittente busta o busta da - tutti questi termini possono essere usati in modo intercambiabile) è il valore utilizzato nella sessione SMTP nel comando MAIL FROM . Come puoi vedere, questo non deve necessariamente avere lo stesso valore che si trova nelle intestazioni dei messaggi. Solo il server di posta del destinatario dovrebbe aggiungere un'intestazione Return-Path all'inizio dell'email. Ciò registra il mittente del percorso di ritorno effettivo durante la sessione SMTP. Se nel messaggio esiste già un'intestazione Return-Path, tale intestazione viene rimossa e sostituita dal server di posta del destinatario.

Tutti i rimbalzi che si verificano durante la sessione SMTP devono tornare all'indirizzo Return-Path. Alcuni server possono accettare tutta la posta elettronica, quindi accodarla localmente, fino a quando non ha un thread gratuito per recapitarla alla cassetta postale del destinatario. Se il destinatario non esiste, dovrebbe riportarlo al valore Return-Path registrato.

Nota, non tutti i server di posta rispettano questa regola; Alcuni server di posta lo riporteranno indietro all'indirizzo FROM.

  1. L'indirizzo FROM è il valore trovato nell'intestazione FROM. Questo dovrebbe essere da chi proviene il messaggio. Questo è quello che vedi come " DA " nella maggior parte dei client di posta. Se un'e-mail non ha un'intestazione di risposta, tutte le risposte umane (client di posta) devono tornare all'indirizzo FROM.

  2. L'intestazione Reply-To viene aggiunta dal mittente (o dal software del mittente). È qui che dovrebbero essere indirizzate anche tutte le risposte umane. Fondamentalmente, quando l'utente fa clic su "rispondi", il valore Rispondi dovrebbe essere il valore utilizzato come destinatario dell'email appena composta. Il valore di risposta non deve essere utilizzato da nessun server. È destinato esclusivamente al lato client (MUA).

Tuttavia, come puoi vedere, non tutti i server di posta rispettano gli standard o le raccomandazioni RFC.

Speriamo che questo possa aiutare a chiarire le cose. Tuttavia, se ho perso qualcosa, fammelo sapere e proverò a rispondere.

Altri suggerimenti

Un altro modo di pensare a Return-Path vs Reply-To è confrontarlo con la posta ordinaria.

Quando si invia una busta nella posta, si specifica un indirizzo di ritorno . Se il destinatario non esiste o rifiuta la posta, il postmaster restituisce la busta all'indirizzo di ritorno. Per l'e-mail, l ' indirizzo di ritorno è il Return-Path .

All'interno della busta potrebbe esserci una lettera e all'interno della lettera può indirizzare il destinatario a " Invia la corrispondenza a indirizzo di esempio " ;. Per l'e-mail, l ' indirizzo di esempio è il Rispondi a .

In sostanza, un indirizzo di reso postale è paragonabile all'intestazione Return-Path di SMTP e l'intestazione Reply-To di SMTP è simile alle istruzioni di risposta contenute in una lettera.

per coloro che sono arrivati ??qui perché il titolo della domanda:

Uso Rispondi a: con i moduli web. quando qualcuno compila il modulo, la pagina web invia un'e-mail automatica al proprietario della pagina. il From: è l'indirizzo del mittente automatico della posta, quindi il proprietario sa che proviene dal modulo web. ma l'indirizzo Rispondi a: è quello compilato nel modulo dall'utente, quindi il proprietario può semplicemente rispondere per contattarli.

Ho dovuto aggiungere un'intestazione Return-Path nelle e-mail inviate da un'istanza Redmine. Concordo con greatwolf solo il mittente può determinare un percorso di ritorno corretto (non predefinito). Il caso è il seguente: Le e-mail vengono inviate con l'indirizzo e-mail predefinito: admin@tuaazienda.com Ma vogliamo che il vero utente che avvia l'azione riceva le email di rimbalzo, perché sarà lui a sapere come correggere le e-mail dei destinatari sbagliati (e non gli amministratori dell'applicazione che hanno altri gatti da frustare :-)). Lo usiamo e funziona perfettamente con exim sul server delle applicazioni e zimbra come server di posta aziendale finale.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top