Newsgroup: it.comp.os.linux.sys
Titolo: Postfix - helo reject

 
proto=ESMTP helo=<srvex01.clienteimportante.local>
Ora... non so perche' ma postfix ha il potere di mandare la mia mente in 
una gran confusione e chiedo aiuto.
A mio modo di vedere,
srvex01.clienteimportante.local 
non e' "valido".... e postfix giustamente, avendo la regola: 
reject_invalid_helo_hostname 
settata in
smtpd_helo_restrictions
s'indigna...per cosi dire
Ho provato ad agire con header_checks.pcre 
ma ho paura che quanto scrivo non gli vada un granche' perche' non 
funziona...
/^Received:.*srvex01.clienteimportante.local/ REPLACE 
Received:
clienteimportante.it
Il man dice che dopo REPLACE se si sta modificando una intestazione 
bisogna iniziare con una label header
Ma qui mi sa che si parla di Helo e non della riga Received.
Nei log dettagliati infatti mi trovo:
blabla[20054]: generic_checks: name=reject_unknown_helo_hostname status=2
blabla[20054]: > 
hostnnn-nn-static.nn-nnn-b.business.telecomitalia.it
[nnn.nn.nn.nnn]: nnn n.n.n <srvex01.clienteimportante.local>: Helo 
command rejected: Host not found
Quindi mi sa che l'unica e' togliere il filtro sull'helo?
O dite che c'e' un modo per aggirare l'ostacolo?
Grazie in anticipo :)
Christian

 funziona...
Più che "non andargli", non c'entra una mazza.
header_checks agisce sugli header.
La mail è stata rigettata sulla base della helo-string (che è un dato di
*envelope*) in fase RCPT, quando gli header non son nemmeno stati ancora
inviati....
-- 
Professional System & Network Sarcazzer
http://bofhskull.wordpress.com/

 E' follia. Levalo.
mi aggancio, spero non dispiaccia all'op, prendendo spunto dalla 
conversazione, io ho impostato
         reject_unauth_destination,
         reject_non_fqdn_sender,
         reject_invalid_hostname,
         reject_unknown_sender_domain,
         reject_unknown_recipient_domain,
         reject_unauth_pipelining,
a tuo avviso, skull, è eccessivo? cìè qualcosa che andrebbe migliorata?
perchè ad esempio io impostai reject_invalid_hostname.
Anticipo i ringraziamenti!

          reject_unauth_pipelining,
Simile al mio set (io uso reject_invalid_helo_hostname, ma è
la stessa cosa)
Proprio su reject_invalid_helo_hostname si può discutere: a livello enterprise
io ritengo che possa essere usato, se fai il mail provider o l'isp magari
un po' meno...

 un po' meno...
Potenzialmente usabile anche a livello di ISP, se si ha la voglia di
star dietro alla quantità di falsi positivi che scatenerà.
Che non sono poi molti, ma van risolti...
Io preferisco essere più buono (che è tutto un dire) e rigettare quelli
che mostrano una direttta correlazione con l'invio di spam.
Qualcuno a caso (di una mappa che ne ha accumulati circa 1200):
/^desktop[a-z0-9_\-]*$/
/^[a-z0-9_\-]*home[a-z0-9_\-]*$/
/^YOUR-[A-Z0-9]{10,10}$/
/^dsldevice\.lan$/
/^user[a-z0-9_\-]*$/
ecc ecc.


 a tuo avviso, skull, è eccessivo? cìè qualcosa che andrebbe migliorata?
mi associo, dato che usiamo regole quali identiche, e saluto


Abbe', se, com'e` l'ordine e` importante, l'interrogazione all'oracolo
diverrebbe cosi` (probabilmente e` ancora insufficiente
all'intelligenza del tutto, nel senso che per dare un giudizio
avveduto ci vorrebbero anche gli altri pezzi, non solo i reject,
quindi, appunto, a meno che Skull non sia un vero Oracolo, prevedo una
assennata sospensione del giudizio):
smtpd_helo_restrictions =
        reject_non_fqdn_hostname,
        reject_invalid_hostname,
smtpd_sender_restrictions =
        reject_non_fqdn_sender,
        reject_unknown_sender_domain,
smtpd_recipient_restrictions =
        reject_unauth_pipelining,
        reject_non_fqdn_recipient,
        reject_unknown_recipient_domain,
        reject_unauth_destination,
#       reject_rbl_client 
zen.spamhaus.org
,
        reject_rbl_client 
list.dsbl.org
,
        reject_rbl_client 
sbl-xbl.spamhaus.org
,

         reject_rbl_client 
sbl-xbl.spamhaus.org
,
E' buona norma bypassare le helo/sender restrictions ed inserirle nel 
recipient.
Why ?
Perchè almeno logghi anche il mittente ed il destinatario.
In caso di FP, fa sempre comodo.

 problema di blacklistati innocenti.
Allora, zen include anche sbl e xbl, e aggiunge pbl.
Di innocenti in pbl, francamente, non me ne sono mai capitati.
Di cretini sì, ma questa è un'altra storia...

 In caso di FP, fa sempre comodo.
Grazie.
FP non sta per fallo parlante, ma per falso positivo, vero?
Andrea

 FP non sta per fallo parlante, ma per falso positivo, vero?
Certo.
Oltre quanto ti hanno gi� detto, alcune altre considerazioni.
Se vuoi mantenere distinti i controlli nelle tre fasi dell'envelope allora 
puoi usare smtpd_delay_reject = yes che raccoglie comunque tutte e tre le 
informazioni per appunto avere il log completo anche se la mail � gi� stato 
deciso di rifiutarla.
list.dsbl.org
 � inattiva da mesi.
http://www.dsbl.org/
Quando si usano le BL � opportuno controllare ogni tanto i log e/o i siti, 
per non fare come quelli che ancora oggi usano 
ordb.org
 (ed hanno risolto 
alla radice il problema spam).
Alcuni suggerimenti inoltre sulle regole
smtpd_helo_restrictions =
	permit_mynetworks,
         check_helo_access pcre:/etc/postfix/access_helo_pcre,
         reject_non_fqdn_hostname
Aggiungi sempre una regola per permetterti di bypassare certi controlli. 
P.es. il check_helo_access sopra ti permette di whitelistare le macchine 
gestite da cazzoni ma con cui, purtroppo, DEVI comunicare. Io in genere uso 
anche il permit_mynetworks per evitare inutili controlli sulla posta in 
uscita per l'helo che spesso per gli altri server interni � comunque locale.
smtpd_sender_restrictions =
	check_sender_access hash:/etc/postfix/access_sender,
	reject_unknown_sender_domain
Il reject_non_fqdn_sender � pi� labile del reject_unknown_sender_domain 
quindi � superfluo. Come per l'helo pu� essere utile aggiungere una mappa 
per whitelistare o blacklistare degli specifici sender, sia interni che esterni.
smtpd_recipient_restrictions =
	reject_unauth_pipelining,
	reject_unknown_recipient_domain,
	check_client_access hash:/etc/postfix/access_recipient,
	permit_mynetworks,
	reject_unauth_destination,
	reject_unverified_recipient,
	check_policy_service inet:
127.0.0.1:60000
,
	reject_rbl_client 
zen.spamhaus.org
,
	reject_rbl_client 
bl.spamcop.net
,
	reject_rbl_client ....
	...
	permit
Per le recipient io uso in genere questo ordine (anche se in molti posti ho 
anche altri controlli che variano, come postfwd). Non so se sia il migliore 
(sicuramente c'� gente molto pi� preparata di me che pu� correggerlo), ma la 
logica � questa: prima i controlli che valgono per interno ed esterno e 
nell'ordine che risparmia banda e risorse; quindi unauth_pipelining che � 
molto poco oneroso va per primo, mentre il secondo � il controllo sul 
dominio di destinazione che richiede una query DNS. Poi metto una mappa per 
poter whitelistare o blacklistare anche le mail che partono dall'interno e 
quindi permetto le mie reti.
Dopo i controlli che valgono solo dall'esterno: primo rigetto la posta che 
non sono tenuto a trattare (unauth destination) poi rigetti gli utenti 
inesistenti che � un controllo che mi costa poco (il risultato viene tenuto 
in cache); poi applico il greylisting che mi risparmia delle query inutili 
alle blacklist (anche per non appesantire inutilmente i loro server) e 
infine le blacklist dalla pi� probabilmente efficace a quella meno efficace.
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

 alle blacklist (anche per non appesantire inutilmente i loro server) e
Ho spostato il graylistamento prima del check delle blacklist
esterne.
Saluti

 questa mi manca
Si usa quando non hai le mailbox locali ma queste sono su un altro server. 
Non so se � il tuo caso.


     reject_rbl_client 
bl.spamcop.net
,
Questa ora come ora la toglierei.
Son cambiate un po' di persone "in testa" a SpamCop, e i buoni risultati
che erano riusciti ad ottenere in quanto a scarsit� di FP stan pian
pianino retrocedendo (neanche troppo pian-pianino)...
Aggiungo una osservazione sul greylisting prima delle DNSBL: � una cosa
poco onerosa finch� il traffico � basso.
Se le mail iniziano a diventare tante, ti ritrovi con un DB di
greylisting enorme, con i problemi del caso soprattutto se hai pi� MX e
il DB � un SQL condiviso tra tutti (per ovvie ragioni): molto meglio in
quel caso passare di greylisting dopo le DNSBL.


 OK, ma siamo sicuri?
A meno che un sender non-FQDN appartenga ad un dominio che risolve, s�.
Cosa che in futuro potrebbe anche capitare, se la gente inizia a dotare
i TLD di record MX... :-P


 ...è pericolosa, poichè avviene prima di reject_unauth_destination.
        check_client_access hash:/etc/postfix/internal_networks
anche messa subito dopo a
smtpd_recipient_restrictions =
mi auguro non sia pericolosa, se appunto dentro ci sono solo le tue
reti interne, ma chiedo conferma.


Una parte del mio cervello non sa che cosa fa l'altra. No, li` dentro
c'e` un pezzo del giro per evitare che dall'esterno ci scrivano con
indirizzi del nostro dominio.

 smtpd_recipient_restrictions =
Eh?


reject_non_fqdn_hostname)
permit_mynetworks c'e' perche' altrimenti non passerebbe il check fqdn(?)
potrebbe essere una soluzione accettabile?
Poi evidentemente pensavo "male"; credevo che fosse diciamo obbligatorio 
salutare con un fqdn o perlomeno qualcosa che ci assomiglia.
Domanda, non riesco a spiegarlo, ma reject_non_fqdn_hostname non e' molto 
piu restrittivo di reject_invalid_helo_hostname ?
Grazie
Christian

 piu restrittivo di reject_invalid_helo_hostname ?
In ordine di "restrizione":
1) reject_invalid_helo_hostname: rigetta se l'helo non è una stringa
valida (es: contiene caratteri non consentiti)
2) reject_non_fqdn_helo_hostname: rigetta se l'helo non è in forma FQDN
(quindi ad esempio è un hostname privo del dominio; di fatto, quindi è
un superset della precedente)
3) reject_unknown_helo_hostname: rigetta se la helo string non risolve
in DNS. Ovviamente, se non fosse FQDN non potrebbe risolvere comunque,
quindi questa a sua volta è un superset delle due precedenti
La 1 ha un tasso di FP risibile.
La 2 meno, ma comunque sufficientemente basso da essere gestibile.
Con la 3 hai ottime possibilità di rifiutare anche grossi provider...


 ====> check_client_access hash:/etc/postfix/access_recipient,
che evidenziavi sopra, ma poi mi sono reso conto che io lo usavo solo
come parte delle regole per impedire che mi scrivessero dall'esterno
con indirizzi interni e quindi in conclusione credo che non lo sia e
non rischi di fare del mio MX un relay aperto, nemmeno per pochi altri
domini.
Andrea

 chiedevo se non potesse essere pericolosa, come la
E' "pericolosa" se la usi per whitelistare, perch� per gli host che 
"whitelisti" tu diventi un open-relay.


          reject_non_fqdn_hostname
Di solito accetto comunque la posta per postmaster anche quando
l'helo farebbe match su reject_non_fqdn_hostname.
Fabio