>Hi List!
>New viruses, spam, etc. are being smarter than most anti-spam/virus technics
>nowadays.
>I am facing some kind of trojans that infect many clients computers with
>broadband connection, and start sending a lot of emails to yahoo.com.tw or
>tiscali.it for example.
As always, when you increase your filtering aggressiveness, you'r
going to catch a few legit IPs, so if that's a problem, stop reading now.
Most crap comes from
1) IPs with no PTR
and
2) subscriber access networks
Advanced IMGate has a special restriction class for PTR-less IPs
where the filtering is more agressive.
For subscriber access networks,
reject_rbl_client zen.spamhaus.org=127.0.0.4,
reject_rbl_client zen.spamhaus.org=127.0.0.11,
and greylisting work very well. The above RBLs are also applied in
the PTR-less restriction class.
At the end of the list, SAV catches a lot.
The above is for inbound policies.
>For example, I do:
>
>grep 'client=unknown\[ip.ad.dr.es' /var/log/maillog | awk -F: '{print $4}' |
>./one_line_q.pl | cut -d " " -f 2 | postsuper -d -
>
>Once I have the ip.ad.dr.es. And, yeah, deleting ALL emails from this IP in
>queue.
too late, IMGate should apply more aggressive policy before the msgs
are queued.
>So,
>Question 1 is : How to get the ip.ad.dr.es without waiting the 'pflogsumm'
>daily report, and
>Question 2: Is there a way to raise Postfix self-defense to avoid spam-storm
>from the 'inside' ? ANVIL maybe ?
For outbound, you could run SAV/RAV to keep your infected Imail users
from spamming.
And you network subscribers must submit only via SMTP AUTH to Imail,
not to IMGate directly.
You should also have outbound port 25 blocked, to prevent
direct-to-MX spamming.
Len
