Re: exim or postfix
On Fri, Nov 12, 2004 at 05:12:34AM +0000, John Goerzen wrote:
> > 2. postfix does support filtering during the SMTP transaction. the difference
> > is that the postfix author tells you up front that it is inherently problematic
> > (for *ANY* MTA, not just postfix) because of the potential for SMTP timeouts if
>
> Yes, it does now (I realized that one last week), but its whole
> filtering support sucks. (Having to set up a SMTP server and client for
> every filter is just nasty.)
i like the way it works. makes it easy to model the flow of mail from
component to component.
btw, if setting up a chain of filters, you don't need to loop it through postfix
each time.
i.e. don't do this:
postfix -> filter1 -> postfix -> filter2 -> postfix -> filter3 -> postfix
do this instead:
postfix -> filter1 -> filter2 -> filter3 -> postfix.
> The only featureful free software filtering system for Postfix that I've
> seen in Amavis. And it sucks too. Slow, unreliable, a huge memory hog,
> leaves files all over on the disk, etc, etc, etc.
again, i like it (amavisd-new, that is). it is a bit of a memory hog (SA is
*much* worse), but it's not unreliable and it doesn't leave files all over the
place, it uses /var/lib/amavis and cleans up after itself. speedwise, it's not
too shabby - insignificant time overhead compared to the time taken by SA or
even clamav.
> That said, exiscan-acl is a lot faster than postfix+amavis on my system.
> Maybe it's because it uses about 500k of memory with a C program instead
> of 40MB of memory wiht a Perl program, or because it doesn't have to
> incorporate a full SMTP server, dunnno.
if you use SA with it, though, it still ends up using that 40MB per process.
(mine uses about 55MB, but i have thousands of local rules, scoring spam
domains and spam phrases etc....generated from the same text files i use to
generate my junk map, body checks, header checks, etc. my anti-spam system has
evolved over the years - as new anti-spam technologies come along, i check them
out and incorporate the useful ones into my system)
the nice thing about amavis is that you tell it to pre-fork as many processes
as you think you'll need (adjust according to empirical observation) and you avoid
the overhead of starting up perl and compiling SA for every message.
dunno if exiscan-acl does something like that - i'd guess that it does because
it is an obvious optimisation. either way, whether pre-forked or not, each SA
process uses that much memory, and takes the same amount of time to run all
it's checks.
i could probably get away with having SA checks during the SMTP stage. but I
agree with Wietse's attitude that a system that only works some of the time is
fundamentally broken. by doing content-filtering later and DISCARDing messages
with scores over 13.0, i get pretty close to the same benefit without any of
the risk.
(it used to be 15.0 until recently, but i started getting quite a few nigerian
type spams in my tagged SPAM folder, at least one per day, with scores of 13.1
and 14.6 and so on, so i lowered the discard score to 13)
> > e.g. my spam-stats.pl report for last week (this is for a little home mail
> > server with about half a dozen users):
>
> That is very interesting. However, you apparently have the luxury of a
> great number of false positives. That is very nice, but it is not a
> luxury I have.
no, i have very few false-positives. whenever i've grepped for "reject:" in
the logs and examined them in detail, i've rarely (never that i can recall, but
i'm probably forgetting some) ever found any false positives. the rejects really
are all spam.
> > ganesh:/etc/postfix# spam-stats.pl /var/log/mail.log.0
> > 2 RBL bogusmx.rfc-ignorant.org
> > 4 Unwanted Virus Notification
> > 4 ETRN
>
> Weird, people are just sending ETRN commands to you?
yep. happens a few times every week. i have no idea why....maybe they're
probing me for some vulnerability in some ancient version of sendmail or
something.
> > 15 RBL taiwan.blackholes.us
>
> I assume you are blocking an en *entire country* here?
yep. i don't know anyone in taiwan, and if anyone there *really* needs to
communicate with me they can use yahoo or hotmail or something. if it matters
to them, they'll find a way....not my problem, i don't care.
of course, this is my HOME mail server. i don't use any of the blackholes.us
RBLs at work. there, i have to be a lot more conservative about spam blocking.
> > 26 RBL Dynablock.njabl.org
>
> My own static DSL IP is on this one. Lots of people have legit reasons
> for not using their ISP's sucky, crappy mail servers.
fair enough, they may have legit reasons, but i don't need the potential for
receiving mail from them more than i need to block the spam and viruses that
come from dynamic IPs.
it's not difficult or expensive (it can even be free if you have the right
contacts) to arrange to relay your mail through a static IP mail server, using
uucp or SMTP AUTH or pop-before-smtp or any one of dozens of alternative
authentication methods.
IMO, if someone couldn't be bothered doing that, i couldn't be bothered
receiving their mail. i get more than enough mail as it is, it's not as if
it's going to distress me to not get one more.
> > 28 RBL hongkong.blackholes.us
> > 39 RBL brazil.blackholes.us
>
> I have to talk to people in this country, too.
i don't.
> > 202 RBL dul.dnsbl.sorbs.net
>
> Ditto on this one.
yep, ditto.
> > 1361 RBL cn-kr.blackholes.us
>
> Have to talk to Chinese people too...
not me. most of my spam comes from Korean IP space these days. a few years
ago, it was from Chinese IP space. as with taiwan, i don't need or want mail
from either country.
> > 4779 User unknown
>
> I am stunned at how many attempts I get to send mail to non-existant
> accounts, too.
spammers sell their lists based on the number of addresses. they don't care if
the addresses they are selling actually exist.
> > 22256 Bad HELO
>
> And I get many legitimate e-mails with a bad HELO. In fact, I would
> argue that your rule here is wrong. If I send you an e-mail from my
> laptop, it is not going to send you an address of a server that can
> receive mail (or has a DNS entry) in HELO, but everything else will be
> valid, and I argue that this is OK.
on my system, a good HELO is any real FQDN (except for my own - nobody outside
my network should HELO as my domain). this is a rule i've tightened over the
years, it used to be anything that seemed like an FQDN, now i require that the
FQDN actually exists in the DNS.
> Anyway, thanks for the info. It's always interesting to see what other
> people are doing.
of course. TMTOWTDI
> And now I know where not to mail you from. :-)
:)
craig
--
craig sanders <cas@taz.net.au> (part time cyborg)
Reply to: