Uso corretto dell'intestazione "Mittente" SMTP?


20

La nostra applicazione Web invia messaggi e-mail alle persone quando qualcuno pubblica nuovi contenuti. Sia il mittente che il destinatario hanno optato per la ricezione di messaggi e-mail dalla nostra applicazione. Quando prepariamo un messaggio del genere, impostiamo le seguenti intestazioni SMTP:

DA: author@example.com
A: recipient@example.com
Mittente: webapp@mycompany.com

Abbiamo scelto di utilizzare l'indirizzo e-mail dell'autore nell'intestazione FROM nel tentativo di fornire la migliore esperienza per il destinatario; quando vedono il messaggio nel loro client di posta, l'autore è chiaro. Per evitare la comparsa di spoofing, abbiamo aggiunto l'intestazione SENDER (con il nostro indirizzo e-mail aziendale) per chiarire che abbiamo inviato il messaggio per conto dell'autore. Dopo aver letto le RFC 822 e 2822, questo sembra essere un uso previsto dell'intestazione del mittente.

La maggior parte dei server di posta riceventi sembra gestirla bene; il messaggio di posta elettronica viene recapitato normalmente (presupponendo che la cassetta postale del destinatario esista, non superi la quota, ecc.). Tuttavia, quando si invia un messaggio DA un indirizzo in un dominio A un indirizzo nello stesso dominio, alcuni domini riceventi rifiutano i messaggi con una risposta come:

571 IP errato - psmtp (in risposta al comando RCPT TO)

Penso che questo significhi che il server ricevente ha visto solo che l'indirizzo di intestazione FROM era nel proprio dominio e che il messaggio proveniva da un server che non considerava autorizzato a inviare messaggi per quel dominio. In altre parole, il server ricevente ha ignorato l'intestazione SENDER.

Abbiamo una soluzione alternativa: la webapp mantiene un elenco di tali domini che sembrano ignorare l'intestazione SENDER e quando le intestazioni FROM e TO sono entrambe in tale dominio, imposta invece l'intestazione FROM sul nostro indirizzo e-mail. Ma questo elenco richiede manutenzione.

Esiste un modo migliore per ottenere l'esperienza desiderata? Vorremmo essere un "buon cittadino" della rete e tutte le parti coinvolte - mittenti e destinatari - desiderano partecipare e ricevere questi messaggi. Un'alternativa è usare sempre l'indirizzo e-mail della nostra azienda nell'intestazione FROM e anteporre il nome / indirizzo dell'autore all'oggetto, ma questo sembra un po 'goffo.


Perché non usare From: authorinvece di From: author@example.com?
Pacerier,

Risposte:


16

Stai guardando le cose sbagliate. Quelle sono le intestazioni dei messaggi . Dovresti guardare la busta SMTP . (Il modo in cui viene specificata la busta dipende da come, esattamente, l'applicazione sta inviando posta al sistema di posta. Su molti sistemi la busta è specificata dagli argomenti della riga di comando al programma di utilità di invio della posta.) A seconda di esattamente quando nella transazione del protocollo decide di emettere quella risposta 571, il server di inoltro SMTP potrebbe non aver visto nemmeno le intestazioni dei messaggi.

Il testo della risposta dice che l'amministratore di quel particolare server di inoltro SMTP con cui stai parlando ha limitato ciò che puoi mettere nella busta SMTP. Sembra lamentarsi della parte del destinatario della busta. Ma potrebbe essere rinviare la convalida del mittente della busta fino alle specifiche del primo destinatario, quindi potrebbe lamentarsi del mittente.

Si noti che il mittente della busta è il luogo in cui vengono inviati i messaggi sullo stato della consegna e non si desidera che vengano indirizzati a persone casuali in tutto il mondo. (A parte il fatto che molte persone non lo fanno in questo modo, non ha senso per i messaggi di stato di consegna per la posta da restituire a nessuno, ma voi.) Specificare se stessi come il mittente della busta.

A MXproposito, è sbagliato richiedere record di risorse. Un server SMTP Relay puo 'essere localizzato Ae AAAArecord di risorse in assenza di qualsiasi MXrecord di risorse. Vedi RFC 5321 § 5.1.


Ho controllato l'RFC prima di implementare il controllo dei record MX e ho imparato la stessa cosa: verificare la presenza di un fallback Un record in assenza di un record MX. Esaminerò la busta SMTP; grazie per il suggerimento.
Eric Rath,

Ho studiato la busta SMTP, l'ho testato. Hai ragione - ho erroneamente supposto che tutto il controllo dell'origine avrebbe usato l'intestazione del messaggio "Da", ma sembra che venga usata la busta.
Eric Rath,

5

Potrei sbagliarmi, ma la causa più probabile dell'errore di cui sopra, specialmente nel caso di Postini, è che i domini in cui vieni rifiutato hanno una rigida politica SPF. La maggior parte dei server di posta con controllo SPF controllerà solo l'intestazione From: non si preoccuperanno dell'intestazione del mittente.

Per verificare se questo è il caso, esegui "dig + short TXT domain.com" dove domain.com è ciò che ti dà il messaggio di errore. Dovresti recuperare qualcosa del tipo:

"v = spf1 mx -all"

La parte importante è il tutto. Ciò significa che il proprietario del dominio ha dichiarato che invierà sempre e-mail dai server che fungono da server di posta, tutte le altre e-mail verranno rifiutate.

Fortunatamente, in questo caso, puoi controllare attivamente prima di inviare l'e-mail! Chiedi a WebApp di eseguire un controllo SPF quando l'utente inserisce il proprio indirizzo e-mail. Se esiste una politica rigorosa, aggiungi il dominio al tuo elenco. Non mancano le librerie per tutte le lingue che possono eseguire controlli SPF.


Grazie, è una buona idea. Ho controllato (con dig) la manciata di domini che hanno già presentato il comportamento indesiderato, e una coppia aveva record SPF con ~ tutto. Quindi non è una soluzione completa, ma penso che sarà difficile trovare una soluzione completa a questo problema. Penso che gli altri stiano applicando la stessa logica di base, ma senza archiviare / pubblicare le informazioni nei record SPF.
Eric Rath,

La tua idea ha suggerito un altro controllo di validazione da eseguire: il dominio dell'indirizzo dovrebbe avere un record MX valido. Se qualcuno digita male il proprio indirizzo e-mail e l'errore cade nella parte del dominio dell'indirizzo (ad esempio person@domainn.com), la consegna fallirà perché non è possibile trovare alcun record MX per il dominio (supponendo che l'errore non abbia portato a un dominio diverso, ma ancora valido).
Eric Rath,

Ho cambiato la "risposta accettata" in quella di JdeBP di seguito: la distinzione tra intestazione del messaggio e intestazione della busta l'ha davvero inchiodata. Ma grazie per il feedback.
Eric Rath,

5
Correzione: SPF controlla "MAIL FROM" nella busta, non le intestazioni "Da" o "Mittente".
Simon East,
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.