Sembra che l’ultimo aggiornamento del ricevitore di posta Self-hosted mail-receiver update following Let's Encrypt root certificate change non risolva più gli indirizzi IP in nomi host. Questo causa problemi con le restrizioni di accesso dei client Postfix che funzionavano in precedenza, abilitate aggiungendo la seguente riga a mail-receiver.yml:
POSTCONF_smtpd_client_restrictions: 'regexp:/etc/postfix/shared/client_access_regex'
Ecco un estratto dal log del ricevitore di posta, che mostra una connessione in entrata:
Oct 01 17:38:11 discourse-mail-receiver postfix/master[1]: reload -- version 3.5.6, configuration /etc/postfix
Oct 01 17:41:58 discourse-mail-receiver postfix/smtpd[151]: connect from unknown[167.71.160.115]
Oct 01 17:41:59 discourse-mail-receiver postfix/smtpd[151]: disconnect from unknown[167.71.160.115] ehlo=2 starttls=1 mail=1 quit=1 commands=5
Ciò che prima si risolveva nel nome host del client di origine www11-do.checktls.com[167.71.160.115] ora non viene risolto e viene contrassegnato come unknown[167.71.160.115].
Questo crea conflitti con le voci regex nel file client_access_regex, progettato per rifiutare tutti gli host senza un record PTR valido (che sono essenzialmente tutti i relay spam) nonché tutti gli host provenienti da intervalli di IP dinamici (principalmente host virtuali, e anche questi sono essenzialmente relay spam).
Poiché nessun IP viene risolto in un nome host, nessuna delle regole funziona più e, peggio ancora, la riga /unknown/ REJECT blocca ora tutte le email in arrivo. Ho dovuto disabilitare temporaneamente la regola per rendere possibili le connessioni in entrata, e tutte le altre regole sono rese inattive dal problema di risoluzione, quindi questo espone nuovamente il server allo spam (il mio forum era stato inondato di spam prima dell’implementazione di queste regole, e dopo che sono state implementate non ricordo di aver ricevuto nulla).
Non posso tornare alla vecchia versione come soluzione temporanea (a causa dei problemi con Let’s Encrypt), e la nuova versione riapre le porte allo spam, quindi sarei molto grato per una correzione (ho provato a capire come abilitare manualmente la risoluzione DNS all’interno dell’immagine Docker, ma senza successo).
Ecco un file client_access_regex a scopo di riferimento, nel caso qualcuno abbia gli stessi problemi ricorrenti di spam e voglia provarlo (utilizza Customize direct-delivery Postfix configuration per configurare /etc/postfix/shared e mail-receiver.yml):
# regex dns: ([a-zA-Z0-9]+(-[a-zA-Z0-9]+)*\.)+[a-zA-Z]{2,}
# regex ip: ((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)
#
# dyn-ip-dns:
/((\.|-|x)(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){2}((\.|-)[a-zA-Z0-9]+)+\.[a-zA-Z]{2,}/ REJECT
/unknown/ REJECT
/sample-spam\.domain\.com/ REJECT