Non riceve la posta da alcuni mittenti a causa della configurazione DNS

Ho notato un comportamento peculiare del mio dominio di app di Google. La maggior parte delle e-mail arrivano come ti aspetteresti, ma per un periodo di tempo sono giunto alla conclusione che le e-mail di determinati mittenti non arrivano. Dopo aver identificato uno di questi mittenti, i cui messaggi di posta elettronica non venivano inviati, gli ho chiesto di provare a inviarmi una e-mail e di inoltrare la risposta "mancata consegna" al mio normale gmail.

La risposta dell'errore di consegna conteneva il seguente frammento:

----- Segue la trascrizione della sessione -----
<myusername@GHS.L.GOOGLE.COM>... Differito: connessione scaduta con ghs.l.google.com.

Questo mi ha aiutato a identificare il problema facendo una rapida ricerca che mi ha portato a questa pagina sul Forum di assistenza di Google Apps. In effetti, ho controllato il record DNS per il mio dominio ed è @stato impostato su ghs.google.com. (CNAME), che non dovrebbe essere. Modificandolo in @ 74.125.93.121 (A)* risolto il problema.

Capisco che nei casi in cui la posta non viene inviata, il mio nome di dominio è stato sostituito dal suo nome canonico attraverso una ricerca CNAME, quindi la posta è stata inviata myusername@ghs.l.google.cominvece di myusername@mydomain.com. Ma perché ha funzionato per la stragrande maggioranza dei mittenti? I mittenti la cui posta non è arrivata, hanno utilizzato un diverso tipo di protocollo di posta, alcune strane impostazioni DNS o quale potrebbe essere?

Da quello che ho potuto vedere ricercando il problema su google, questo sembra essere un problema diffuso (molte persone che si lamentano delle e-mail da battle.net che non arrivano, sarebbe un esempio popolare), solo che le persone non sembrano essere consapevoli del fatto che il problema risiede nelle proprie impostazioni DNS, piuttosto che dalla parte dei mittenti.

Quindi, come può essere spiegato?

^{* Ho usato questo IP per quello che ho letto qui , ma penso che qualsiasi IP farebbe il trucco. Qualcuno può confermare questo? Si noti che la semplice rimozione del @record non ha risolto il problema, ma è stato necessario modificarlo.}

Da RFC 2821 "Simple Mail Transfer Protocol", sezione 5 "Risoluzione degli indirizzi e gestione della posta":

La ricerca tenta innanzitutto di individuare un record MX associato al nome. Se viene invece trovato un record CNAME, il nome risultante viene elaborato come se fosse il nome iniziale.

In generale, è così che funzionano i CNAME. Sono spesso usati male, capiti male e implementati male. :-)

Se il tuo dominio è example.com, probabilmente hai record MX esistenti che puntano ai soliti host di Google Apps.

example.com. MX 10 ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT1.ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT2.ASPMX.L.GOOGLE.COM.
example.com. MX 30 ASPMX2.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX3.GOOGLMAILE.COM.
example.com. MX 30 ASPMX4.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX5.GOOGLEMAIL.COM.

Sembra che tu abbia avuto anche una voce come questa:

example.com. CNAME ghs.l.google.com.

Gli stati "Concetti e strutture del dominio" RFC 1034 nella sezione 3.6.2 "Alias ​​e nomi canonici" sconsigliano questa configurazione:

Se un RR CNAME è presente in un nodo, non dovrebbero essere presenti altri dati; questo assicura che i dati per un nome canonico e i suoi alias non possano essere diversi.

Nel caso dell'errore che hai incollato, il server di posta e / o il server DNS all'estremità di invio hanno tentato di cercare i record MX per il tuo dominio, example.com e hanno trovato un CNAME che punta a ghs.l.google. com. Ha quindi cercato di cercare i record MX per ghs.l.google.com. Quel dominio al momento non ha record MX, quindi il server di posta sarebbe passato al record A per ghs.l.google.com. Quell'indirizzo IP non era in ascolto sulla porta SMTP, quindi il risultato è l'errore "Timeout della connessione con ghs.l.google.com".

Rimuovendo il record CNAME, hai risolto i tuoi problemi di posta. Potresti riscontrare problemi se l'indirizzo IP che hai definito al suo posto viene modificato da Google.

È possibile invece definire il nome utente per www.esempio.com:

www.example.com. CNAME ghs.l.google.com.

Ed esegui un piccolo server web su qualunque IP tu punti esempio.com, che semplicemente reindirizzi HTTP a http://www.example.com/

È un po 'sorprendente che abbia funzionato bene come ha fatto. Credo che la legge di Postel ottenga un certo merito. :-)

Torna a RFC 1034 2.6.2:

Le RR CNAME causano azioni speciali nel software DNS. Quando un server dei nomi non riesce a trovare un RR desiderato nel set di risorse associato al nome di dominio, verifica se il set di risorse è costituito da un record CNAME con una classe corrispondente. In tal caso, il server dei nomi include il record CNAME nella risposta e riavvia la query sul nome di dominio specificato nel campo dati del record CNAME. L'unica eccezione a questa regola è che le query che corrispondono al tipo CNAME non vengono riavviate.

Pertanto, in questo caso si potrebbe sostenere che il server DNS non dovrebbe / non dovrebbe seguire il CNAME in una ricerca MX a meno che non siano stati trovati record MX.

Quando si invia posta, Sendmail e qmail (e probabilmente altri) tenteranno di default di riscrivere qualsiasi nome CNAME utilizzato nella parte destra di un indirizzo e-mail con il nome canonico.

In effetti, alcuni siti si basavano su questo comportamento. djb approfondisce il motivo per cui pensa che le persone dovrebbero smettere di fare affidamento su di esso nel suo documento "CNAME records in mail" .

Il @simbolo in un record BIND è solo un modo abbreviato di scrivere il dominio. Se stai creando un record per example.com, allora @è solo un alias per example.com. Dire che il @record doveva essere un IP è un'affermazione che manca di informazioni critiche - non ci hai detto che tipo di record fosse.

Dal rapporto di consegna, sembra che tu abbia fatto qualcosa con il tuo DNS per indurre il server di posta remoto a riscrivere il tuo dominio su ghs.l.google.com - molto strano (PS, un record A deve essere un IP, un record CNAME non deve essere un IP o un altro record CNAME).

Perché quel server di posta di persone stia riscrivendo il tuo indirizzo è strano - non dovrebbe farlo a meno che quella persona non abbia fatto qualcosa per dirgli esplicitamente di riscriverlo. Inoltre, non dovrebbe interessarsi affatto quale sia l'IP del tuo dominio a meno che non riesca a trovare alcun record MX, poiché i record MX sono il modo in cui i server di posta capiscono dove va la posta.

Mi sembra che, date le pochissime informazioni fornite, tu non abbia seguito le istruzioni di google su come configurare correttamente il tuo DNS per la posta elettronica. Probabilmente hai anche degli errori nel tuo file di zona: farli controllare da un amministratore di zona competente.