Newsgroup: it.comp.os.linux.software
Titolo: postfix, reject_unknown_hostname la usate?

Ho messo la regola di cui all'oggetto in smtpd_helo_restrictions.
Prima d'ora non la usavo.
Da quando l'ho impostata mi arrivano un sacco di segnalazioni di mail
che non arrivano piu'.
Effettivamente controllando, il nome host che viene trasmesso al mio
server col comando HELO risulta inesistente.
Sinceramente non capisco il motivo, non si tratta sicuramente di spam,
so da dove arrivano le mail.
Capita anche a voi?
Come vi comportate?
A me hanno chiesto di disabilitare la restrizione.

 A me hanno chiesto di disabilitare la restrizione.
Client che mandano HELO non FQDN. Io ho impostato le restrizioni sull'HELO
sul relay, che in ogni caso non dovrebbe ricevere connessioni dirette dai
client, e puo' quindi serenamente rifiutare l'HELO non corretto da un
server. In ogni caso sul reject_unknown_hostname viene fatto un softbouce
(450 mi pare), quindi le mail dovrebbero tornarmi sull'MX priario.
ciao
Luca

:
Helo command rejected: Host not found.
Non risolve 
excsrv03.eidoslan.net
.
E' un problema loro?
Hanno il loro smtp impostato male?

 Hanno il loro smtp impostato male?
~$ host 
excsrv03.eidoslan.net
Host 
excsrv03.eidoslan.net
 not found: 3(NXDOMAIN)
Non esiste nemmeno un record A. Purtroppo il rischio di questi check su MX
primari è che sistemi malconfigurati come quello non riusciranno a
mandarti posta. E' per quello che io peronalmente li tengo solo sul relay,
in modo da minimizzare il rischio di perdere posta.
ciao
Luca


Normale.
Quella restriction avrebbe un senso in un mondo di server configurati da 
gente che sa configurare un server.
Purtroppo il 90% dei server non č cosě.
Disabilita e cerca altre strade (creati dei test da usare in 
check_helo_access, insomma...)
-- 
cat: .signature: No such file or directory

 relay, in modo da minimizzare il rischio di perdere posta.
Perche' hai necessita' di usare un relay?

 Purtroppo il 90% dei server non è così.
Sono costretto a toglierla allora .......... che palle.........


Io uso la reject_unkown_sender_domain, che controlla l'mx o l'a record del 
mittente
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
	Prima di parlare collegare la spina del cervello,
	 leggere e in caso di schermata blu riavviare.

 del mittente
Nell'helo restriction?
Io la usavo nel recipient restrictions.
Comunque nel mio caso non esistono nemmeno i record A, si tratta proprio
di malconfigurazione.
Purtroppo mi devo adeguare.

 Sono costretto a toglierla allora .......... che palle.........
In tutta onestà serve comunque a poco. Molti dei motori usati dallo 
spamware recente generano un helo copiandolo dalla zona inversa dell'IP 
del proxy.
Il risultato è che hai un client non lecito con helo lecito.
Questo spinge a crearsi altre restrictions decisamente meno banali:
bash-2.05b$ egrep -v "^#" helo-* | wc -l
      633
/me veh...



nel sender_restriction, controlla l'esistenza di A o MX del dominio 
dell'email, non del server che contatta il tuo mx


 Perche' hai necessita' di usare un relay?
Per il servizio di relaying?
ciao
Luca

 dell'email, non del server che contatta il tuo mx
Messa nel sender_restriction o nel recipietn_restriction non cambia
niente tanto tutti i controlli vengono effettuati dopo il comando RCPT
TO a meno di non aver settato smtpd_delay_reject = no.

Luca Corti wrote:

Scusa l'ignoranza ma non ho capito :-(

 
Ok, ma è  diverso il controllo; il server si presenta con un helo 
sballato, ma l'email deve avere un mittente corretto


 
Si, ok volevo solo essere sicuro di aver capito bene e cioe' che
reject_unkown_sender_domain messa in sender restriction o in recipient
restriction, avendo smtpd_delay_reject = yes (default), e'
indifferente.

 Scusa l'ignoranza ma non ho capito :-(
Nel DNS indichi con i record MX chi sono i mailserver per un dato dominio
e la relativa priorità. Ad es.
example.org
.	IN	MX 10	
mail.example.org
.
example.org
.	IN	MX 20	
relay.example.org
.
Se qualcuno manda una mail ad un indirizzo di quel dominio (es.
us...@example.org
) il suo SMTP cercherà di contattare 
mail.example.org
. Se
non ottiene risposta contatterà 
relay.example.org
. 
Relay.example.org
 non
riceve direttamente la posta per 
us...@example.org
, ma la gira a sua volta
a 
mail.example.org
. Mettiamo che 
mail.example.org
 sia down,
relay.example.org
 terrà in coda la posta per 
example.org
 finchè
mail.example.org
 non torna a funzionare e gliela consegnerà.
Puo' tornare utile, ad esempio, quando si cambiano l'MX di un dominio per
evitare di perdere dei messaggi.
ciao
Luca