Newsgroup: it.comp.os.linux.sys
Titolo: spamassassin tag outgoing mail

Salve,
sono nuovo dell'ambito mailserver, e scusate se la domanda è banale.
Spamassassin mi inserisce nel subject delle mail, che superano la soglia,
il tag che ho impostato per identificare lo spam.
Cercando su internet non sono stato capace di trovare una soluzione...
L'unica che ho trovato prevede di utilizzare due porte differenti, 
attraverso
le quali ascoltare per le mail in ingresso, e inviare le mail in uscita.
Mi sembra strano che non esista un semplice modo per farlo...
Utilizzo Debian Etch aggiornata, SpamAssassin 3.1.7-2, Postfix 2.3.8-2+b1.
Le email vengono passate a spamassassin con:
(
master.cf
)
smtp      inet  n       -       -       -       -       smtpd -o 
content_filter=spamassassin
spamassassin    unix    -       n       n       -       -       pipe 
user=spamd argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} 
${recipient}
Grazie!
Buon pomeriggio,
Gabriele

 
trusted_networks in 
local.cf
?
oppure configuri il tuo mta per non scansionare email che vengono da 
sessioni autenticate o provenienti dalle relay nets, ma questo dipende 
dall'mta e non da spamassassin.
Ah comunque se spamassassin ti marca le email in uscita come spam i casi 
sono 3:
1) Hai configurato male spamassassin (required score troppo basso ecc...)
2) Lavori per una ditta che vende Viagra
3) I tuoi utenti mandano spam (qualche worm nella rete interna?)
Vedi tu

]
	*  0.5 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL
	*      [85.18.136.98 listed in 
zen.spamhaus.org
]
	*  2.9 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL
	*  1.6 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address
	*      [85.18.136.98 listed in 
dnsbl.sorbs.net
]
	*  0.1 RDNS_DYNAMIC Delivered to trusted network by host with
	*      dynamic-looking rDNS
	* -0.8 AWL AWL: From: address is in the auto white-list
::CUT::
To: 
X...@gmail.com
Subject: [SA: SPAM9.4] prova
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Prev-Subject: prova
prova
:::::::::::::::::::::::::::::::::::::::::::::::

 C'č qualcosa che mi sfugge...
Beh, la cosa e' banale! Visto che SpamAssassin e' stato pensato per
controllare le E-Mail in arrivo e non quelle in partenza, lui considera
tutte le E-Mail come E-Mail in arrivo al tuo Server.
In questo caso si nota subito che l'IP 85.18.136.98 (l'IP della TUA
macchina, dalla quale hai spedito l'E-Mail) e' parte di un pool di IP
dinamici che, come tali, sono da considerarsi a rischio (Zombie, Bot, et
similia) e quindi sono bloccati da un numero sempre crescente di Servers.
SpamAssassin ti informa proprio di quello e cerca, nei suoi limiti, di
bloccare l'E-Mail.
Nel tuo caso, e' ovvio che l'IP sorgente sia dinamico (e' cosi per quasi
tutti), ma tutti gli altri non fanno il controllo di Spam sulle E-Mail in
uscita e lo SpamAssassin dall'altra parte vede solo l'IP del Server che ha
spedito l'E-Mail (che, si spera!, NON ha un IP dinamico).
Ripeto: non tentare di risolvere il problema da SpamAssassin, che il
problema NON e' li. Di a Postfix di passare a SpamAssassin (e, si spera!,
anche a un Virus-Scanner, zB: ClamAV) SOLO le E-Mail in ingresso.
Ah, e per ridurre un po' il carico e tagliare fuori un po' di Spam sicuro,
puoi anche pensare di implementare i tests di Greylist e SPF!
Ciao
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

 Luca Bertoncello
G.

 DNS. Devo cambiare registrar!
Beh, questo sarebbe gia' un motivo per cambiarlo. Ma il test, cosi' come
il controllo Greylist, lo fai senza dover rendere conto a nessuno e senza
fare cambiamenti nel DNS.
Tempo addietro scrissi questo articolo a proposito:
http://www.soft-land.org/articoli/greylist
Dagli un'occhiata!


 Luca Bertoncello
G.

 Per i tests è un'altra cosa inserita nella lista "cose da fare" :)
Io la metterei al primo posto... Da quando ho implementato SPF e Greylist
(e usando anche le DNSBL), il carico di SpamAssassin e ClamAV si e'
dimezzato...
Ti sconsiglio invece il controllo per i DomainKeys. Sebbene in teoria sia
un sistema eccellente nel momento in cui sei iscritto ad una Mailing-List
hai praticamente la certezza di avere problemi, visto che al momento la
totalita' dei gestori di ML maltratta gli Headers quanto basta per far
fallire sistematicamente il controllo DomainKeys.


 Luca Bertoncello
Gabriele
[1] 
http://english.keyweb.de/keyweb.shtml
[2] per es: 
http://www.math.lsa.umich.edu/mmss/coursesONLINE/chaos/chaos6/index.html
      e          
http://warp.povusers.org/Mandelbrot/
[3] per es: 
http://forum.roboitalia.com/forumdisplay.php?f=42
      e		
http://robotik.inflomatik.info/

 e studiare come funziona OpenCV[3].
Buon divertimento! :)


 (devo cercare quella di SA) e qualche NG.
prova a mettere in 
main.cf
smtpd_sasl_authenticated_header = yes

 le palle...
Sě, ma qual č il tuo obiettivo? Vuoi che la posta in uscita passi attraverso 
spamassassin oppure no? Perché non "separi" posta in uscita e posta in 
entrata usando, per la prima, submission?

 
A che pro?

 ma cercare di capire sicuramente male non mi fa :)
nagios
spluciati anche bene i log di sistema

 il tag che ho impostato per identificare lo spam.
non è molto chiaro il quesito.
Se il tuo problema è evitare che le mail mandate dai tuoi utenti *locali*
verso l'esterno (altri server) vengano controllate da sa, la RFC 2476
(
http://www.faqs.org/rfcs/rfc2476.html
) dice chiaramente al paragrafo 3.1
che per questo scopo DEVI usare una porta a parte, la 587 (submission,
appunto). Non è questione di /possibilità/, si *deve* fare proprio così. A
questo punto, avrai postfix in ascolto su *due* porte: la 25 per il
traffico in entrata da altri server, la 587 per le email inviate dai tuoi
utenti.

 utenti.
Scusa se mi intrometto, ma, a parte il fatto che uno PUO' o meno
implementare il submission, ho sempre visto MTA che **NON** scandivano la
posta in uscita.
Anch'io ai tempi in cui avevo ancora Postfix feci cosi' (non ho piu' i
files di configurazione), e lo faccio anche ora con Exim.
E lo fanno tutti.
Dire che DEVI usare Submission per evitare che la posta in uscita venga
scandita e' un po' una ca$$ata... :)


 non è molto chiaro il quesito.
una altro modo è configurare postfix per aggiungere un header a ciascun
messaggio inviato dagli utenti locali (ovviamente autenticati) quindi
utilizzare le whitelist di sa.
Per aggiungere un header devi utilizzare l'azione PREPEND all'interno di un
file che contiene le regole di controllo degli header (che devi crearti).
http://www.postfix.org/header_checks.5.html
Per le wl di sa, guarda la documentazione

 scandita e' un po' una ca$$ata... :)
dipende dai punti di vista...
se il suo problema è evitare la scansione dei messaggi locali, la RFC 2446
fornisce un modo rapido ed infallibile per determinare chi sta inviando un
dato messaggio: gli utenti locali usano la 587, tutti gli altri la 25. Non
è *l'unico* modo, è quello più semplice e più conforme alle regole: la RFC
dice di fare in questo modo, è stupido inventarsene uno diverso. 
Volendo giocare, esistono alcuni altri metodi per ottenere lo stesso effetto
con postfix (guarda l'altro post). Però sono più complicati e *molto* meno
aderenti alle regole che presidedono alla gestione delle email.
Certo che si può fare, tutto si può fare con postfix. Però è una fatica
molto inutile inventarsi un sistema complicato per ottenere un risultato
che può essere comunque raggiunto in un'altra maniera.

 scandita e' un po' una ca$$ata... :)
Usare submission è cosa buona e giusta.

 bypassare SA.
eh, gentilmente, puoi dirmi dove? o devo tirare a indovinare?
ora, è palese che io non ho ben chiare le idee su come funzioni postfix 
in generale,
e in particolare il 
master.cf
 di postfix, dal quale invoco spamassassin...
Non riesco comunque a capire come possa un permit_sasl_authenticated 
influire su
questa situazione...
smtpd_recipient_restrictions =
         permit_mynetworks,
         permit_sasl_authenticated,
grazie comunque

 
Ok!
mi studio questa soluzione a cui sinceramente non avevo pensato!
grazie :)))

 utenti.
inizio a leggere e spero di non farci l'alba :P
Grazie e buona serata!
Gabriele

> appunto). 
aioe ti devo fare un santuario in montagna! :P
credevo che sarebbe stato molto più difficile...e invece! :)))
per i posteri:
master.cf
smtp      inet  n       -       -       -       -       smtpd -o 
content_filter=spamassassin
submission inet n       -       -       -       -       smtpd
   -o smtpd_enforce_tls=yes
   -o smtpd_sasl_auth_enable=yes
   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
e sui client cambiare porta a 587.
Grazie ancora!!!! :)))))

 grazie comunque
Invento sul momento (io uso amavis), per cui dovresti verificare la 
sintassi.
In 
main.cf
:
#
smtpd_restriction_classes = submiss
submiss =
            permit_sasl_authenticated,
            check_recipient_access pcre:/etc/postfix/recipient_access,
            permit_auth_destination,
            reject
smtpd_recipient_restrictions = submiss
#
In /etc/postfix/recipient_access
#
/^abuse\@/           DUNNO
/.*/                 FILTER amavis:[127.0.0.1]:10025
#
in 
master.cf
#
smtp-amavis     unix    -       -       y       -       2       smtp
     -o smtp_data_done_timeout=1200
     -o smtp_send_xforward_command=yes
     -o disable_dns_lookups=yes
     -o disable_mime_output_conversion=yes
     -o max_use=20
#

 /.*/                 FILTER amavis:[127.0.0.1]:10025
Leggasi:
/.*/                 FILTER smtp-amavis:[127.0.0.1]:10025

]
segui il link che ti viene proposto e...

 avresti 
(forse) capito,
come l'ho capito io, del perchč spamassassin mi inserisce quei/quel tag.