Postfix reject_unknown_reverse_client_hostname: sostituisci default unknown_client_reject_code (450) a 550. Perché / quando non dovrei?

Nella battaglia quotidiana contro lo SPAM, ci sono state diverse volte in cui sono stato tentato di applicare pesantemente i requisiti DNS dai client che si connettono da Internet selvaggio.

In dettaglio, avrei aggiunto l' impostazione reject_unknown_reverse_client_hostname all'interno della mia sezione smtpd_client_rest restrizioni , come in:

smtpd_client_restrictions = 
            permit_sasl_authenticated
            check_client_access hash:/etc/postfix/access 
            check_policy_service inet:127.0.0.1:4466
            reject_unknown_reverse_client_hostname
            reject_unauth_pipelining

Ad ogni modo, ho notato che quando si colpisce tale restrizione, il comportamento di Postfix è abbastanza "debole" poiché il valore predefinito per unknown_client_reject_codeè 450. Quindi, il client è invitato a continuare a riprovare.

Durante l'indagine per una risposta 550, ho incontrato la seguente dichiarazione, sulla documentazione ufficiale di Postfix :

inserisci qui la descrizione dell'immagine

Sono assolutamente non un esperto su tutta la RFC 5321 , ma come qualcuno abbastanza vecchio per sapere RFC 821 , davvero non vedo il motivo per cui, una risposta invece di un 450 550, potrebbero avere un impatto il mio esempio Postfix al massimo livello SMTP ( infrangendo la conformità RFC), soprattutto considerando che in caso di errori temporanei, Postfix rimarrà con un 450 indipendentemente dall'impostazione esplicita.

Quindi, qualcuno può aiutarmi a capire qual è il problema con una tale sostituzione?

PS: nel frattempo, ho concluso con una restrizione "rilassata":

smtpd_client_restrictions = 
            permit_sasl_authenticated
            check_client_access hash:/etc/postfix/access 
            check_policy_service inet:127.0.0.1:4466
            warn_if_reject reject_unknown_reverse_client_hostname
            reject_non_fqdn_helo_hostname
            reject_unauth_pipelining 
            reject_invalid_helo_hostname

postfix smtp spam

— Damiano Verzulli
fonte

Inizierò con due risposte pratiche

La prima e più ovvia risposta è che nel caso in cui si verifichi un errore DNS temporaneo, un rimbalzo temporaneo consentirà al server di posta del mittente di riprovare fino a quando l'errore DNS non verrà corretto. In questo caso, un rimbalzo permanente bloccherà la posta effettiva del prosciutto da raggiungere.
La seconda risposta è che una grande quantità di spam viene inviata tramite botnet box che non hanno alcuna forma di programmi funzionali effettivi per inviare la posta. Spruzzeranno la loro spazzatura solo una volta e non proveranno a rispedire alcun messaggio se detto messaggio riceve un errore temporaneo o permanente. Quindi, usando un errore temporaneo, stai bloccando una grande percentuale di spam per sempre, ma stai ancora permettendo a ham di riprovare. (Questo, a proposito, è il motivo per cui il greylisting funziona ancora e cattura ancora molto spam.)

Oltre a questi, c'è anche una risposta che porta di più alla teoria e alla RFC

La RFC dice nella sezione 4.2.1. quello:

Una regola empirica per determinare se una risposta rientra nella categoria 4yz o 5yz (vedi sotto) è che le risposte sono 4yz se possono avere successo se ripetute senza alcuna modifica nel modulo di comando o nelle proprietà del mittente o del destinatario (ovvero , il comando viene ripetuto in modo identico e il destinatario non inserisce una nuova implementazione).

Nel caso di un errore di ricerca inversa, sarebbe possibile che il messaggio fosse accettabile senza alcuna modifica nel messaggio stesso, purché l'errore DNS fosse corretto. Pertanto, questo dovrebbe essere un errore temporaneo.

Nel caso in cui il messaggio non sia spam, il sysadmin del mailserver di invio potrebbe notare il messaggio di errore e risolvere il problema DNS, in modo che il messaggio possa essere consegnato senza che l'utente debba intervenire e rispedire il messaggio. E a meno che l'utente che invia l'e-mail sia anche responsabile del server di posta e / o delle sue voci DNS, anche se ottengono direttamente un rimbalzo permanente, non saranno in grado di farci nulla, a differenza del caso di un errore ortografico indirizzo.

Naturalmente, sei sempre nei tuoi diritti di rifiutare qualsiasi e-mail per qualsiasi motivo.

— Jenny D
fonte

Ho pensato a problemi temporanei del DNS ma .... sembra che non dovrebbero essere un problema in quanto ... " Il server SMTP risponde sempre con 450 quando il mapping non è riuscito a causa di una condizione di errore temporaneo ". Questi dovrebbero includere problemi temporanei di ricerca DNS. No? Per quanto riguarda il secondo punto (BotNet, greylisting, ecc.), Sembra ragionevole: quando i client non implementano un meccanismo di accodamento adeguato, una risposta 4XX produce gli stessi effetti di una 5XX. Comunque mi manca ancora il motivo per cui questo ha un impatto a livello di RFC.

— Damiano Verzulli,

@DamianoVerzulli Si applicherebbe quando la mappatura fallisce con un errore, non quando il DNS non è configurato correttamente per restituire il nome sbagliato, e successivamente viene corretto. In ogni caso, ho ampliato un po 'i problemi relativi alla RFC.

— Jenny D,

Grazie per aver indicato la sezione RFC corretta. Mi sto concentrando su questo: "le risposte sono 4yz se possono avere successo se ripetute SENZA ALCUN CAMBIAMENTO nel modulo di comando o nelle PROPRIETÀ del Mittente o del destinatario". La mia prima ipotesi è che il nome host DNS del client, così come il suo mapping DNS inverso, siano proprietà del mittente. No? Altrimenti non riesco a vedere quale potrebbe essere una proprietà del mittente. (A proposito: per favore non prendere i miei commenti sul personale. Sono davvero interessato a questa discussione e apprezzo molto i tuoi punti! Grazie per aver commentato!).

— Damiano Verzulli,

@DamianoVerzulli Il nome host DNS non è una proprietà del server di posta mittente e non può essere modificato nella configurazione del server di posta. È controllato dal server DNS autorevole, che di solito non è nemmeno lo stesso server, tanto meno parte del server di posta elettronica. A volte non è nemmeno controllato all'interno della stessa organizzazione. (Non lo prendo sul personale - questa è una discussione di fatti, senza argomenti ad hominem, non c'è nulla da prendere sul personale! Sono d'accordo che è molto interessante e non penso che sia chiaro, c'è un caso da fatto anche per l'altro lato.)

— Jenny D