Vademecum impostazioni SMTP, SPF, PTR records

tips admin smtp spf ptr

  • 5 commenti
Ciao a tutti,
negli ultimi mesi mi è capitato più volte di prendere in carico problematiche segnalate da diversi clienti, legate all'invio/ricezione della posta che per un motivo o per l'altro non arrivavano a destinazione.
Visto che le cause sono sempre state le medesime, ho pensato di condividere degli appunti con possibili soluzioni (con i vostri commenti potremo anche ampliare questo post ovviamente, aggiungendo altri scenari)

Problematica invio legata SPF record


Ci si accorge dell'errore solitamente perchè la mail in uscita tornano indietro con il seguente messaggio:

"Error transferring to PINCOPALINO.COM; SMTP Protocol Returned a Permanent Error 554 5.7.1 : Recipient address rejected: Please see http://spf.pobox.com/why.html?sender=Daniele Grillo%40dominopoint.it&ip=XXX.XXX.XXX.XX"


Cosa significa?

Significa che sul DNS del vostro dominio internet (ex. dominopoint.it) è presente un record SPF e che non è impostato correttamente.

In pratica in questo record speciale andremo a definire l'elenco di IP o domini autorizzati a spedire le mail in uscita  (potete utilizzare i vostri IP pubblici o qualora utilizziate ad esempio un servizio di newsletter o smtp esterno è consigliato indicare gli IP di invio)
Nel caso più semplice può essere il vostro antispam appliance e non direttamente Domino o un SMTP esterno abilitato ad inviare le mail verso l'esterno.
Una possibile sintatti potrebbe essere questa (di sintassi e casi ce ne sono diversi, vi invito a leggere le specifiche del record a questa pagina ufficiale SPF):

"v=spf1 mx ip4:XXX.XXX.XXX.XXX/32 -all"


dove

XXX.XXX.XXX.XXX
= IP pubblico che spedisce le mail
mx
= possono inviare le mail anche gli IP indicati nell'MX record
-all
= tutti gli altri non sono validi

Con l'esempio sopra indicherete che solo 1 IP pubblico specifico e i vostri server MX che ricevono la posta sono autorizzati ad inviare le mail del vostro dominio.

Per risolvere il vostro problema dovrete impostare correttamente il record SPF (è solitamente un record TXT) sul vostro dominio internet gestito dal vostro provider sui cui è registrato il dominio (ex: register.it, aruba.it, etc...etc..)
Il concetto di funzionamento è davvero molto semplice.
Il server ricevente  verificherà se esiste il record SPF in questione (se abilitato ovviamente come controllo) e se esiste verificherà che l'IP che si è collegato sulla porta SMTP è uno di quelli accreditati interrogando il record SPF.
Un modo per testare l'implementazione dell'SPF record è questo tool online
Per verificare una volta che i DNS si è propagati (24/48h) basta mandare una mail a questo indirizzo spf-test@openspf.net  (la mail ritornerà indietro come un delivery failure con scritto PASS o FAIL nell'header)
Tenete presente che anche se molti provider non attivano il controllo SPF io consiglio sempre di implementarlo per sicurezza.

Reverse DNS Lookup


Detto anche PTR record.
Il vostro IP che spedirà la posta verso l'esterno solitamente ha un IP pubblico che gli è stato attribuito (Domino direttamente oppure Antispam solitamente)
Quell'IP pubblico solitamente avrà nel vostro DNS del vostro provider un record Host attribuito (solitamente è MX di ricezione, ma non è detto..può essere anche un semplice HOST)
Un ulteriore controllo che viene fatto dai destinatari di posta è che l'IP pubblico collegato abbia settato la risoluzione del nome al contrario partendo dall'IP.

Come testarlo?

Usate il tool di MX Toolbox a questa pagina ed inserite il vostro IP di spedizione della posta

Se non è settato o è sbagliato...dovrete contattare il vostro fornitore xDSL (telecom, fastweb etc...) che vi fornisce il range di IP pubblici e chiedergli di implementare il vostro PTR record in maniera corretta (ex: mail.dominopoint.it)

SMTP Reverse Banner Check


Anche in ricezione sarebbe opportuno che sulla porta 25 del vostro/i  MX record (solitamente un Antispam o Domino direttamente) rispondesse con un HELO domain corretto (ex. mail.dominopoint.it)
Se è Domino direttamente a rispondere ricordatevi di mettere la variabile nel notes.ini

SMTPGreeting = servername.domain.com SMTP Server ready at %S

Come testarlo?

Usate il tool di MX Toolbox a questa pagina (inserendo il vostro IP/hostname di ricezione)

Posta in uscita - permanent error Status: 2562


I vostri utenti vi segnalano spesso SMTP Permanent Error, ed andando a debuggare la comunicazione SMTP in uscita ( Leggete questa technote per capire come attivare il Debug) vi accorgerete che ad un certo punto...sulla console di Domino appare

SMTPClient: Data Send Failed XXXX  bytes, Status: 2562
SMTPClient: Connection broken after an error sending DATA command

Questo è solitamente un problema legato all'ESMTP Inspector  dei CISCO ASA firewall (Vi invito a leggere questa technote di IBM) o a fattori esterni a Domino che in qualche modo intercettano la porta 25,

Cosa fare?

Sembra che anche sui recenti firmware dei CISCO ASA sia stato reintrodotto il BUG,  quindi l'unica soluzione è farsi disattivare questa feature

Mi auguro che questi appunti siano stati utili, ed aspetto da voi qualunque suggerimento od ampliamento vogliate fare

Ciao!







5 Commenti:

  • #1 Filippo Di Meco 02/07/2018 1:06:07 PM

    Io ho un problema su un cliente che ha un server exchange 2016 interno tramite il quale spedisce posta all'esterno e il dominio di posta invece è su arubabusiness. Tramite un connettore pop3 (popbeamer) il server scarica la posta e la invia alle cassette postali interne. Da quando abbiamo cambiato provider internet da telecom ad un gestore locale WIFI (la zona non è coperta da fibra) il provider ha dimenticato di inserire il reverseDNS per lì'ip pubblico che ci ha assegnato e l'ip è andato a finire in diversi server di blacklist. Adesso nonostante il reverse dns sia stato creato, con un nome generico alcuni server come quello di trendmicro non vogliono cancellare l'ip dalla blacklist con questa risposta:

    Hi,

    Thank you for your e-mail. IP has generic-naming rDNS. We kindly request to

    add proper rDNS for this IP address, as this is one of the basic practices

    of mail servers.

    Typical static rDNS terms:

    bus, biz, colo, ded, fix, mta, perm, server, smtp, static, wsip.

    You can get back to us on this ticket when it's done, for the removal of

    address in our list.

    You may seek help from your ISP regarding this.

  • #2 Francesco Marzolo 08/03/2015 2:28:28 PM

    Aggiungo un piccolo contributo per chi deve progettare l'ambiente di protezione su clienti dotati di più record MX. Facciamo un esempio che ci aiuta a puntualizzare: brambilla.com, già dotato di filtro antispam, decide di dotarsi di più record MX, per ovviare ai momenti di fault della sua linea internet, e acquista un servizio di MX backup sul provider di sua scelta, aruba.it.

    Accadrà prima o poi che un messaggio destinato a brambilla.com arrivi su aruba.it. Tutto previsto. Al ripristino del dialogo con il server "di casa", il server aruba cercherà di trasmettergli il messaggio, ma accadrà un problema: il server antispam non riuscirà a verificare su SPF (di default) il fatto che aruba.it SPEDISCA verso il server interno posta con mittenti che NON appartengono ad aruba.it.

    Il server antispam rifiuterà la posta che è stata temporaneamente parcheggiata su aruba.

    Come fare? Le soluzioni sono alcune. Per prima cosa, aiuta nella fase di configurazione avere istruzioni SPF che spieghino cosa succede. Io uso spesso due record SPF, cerco di ridurli all'osso:

    IN  TXT "v=spf1 mx -all exp=spf-exp.brambilla.com" 

    spf-exp IN TXT "The email from %{s} using SMTP server at %{i} was rejected by %{c} (%{r}) at %{t} because it failed the SPF records check for the domain %{p}." 

    Rare volte anche un SPF sull'host oltre che sul dominio, può portare beneficio, ma questo sarebbe oggetto di un altro post.

    Notate il "-all", dipende da quanto siete sicuri che la posta venga rifiutata se viene da una sorgente non prevista, io lo preferisco molto.

    Non è il caso di aggiungere in SPF aruba.it, ho fatto questo esempio apposta, perché sarebbe troppo insicuro.

    In definitiva sono giunto alla conclusione che in situazioni complesse sia meglio se non necessario configurare più entrate smtp periferiche, e sia necessario dotare solo questa periferia di filtri antispam, ma non i dialoghi interni, che possono anzi interrompere la trasmissione di messaggi tra server che nulla hanno (ormai) da controllare.

    Sarà capitato di vedere messaggi rifiutati da sistemi destinatari a cui da poco era stato aggiunto un fitro SPF da un solerte sistemista che poco aveva capito, l'unica è attendere che qualcuno segnali il problema. E quando lo si fa per primi, spesso si viene presi per visionari.

    Se avete altre esperienze mi farebbe piacere confrontarmi.

    Buon SPF a tutti!

  • #3 Flaz 03/01/2013 9:03:16 AM

    Per verificare l'hostname associato all'IP ci si può anche arrangiare con nslookup dando:

    set q=ptr

    40.30.20.10.in-addr.arpa

    Dove 4.3.2.1 è l'IP al contrario (ovvero in questo caso l'IP sarebbe 10.20.30.40)

    Ciao!

  • #4 Daino 02/19/2013 9:41:10 AM

    Grazie e complimenti!

    L'hai scritto proprio al momento giusto, in cui diversi clienti hanno il problema (Tiscali in particolare).

  • #5 Giorgio 02/18/2013 3:18:01 PM

    Finalmente un post sistemistico!

    grazie Daniele!

Commenta articolo
 

Questo spazio web è stato creato da per un uso pubblico e gratuito. Qualsiasi tipo di collaborazione sarà ben accetta.
Per maggiori informazioni, scrivete a info@dominopoint.it

About Dominopoint
Social
Dominopoint social presence: