Newsgroup: it.comp.os.linux.sys
Titolo: Spam da postmaster

Per quale cavolo di motivo vorrei sapere, non riesco a bloccare i
messaggi provenienti da postmaster su postfix?
Usando postfixadmin ho anche eliminato l'alias postmaster@dominio, ma
ho sempre una valanga di messaggi verso indirizzi inesistenti
provenienti da postmaster@dominio, che non riesco a bloccare in alcun
modo... qualche suggerimento?
Sto usando postfix con autenticazione sasl e account su mysql
Luca

 modo... qualche suggerimento?
Se č quello che credo io,
notify_classes                  = resource, software
e vivi felice.
-- 
http://bofhskull.wordpress.com/


Un bel mondo, nel quale mi piacerebbe girare armato!

 mail server che riceve la mail mandi lo spam verso il 'from'.
Aggiungo: visto che le E-Mail dovrebbero essere "teoricamente" interne (da
un utente del dominio ad un altro utente dello stesso dominio), ha senso:
a) permettere le E-Mail con mittente @tuodominio SOLO da utente
autentificati
b) controllo SPF + informazioni SPF del tuo dominio che permettono come
Server mittente solo il tuo Server (ho scritto un piccolo HowTo anche per
Postfix. Lo trovi sul sito del buon Davide Bianchi)
I miei due cent
Luca Bertoncello
(
luca...@lucabert.de
)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 l'indirizzo "sbagliato". La mail semplicemente scompare.
Posto che ciascuno sui suoi sistemi fa ciň che gli pare (my network, my 
rules), a me 'sta roba del dev-null mi par follia... :-\
-- 
http://bofhskull.wordpress.com/


E lo stesso messaggio il relayhost lo passa cmq al deliveryhost
(ovvero dove stanno le caselle di posta) che naturalmente lo rifiuta
una seconda volta, il problema è che sotto "attacchi" pesanti questa
situazione tende a bloccare il passaggio dei messaggi buoni, quel che
vorrei riuscire a fare è bloccare le email verso indirizzi inesistenti
solamente nel relayhost, trovare una soluzione allo spam da postmaster
verso gli indirizzi buoni, al momento c'è sia autenticazione SMTP che
spamassassin che li blocca, ma vorrei capire come mai i messaggi da
postmaster passano ugalmente
Luca

 postmaster passano ugalmente
Sicuro che non stai parlando di "messaggi" che vedi solo nei log e che 
magari sono associati a "status=deliverable"?
Perchè in quel caso sono solo i probe effettuati dal codice di verifica 
dei destinatari, ma non generano alcuna mail...
-- 
http://bofhskull.wordpress.com/

 Postfix. Lo trovi sul sito del buon Davide Bianchi)
E questa cosa mi interessa molto, ora mi documento, grazie mille
(anche a davide e agli altri ovviamente)
Luca

 dei destinatari, ma non generano alcuna mail...
Mi spiego meglio, io ho 2 mail server, uno esterno, che fa solo da
filtro con amavis e poi rigira tutti i messaggi al server interno per
il delivery, il problema è che dai log io vedo la stessa cosa su
entrambi i server, cioè il primo server logga un reject, poi sembra
che rigiri cmq la mail al server interno che la rifiuta una seconda
volta, e ieri questa situazione mi ha messo in crisi la macchina
interna, dato che per via del gran numero di reject non scriveva i
messaggi buoni nelle maildir, accodandoli invece da qualche parte... è
questo che non mi torna di tutta la faccenda!!!!

 questo che non mi torna di tutta la faccenda!!!!
Credo tu debba approfondire un poco l'architettura di quello che hai in 
casa, perchè temo che il problema sia in realtà questo...
Dal messaggio che incollavi sopra si desume che il tuo mailserver 
"esterno" effettua verifica dei destinatari tramite il servizio di 
verification interno a postfix.
Questo funziona così:
quando il sistema mittente specifica quale è il destinatario (quindi al 
termine della fase "RCPT TO"), il tuo tier_1 apre una sessione SMTP 
verso il tier_2 (il sistema "interno"), simulando la consegna di un 
messaggio proveniente da postmaster@tuodominio (comunque configurabile) 
all'utente in questione.
Non completa la sessione SMTP, ma arriva solamente fino alla fase "RCPT 
TO". Se il tier_2 risponde "250 OK" significa che il destinatario esiste.
Se risponde "550 User unknown in virtual mailbox table" significa che 
non esiste.
I log di reject che vedi sul tier_2 non sono mail "vere", ma queste 
sessioni di probe in azione.
Per evitare di effettuare il probe ad ogni singola mail, il servizio di 
verification ti consente di mantenere una cache dei probe già effettuati:
address_verify_map              = btree:/etc/postfix/verify
address_verify_negative_refresh_time    = 1h
address_verify_negative_expire_time     = 5d
Il che ti consente di "scaricare" un poco il sistema di backend, 
evitando di domandargli sempre le stesse cose.
Nota che questo, tuttavia, serve poco a calmierare il carico se i probe 
vengono fatti in direzione di indirizzi sempre diversi, dato che in tal 
caso non è possibile avvalersi della cache.
Per risolvere questo caso, hai due sistemi, non necessariamente esclusivi:
1) spostare la fase di verifica dei destinatari in una posizione del 
ruleset che avviene "meno spesso". Ad esempio, se fai utilizzo di 
filtraggio in fase envelope (DNSBL, ad esempio), puoi spostare la 
chiamata a "reject_unverified_recipient" *dopo* l'applicazione delle 
varie DNSBL. Questo fa sì che apri una chiamata al backend solamente per 
le mail che verranno accettate dal ruleset, e non per quelle che tanto 
non andranno da nessuna parte.
2) rimuovere il codice di verification e utilizzare una più consona 
"relay_recipient_maps", appoggiandola alla stessa base-dati che utilizzi 
sul tier_2: il codice di verification ti è necessario *solamente* 
qualora tu non abbia alcun controllo sulle utenze presenti a tier2. Ad 
esempio nel caso in cui tu stia gestendo un sistema di frontend per un 
mailserver che è gestito integralmente da un tuo cliente...
Bye.
-- 
http://bofhskull.wordpress.com/

 casa, perchè temo che il problema sia in realtà questo...
In effetti, andando ad approfondire la cosa il problema sembra proprio
quello, l'ho messo su qualche anno fa, quindi è probabile che abbia
ingenuamente sorvolato su questo tipo di problema, ovviamente
dimenticandomene finchè non sono stato nella cacca... un'altra lezione
da imparare
 Il tier1 verifica soltanto l'autenticazione, filtra e rigira tutto
quello che riguarda i domini in
transport_maps= hash:/etc/postfix/transport
al server interno, il quale poi interroga il DB. quindi si comporta
effettivamente come dici tu.
Ora vedo un pò, tra i tuoi consigli e quelli di Luca Bertoncello ho un
paio di idee su come modificare i 2 mailserver per risolvere questi
problemi (e darmi un pò del deficiente per non averci messo prima le
mani!)
Grazie Ancora
Luca