Newsgroup: it.comp.os.linux.sys
Titolo: Lapsus su server di posta

Ciao a tutti.
Situazione attuale:
cliente (con adsl telecom ip dinamico) che deve inviare posta tramite il 
mio server anzichè tramite smtp telecom.
Ho configurato sasl e tutto il resto ed il cliente viene autenticato dal 
mio server ed invia correttamente.
Ma il server remoto che riceve posta, mi stronca i messaggi perchè 
proveniente da un IP dinamico (quello del cliente).
Esiste un modo per sistemare la cosa, ma non ricordo come!! Any hint?

 Esiste un modo per sistemare la cosa, ma non ricordo come!! Any hint?
Il tuo server non deve spedire direttamente ma fare il relay sull'smtp
server della telecom.
-- 
Stefano L.

 writes:
A> Esiste un modo per sistemare la cosa, ma non ricordo come!! Any hint?
Se usi Postfix:
smtpd_recipient_restrictions = permit_sasl_authenticated [...]
Saluti,
Luca Polo.
-- 
Luca...@gest.unipd.it
 --- 
http://www.gest.unipd.it/~jake
----------------------------------------------------------
One Ping to rule them all. One Ping to find them.
One Ping to bring down them all.
And in the darkness crash them.         [The Lord of the Pings]

 smtpd_recipient_restrictions = permit_sasl_authenticated [...]
Già fatto.
Infatti il cliente riesce ad inviare posta.

 server della telecom.
No, io devo inviare con il mio, sono io il provider.
Con tanto di ip fisso, reverse, deleghe ripe etc.
Il problema non è il mio ip ma quello del mio cliente.

Alessandro ha scritto:

scusa, ma se l'email del cliente esce dal "tuo" server, come fa il 
server del destinatario della posta a vedere che IP ha il tuo cliente?
L'unica possibilita' che riesco ad immaginare (con i pochi dettagli che 
hai fornito) e' che, questo IP, rimanga registrato nell'header del 
messaggio in un campo 'Received' - e quindi, successivamente, rilevato 
dal sw antispam del server di destinazione (in tal caso e' altamente 
probabile che lo classifichi come spam).
-- 
Cybertoldo
Per rispondermi via email, sostituisci moc.liamg con 
gmail.com

 
E' esattamente così.
Infatti, non mi viene in mente una possibile soluzione.
Tenendo conto, che altri miei clienti, spediscono posta regolarmente.
Il cliente ha impostato come server SMTP il mio server, ha attivato 
l'autenticazione etc etc, la mail arriva al mio server, il mio server la 
inoltre a quello di destinazione, e il destinatario la sega.
(me ne sono accorto perchè un mio account con SpamAssassin me la marca 
come spam, proprio perchè il primo ip di immissione alla rete, cioè 
quello del cliente, è un IP dinamico)
Che sia solo un problema del mio spamassassin? Se si, come risolvo sta 
questione o come configuro il mio SA? Non mi ricordo come si fa :(

 ......
Che mi risulti, SpamAssassin analizza *tutti* gli header 'received' di un 
email ed aggiunge punteggio (tramite controlli DNSBL) per ogni ip che trova 
in blacklist. Cioe', riassumendo: se l'ip del tuo cliente e' presente in un 
campo received, e l'ip e' in qualche blacklist, l'email rischia di venire 
segata da (qualunque) SpamAssassin.
Soluzioni?
Non conosco abbastanza Postfix per consigliarti o per dirti se l'hai 
configurato bene o male...
A titolo di esempio ti posso solo dire che, usando il Qmail, un paio di anni 
fa circa sono stato costretto, per la disperazione, a fare una modifica sui 
sorgenti di qmail-smtpd: cambiai la stringa dell'header "Received" nel caso 
in cui un client aveva accesso in "relay", oppure si era "autenticato" con 
user/pass (in pratica camuffavo, sia l'ip riportato nell'intestazione, che 
l'eventuale dominio inversamente risolto). Ovviamente, per mantenere 
traccia, l'ip del client sparito dal 'Received' lo avevo poi scritto in 
un'altra intestazione custom X-Qualcosa.
Cmq, per capire meglio il problema, posta almeno l'header dell'email segata 
dal tuo SpamAssassin (se puoi, mantieni nell'header l'ip del tuo cliente - 
oppure dicci in quali blacklist si trova quell'ip; controllalo con 
http://www.dnsstuff.com/tools/ip4r.ch?ip=ip.del.tuo.cliente
 )
Ciao


Alessandro wrote:

Leggi qui:
http://wiki.apache.org/spamassassin/DynablockIssues

]
  0.7 RCVD_IN_NJABL_PROXY    RBL: NJABL: sender is an open proxy
                             [82.49.206.165 listed in 
combined.njabl.org
]
  1.9 RCVD_IN_NJABL_DUL      RBL: NJABL: dialup sender did non-local SMTP
                             [82.49.206.165 listed in 
combined.njabl.org
]
  -0.9 AWL                    AWL: From: address is in the auto white-list
E' in una marea di blacklist, molte delle quali elencano IP dinamici.
Il che ci può anche stare, infatti non invia mail direttamente ma fa 
relay attraverso il mio server, ma come fare ad evitare questo 
spiacevole inconveniente? Il cliente ha attivato un servizio di SMTP 
attraverso noi proprio per evitare le problematiche di telecom, ma a 
quanto pare, ore ne ha molti di più di problemi (e non dipendono da me)
[ Skull dove sei?!? :) ]

 rischia di venire segata da (qualunque) SpamAssassin.
Basta mettere mano alle configurazioni di SA:
skip_rbl_checks 1

 E' in una marea di blacklist, molte delle quali elencano IP dinamici.
A mio avviso i check su rbl varie li deve fare Postfix, non SA, proprio
perchè andare a fare inspection sulla catena dei received può essere
molto pericoloso, se non fatto con criterio.

whiplash ha scritto:

Si certo, di soluzioni dal mio lato ce ne sono tante (disattivare rbl, 
whitelist etc) ma questo problema, si verifica solo sul mio server o 
anche sui server remoti? Io mi sono accorto del problema, ma di certo 
uno su @hotmail (sparo un provider a caso) di certo non può accorgersi 
di nulla

 molto pericoloso, se non fatto con criterio.
Certamente, io sul mio server posso risolvere senza problemi in vari modi.
Però, la stessa cosa accade anche sui server remoti dotati di 
spamassassin immagino. Ed in questo caso non posso intervenire.
Di workaround ce ne sono parecchi, ma sono validi solo per la mia rete.
Esiste un modo per correggere questo problema a monte senza girargli 
intorno?
Quello che non capisco è come mai se il cliente invia tramite SMTP 
telecom al mio server, le mail vengono recapitate correttamente, mentre 
se invia tramite il mio SMTP, vengono bloccate (ed il problema non è una 
mailconfigurazione del mio server, ma di blacklist del cliente).
(sinceramente, l'ultimo controllo che ho fatto mediante smtp telecom è 
di 1 settimana fa, forse adesso anche tramite telecom la mail vengono 
bloccate da postfix [le rbl le uso quasi solo su postfix, in questo caso 
i check sono bypassati causa sasl e quindi entra in funzione SA] causa 
blacklist)

 Ed in questo caso non posso intervenire.
In quel caso sono *loro* ad avere una configurazione errata.
L'unico workaround che potresti usare è tentare una riscrittura dei
Received mediante header_checks

 Received mediante header_checks
Ok, ma statisticamente quanti provider hanno SA configurato alla c@zzo 
che filtra in base alle RBL? (ovvio che parlo di provider 'trafficati', 
libero, hotmail, aol, yahoo etc etc)
Perchè se il 95% dei provider non ha questo tipo di problemi, allora non 
faccio alcun cambiamento, sistemo il mio relay e sono a posto.
Se invece il problema è abbastanza frequente, riscrivo gli header.

 di nulla
Se ne hai la possibilità senza pregiudicare la produttività del server, 
prova a tua volta a fare temporaneamente un relay della posta che giunge 
ai tuoi server, verso un provider esterno, e vedere se cambia qualcosa.
Con tutte ste RBL che circolano è diventato un problema non da poco per 
i sistemisti, riuscire a gestire correttamente la posta affinche non 
finisca in black list!!!

 finisca in black list!!!
E' la prima prova che farò appena esco da qui e vado a casa.
Mi mando un paio di mail su libero e su yahoo (.com|.it) per vedere se 
arrivano.

 
http://wiki.apache.org/spamassassin/DynablockIssues
Ottimo link. Alessandro: segui il consiglio di leggerlo.
Ciao


 [1]
Purtroppo, come ti ripeto, non ho una conoscenza tale di Postfix per dirti 
se questa "e' una possibile" soluzione con questo mail server - oppure "e' 
la soluzione canonica" al problema.
Note:
1) qui hai come effetto collaterale di perdere traccia dell'ip di 
provenienza del messaggio: bene da un punto di vista della privacy del 
cliente, ma non per te che fornisci il servizio (IMHO). Io, come ti ho gia' 
detto, lo riporto poi in un header custom (pero' attento a non metterlo in 
'X-Originating-IP' perche' SA controlla anche quello :-) )


 Ottimo link. Alessandro: segui il consiglio di leggerlo.
Già letto, questo spiega come bypassare i controlli sul MIO server, ma
non spiega come assicurarsi che la mail arrivi a destinazione.
Quello che non capisco è se è corretto che la mail venga taggata in
quel modo da SA (corretto ma ovviamente non consigliato) o se i
problemi sono sul mio postfix in fase di invio.
Ma a quanto pare, il problema è il server di destinazione (nel test
del cliente, smtp che server di destinazione erano entrambi miei)
pertanto si spera che grossi provider (yahoo, aol, libero) non abbiano
tali problemi.

 non spiega come assicurarsi che la mail arrivi a destinazione.
...e infatti! :-) , penso proprio che tu non l'abbia letto.
Apri quel link (beninteso: se lo vuoi fare...)
http://wiki.apache.org/spamassassin/DynablockIssues
cerca il paragrafo:
"I'm an ISP, and mails from our customers, using authenticated connections 
from another ISP, are hitting RCVD_IN_DYNABLOCK."
c'e' una parte rigurdante Postfix (da leggere)... poi, piu' sotto, trovi un 
altro link che ti conduce a:
http://dev.riseup.net/privacy/postfix/
In questa pagina, oltre al resto (sempre tutto da leggere), nel paragrafo 
"Postfix 2.3 and later", viene ipotizzata una soluzione (che gia' 
risolverebbe il tuo problema). In fondo alla pagina, poi, c'e' un altro 
rimando (che trovi scritto anche nell'altro mio post):
http://blog.madduck.net/geek/2006.06.30-postfix-auth-anonymisation
Qui, imho, c'e' una spiegazione migliore della precedente.
Infine, in quest'ultima pagina, trovi anche un link ad un'interessante 
discussione sul tema, nella mailing list postfix.devel:
http://thread.gmane.org/gmane.mail.postfix.devel/382/focus=382


 
http://thread.gmane.org/gmane.mail.postfix.devel/382/focus=382


 io ho invece il dubbio che tu non l'abbia letto
Ho letto il documento, a dire il vero non il 100% ma il 90% si.
Sono tutte soluzioni che devo implementare io sul mio server
spamassassin.
Però, il problema non è sul mio server dove posso intervenire ma su
quelli remoti.
Esempio:
io ho una ADSL con ip dinamico di Azienda1
l'smtp messo a disposizione da tale azienda, smtp1, fa schifo ed io
non lo voglio usare.
utilizzo come smtp quello di Azienda2, tramite regolare
autenticazione.
Quando invio un messaggio tramite Azienda2 al TUO (per fare un
esempio) indirizzo mail, SpamAssassin installato sul server dove
risiede il tuo indirizzo email blocca la consegna (o la tagga) perchè
il mio IP è identificato come dinamico (giustamente).
Le soluzioni che mi son state proposte, sono dei workaround da
applicare sullo SA del server di destinazione, ed io non posso
chiamare Yahoo e dirgli: guarda che il tuo antispam e configurato da
cani, vai a leggere questo documento.
Allora mi chiedevo, è un problema del mio server smtp (ma ho capito di
no), o è un problema dello SA di destinazione configurato da cani? Nel
mio esempio, smtp e SA corrispondono allo stesso server, ma il
problema, ripeto, non è la ricezione sul mio server quanto l'invio
verso altri provider in cui non posso avere un feedback se non
mediante l'utente incazzato perchè dopo 2 mesi si è accorto che tutte
le mail inviate non venivano recapitate.
Un conto è dirgli: guarda, probabilmente il provider di destinazione
fa schifo ed ha i server configurati male, un altro conto è dirgli:
hai ragione, il mio server smtp non effettuava relay delle mail in
maniera corretta e il provider remoto giustamente le bloccava.
Aggiungere il tag sasl authenticated (che ad una prima e veloce
analisi non funziona, domani ci guarderò meglio) è una valida
proposta, così nei server di destinazione che fanno fede a tale header
ho una possibilità in più di non essere bloccato come spam. (in questo
caso è una variazione che posso fare io lato smtp)
Ma tutte le altre soluzioni di quel link (come ad esempio aggiungere
una trusted network etc) non sono implementabili dal mio lato smtp ma
solamente lato SpamAssassin che tagga le mail.
Inoltre, se io non avessi avuto SpamAssassim (o non fosse stato
configurato male), questo problema non si sarebbe mai verificato dal
mio lato, ma chi mi dice che altri provider non siano nella mia stessa
situazione? Sto cercando di verificare se è un problema lato SMTP
(quindi un mio problema da risolvere) o se è un problema puramente di
SpamAssassin configurato male (quindi un problema in ricezione, cioè
non mio)
Se poi così non fosse, vuol dire che non ho proprio capito niente e
che lunedì rileggerò tutto con molta più attenzione.

 che lunedì rileggerò tutto con molta più attenzione.
la soluzione proposta in quella particolare situazione è quella di
anonimizzare il primo hop intervenendo sul tuo Postfix, in modo che negli
header non risulti più l'IP del mittente. Il filtro antispam non va toccato
nè da parte nè da parte del tuo smarthost.
per leggerla dovevi seguire il link appena sotto:
http://dev.riseup.net/privacy/postfix/


Preferirei evitare di anonimizzare gli header soprattutto se il
problema non è causato da una mia errata configurazione.
Ho inviato una mail di prova verso libero, 
yahoo.com
, 
yahoo.it
 hotmail
alice ed altri grossi provider ed è arrivata senza problemi. Questo mi
fa pensare che il problema fosse stata una malconfigurazione del mio
SA (ora risolta) per cui non credo sia necessario modificare gli
header.
Come suggerito anche da whiplash, i check sulle rbl andrebbero
preferiti a livello di MTA e non da SA. Il mio SA, causa una mia
dimenticanza in fase di implementazione, rieffettuava gli stessi check
sulle stesse rbl di postfix (con la differenza che SA controlla TUTTI
gli header, bloccando anche mail provenienti da host autenticati).
Disattivato il check di SA, sembra essere tornato tutto alla normalità.

 Disattivato il check di SA, sembra essere tornato tutto alla normalità.
meglio così.
io avevo capito da questa tua frase:
"Ma il server remoto che riceve posta, mi stronca i messaggi perchè 
proveniente da un IP dinamico (quello del cliente)."
che il problema non dipendesse dal tuo Spamassassin.

 che il problema non dipendesse dal tuo Spamassassin.
Quando io ho fatto la prova con il cliente, l'smtp era il mio come anche 
il server remoto su cui recapitare il messaggio di prova. E SA segava il 
messaggio.
Questa cosa mi ha fatto pensare: non è che anche altri grossi provider 
possono segarmi il messaggio perchè proveniente da IP dinamici? Mi era 
venuto un dubbio.
Poi ho fatto delle prove ed a quanto pare la posta viene ricevuta 
correttamente.
Mi stavo chiendendo quindi se a livello di SMTP potessi fare qualche 
cosa (senza cambiare gli header, ma semplicemente una soluzione più 
ortodossa)
Rileggendo la mia mail mi sono espresso male.
Questa frase:
"Ma il server remoto che riceve posta, mi stronca i messaggi perchè
proveniente da un IP dinamico (quello del cliente)."
doveva essere interrogativa:
"Ma non è che il server remoto che riceve posta, mi stronchi i messaggi 
perchè proveniente da un IP dinamico (quello del cliente)?"
Comunque problema risolto