Motivi legittimi SMTP "MAIL FROM:" non corrisponderà a "From:" Header in DATA


18

Esiste mai un motivo legittimo per cui il campo SMTP "MAIL FROM:" non corrisponda al campo "From:" nella sezione DATA di un messaggio, oltre alle mailing list?

Da /programming/1750194/smtp-why-does-email-needs-envelope-and-what-does-the-envelope-mean :

“Ma, per continuare la metafora della posta ordinaria, la maggior parte delle lettere professionali conterrà gli indirizzi del mittente e del destinatario stampati sulla lettera stessa. Tali indirizzi non sono necessari per il postino, ma sono invece una cortesia per il destinatario. Quindi è ragionevole che l'e-mail funzioni allo stesso modo. "

Il problema con questa linea di logica risiede qui: "cortesia al destinatario". Includere l'indirizzo "Da:" in un'e-mail tramite SMTP non è una cortesia; è necessario se il destinatario deve essere in grado di inviare una risposta.

Da: Come limitare l'intestazione Da in modo che corrisponda a MAIL FROM in postfix? :

"Ma se vuoi davvero assicurarti di From: e MAIL FROM, devi applicare header_checks in modo che Return-Path: corrisponda a From:"

Quali sono le implicazioni nel fare questo? Le mailing list sarebbero ovviamente un problema. Esistono altri usi legittimi delle diverse informazioni di intestazione "MAIL FROM:" e "From:"?

Risposte:


22

Esistono molti motivi per cui gli indirizzi Header e Envelope From potrebbero non corrispondere. La maggior parte riguarda i processi automatizzati di invio della posta, in cui i problemi di consegna devono essere segnalati a un indirizzo che non è rappresentativo di chi ha inviato la posta, o di chi è stato inviato per conto o a chi deve rispondere. Le mailing list come hai sottolineato sono un buon esempio.

Il motivo principale per cui un messaggio inviato dal client di posta di un utente potrebbe essere diverso dagli indirizzi è la posta inoltrata. Il contenuto della posta dovrebbe quindi essere ragionevolmente fedele all'originale, ma in caso di errori di consegna, questi dovrebbero essere segnalati all'utente che ha inoltrato l'e-mail, non al mittente originale.

Oltre all'intestazione SMTP, ci sono una varietà di intestazioni MIME che vari programmi usano per cercare di distinguere tra il mittente originale e il mittente intermedio e / o l'indirizzo preferito per segnalare errori a. Rispondi a, mittente, originariamente da , Errori-To, ecc., Ecc. Ognuno con semantica diversa. Alcuni di questi hanno il supporto standard, mentre molti altri no, ma potrebbero essere in uso comunque. Il modo in cui i vari programmi di posta elettronica si comportano in pratica varia notevolmente.

Se un modo di indirizzare la posta sia consigliabile è una questione diversa dal fatto che sia "legittimo" come chiedi. Se stai prendendo in considerazione la legittimità qui in termini di una politica come la gestione di potenziali spam, allora no, non credo che sarai in grado di fare una semplice distinzione in questo modo.

Pensa alla firma DKIM della posta elettronica e all'autenticazione SPF dei server di posta per i domini di posta elettronica. Se stai inviando molta posta, potrebbe essere importante essere in grado di autenticare la tua posta in questi modi e ciò potrebbe avere implicazioni per l'indirizzamento della posta dalle intestazioni, poiché puoi autenticare solo la posta relativa ai domini per i quali hai l'autorità .

-

Esteso su richiesta:

Un'intestazione "Rispondi a" MIME indica a un MUA (agente utente di posta, in genere client di posta di una persona) di inviare risposte a un indirizzo diverso, anziché all'indirizzo "Da" di MIME. Questo non è usato da un MTA (Mail Transport Agent) per cose come errori.

Di solito un MTA utilizza l'indirizzo "MAIL From" della busta SMTP per inviare errori. L'IT può essere sostituito con un'intestazione "Errori-A" MIME, che è un'istruzione MTA. Non tutti gli MTA lo onoreranno, quindi è un meccanismo inferiore per impostare l'indirizzo della busta SMTP, ma ci sono molte circostanze in cui è possibile impostare le intestazioni MIME in un messaggio, ma non l'indirizzo della busta SMTP da. Ad esempio, il software in esecuzione in un ambiente di hosting condiviso potrebbe trovarsi in questa situazione.

"Mittente" è molto più ambiguo come istruzione per gli agenti software, ma indica chi o cosa ha inviato l'e-mail in modo che sia distinto dall'indirizzo Da che è più simile a chi è stata inviata la posta per conto di. Ad esempio, quando si compila un modulo di posta elettronica il proprio politico, sarebbe molto appropriato che l'e-mail risultante utilizzasse la propria posta nell'intestazione Da, ma avesse un indirizzo del mittente correlato all'organizzazione che ha impostato il modulo.

'Originally-From' viene utilizzato da alcuni software MUA durante l'inoltro della posta, con l'indirizzo dello spedizioniere utilizzato per l'intestazione 'From'. Gli altri MUA lasceranno solo l'indirizzo del mittente e utilizzeranno un'intestazione "Rinvia-Da". Se i MUA che ricevono queste varie e-mail di intestazioni interpretano le intestazioni in modo utile o addirittura li visualizzano è piuttosto variabile. Quando rispondi a una mail che ti è stata inoltrata, a chi dovrebbe rispondere per impostazione predefinita? Forse è meglio impostare l'intestazione "Rispondi a"?

Il comportamento dei MUA è variabile, e mal definito, anche se sembra migliorare nel tempo. Al contrario, la semantica dell'Inviluppo è molto più definita. In genere c'è stata una posizione forte secondo cui gli MTA non dovrebbero mai occuparsi delle intestazioni MIME, ma poiché gli MTA sono sempre più ritenuti responsabili del contenuto della posta (ad es. Vedi SPF e gli standard DMARC emergenti), c'è una pressione affinché la chiarezza di quella posizione venga degradata. Meccanismi di vecchia data come Error-To sono anche in conflitto con l'idea che gli MTA non guardino il contenuto dell'intestazione, il che è parte del motivo per cui tali meccanismi sono sempre stati applicati in modo incoerente. Le filosofie degli autori di software variano.

Potresti trovare utile dare un'occhiata a http://tools.ietf.org/html/rfc4021#section-2 , ma ricorda che le pratiche attuali della moltitudine di software di posta elettronica là fuori variano in modi che non sono necessariamente benedetti dagli standard.

Va bene cercare di elaborare una chiara filosofia su come pensi che la posta debba essere usata, ma non aspettarti che tutti gli altri facciano le cose come pensi che dovrebbero.


Ho ancora tempo per assegnare questo premio e sono interessato a scenari aggiuntivi che richiederebbero l'uso delle intestazioni: `Rispondi a, Mittente, Originariamente-Da, Errori-A`
goodguys_activate

Grazie per le aggiunte. Spero di avere una chiara comprensione di quali siano i comportamenti previsti dall'MTA, rispetto a come sono implementati. Inoltre, potresti essere interessato a questo q: ho appena pubblicato su Sec.StackExchange per quanto riguarda la whitelisting e-mail (simile a BATV) security.stackexchange.com/q/41008/396
goodguys_activate

1
+1, perché solo 4 voti?
Pacerier,

11

L'elaborazione automatizzata è un grande motivo. Volete essere in grado di inviare rimbalzi / autoreplies / errori da elaborare separatamente, altrimenti quei messaggi scompaiono, o vengono ignorati, o qualche povera linfa deve scavarli. Sì, è possibile aggiungere un'intestazione X per l'elaborazione, ma molte volte rimbalza / ecc. non includerà l'e-mail originale o solo una parte alterata di essa e non sarai in grado di ottenere la fonte.

Ad esempio, supponi che qualcuno si iscriva sul tuo sito Web e invii loro un'email per ringraziarti della registrazione. MAILFROM e From potrebbero apparire così:

MAIL FROM: <user-signup-123123123@bounces.example.com>
From: Website X <noreply@example.com>

In questo modo, l'utente vede il "friendly from" nel client di posta. Ma se l'utente non esiste, il suo MTA invierà il messaggio di rimbalzo a:

user-signup-123123123@bounces.example.com

e un processo automatizzato può facilmente estrarre userid (la parte 123123123) e la parte del sistema che ha creato il rimbalzo (la parte -signup-) dall'intestazione e cancellare / contrassegnare facilmente quell'utente come disabilitato.


8

La posta da: nella conversazione smtp è progettata per essere il luogo in cui andranno i rimbalzi L'intestazione Da: nel corpo del messaggio viene utilizzata per visualizzare al destinatario e come indirizzo di risposta se l'intestazione Rispondi a: non è impostata.

Le e-mail che non devono generare un rimbalzo dovrebbero impostare il mittente vuoto nella busta, ad esempio una ricevuta di ritorno avrà di solito: mail from:<>con il nome dell'utente nell'intestazione from:.

Un'altra situazione è quella in cui un server di posta utilizza BATV per rifiutare i rimbalzi falsi. La posta da: sarà nel formato prvs=tag-value=mailbox@example.com.


Penso di ricordare di aver visto un X-header per resi e rapporti di mancato recapito. Sai quando e come viene utilizzato?
goodguys_activate

Le intestazioni X sono state originariamente aggiunte come mezzo di MUA e / o MTA per inserire metadati personalizzati e non sono specificate in alcuno standard, sebbene alcuni diventino standard defacto. Potresti pensare al tipo mime multipart / report definito in rfc 6522 che è stato definito per aiutare il software a classificare i messaggi che vengono rimbalzati automaticamente. Questi verranno comunque inviati con una busta vuota per posta da:
Richard Salts,

1

A meno che non stia leggendo correttamente le intestazioni o la domanda, le e-mail dal mio BlackBerry vengono inviate dal server BlackBerry e praticamente nessuno dei campi corrisponde. Piccola percentuale di utenti, mi rendo conto. Ho esaminato questo aspetto recentemente nella valutazione del mio server di posta. Di seguito è un'e-mail anonima inviata dal mio BlackBerry al mio account Gmail:

Delivered-To: recipientusername@gmail.com
Received: by 10.50.11.138 with SMTP id q10csp217364igb;
        Wed, 14 Aug 2013 00:18:53 -0700 (PDT)
X-Received: by 10.42.83.84 with SMTP id g20mr4290552icl.10.1376464731205;
        Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Return-Path: <SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com>
Received: from smtp08.bis6.us.blackberry.com (smtp08.bis6.us.blackberry.com. [74.82.85.8])
        by mx.google.com with ESMTP id lq6si7427361icb.102.2013.08.14.00.18.51
        for <recipientusername@gmail.com>;
        Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Received-SPF: pass (google.com: domain of SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com designates 74.82.85.8 as permitted sender) client-ip=74.82.85.8;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com designates 74.82.85.8 as permitted sender) smtp.mail=SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com
Received: from b15.c8.bise6.blackberry ([192.168.0.115])
    by srs.bis6.us.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id r7E7InfH019786
    for <recipientusername@gmail.com>; Wed, 14 Aug 2013 07:18:49 GMT
Received: from 172.29.201.172 (cmp2.c8.bise6.blackberry [172.29.201.172])
    by b15.c8.bise6.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id r7E7IlCt013236
    for <recipientusername@gmail.com>; Wed, 14 Aug 2013 07:18:47 GMT
X-rim-org-msg-ref-id: 587275596
Message-ID: <587275596-1376464726-cardhu_decombobulator_blackberry.rim.net-631052459-@b17.c8.bise6.blackberry>
Reply-To: senderusername@example.com
X-Priority: Normal
Sensitivity: Normal
Importance: Normal
Subject: Test
To: "Recipient Name" <recipientusername@gmail.com>
From: senderusername@example.com
Date: Wed, 14 Aug 2013 07:18:45 +0000
Content-Type: text/plain
MIME-Version: 1.0

Test
Sent via BlackBerry by AT&T

C'è un motivo eccellente per questo: la riscrittura SPF . Se BlackBerry non lo stesse facendo, si otterrebbero molti più errori SPF durante l'invio dal dispositivo.
MikeyB,

Vero, ma è perché BlackBerry non utilizza il mio server per l'invio.
Paolo
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.