on 12/20/08 10:41 AM, Lindsay Haisley said:
A "milter" is just an MTA component/plugin that reflects user-space
(outside the MTA) decisions on spam/viruses back to the SMTP dialog so
that a receiving server can reject an email for cause without generating
a backscatter email to the envelope sender.
That is one possible description of a milter, yes.
But that does not describe all possible milters, no.
You are correct that milters sit outside of the MTA itself, but their
purpose is to provide different tools to the "mail filter" process than
are normally available inside the MTA itself. What those different
tools are will depend on the milter.
Some of them are seriously anal about checking exact conformance to the
way certain headers are supposed to be used, because a certain class of
spam tends to get these headers wrong in subtle ways.
Some of them will check the NS records of the domain of the sending MTA,
or the whois registration of the network of the sending MTA, so that you
can ban entire classes of senders based on whether or not they share the
same nameserver as known spammers (because spammers tend to re-use the
same nameservers over and over again, regardless of how many thousands
or millions of domains they register), or they tend to re-use the same
network registrars.
Some milters will use tools like "p0f" to do a passive OS check on the
incoming connection (much like the OS determination techniques used in
nmap, but using purely passive means), and then take one of several
different actions based on what kind of machine is making the incoming
connection -- reject them outright if they're running an OS you don't
like (since >99% of all spam comes from Windows boxes, this can be a
huge win all by itself), or maybe put them into a tarpit (to make them
use up their resources), or whatever.
Milters can do virtually anything, in any way they want. You can write
your own milters in Perl or any other language you want.
Unfortunately, milters are not widely supported outside of modern
versions of sendmail and postfix.
BTW, as I mentioned, about 80% of the spam _I_ (personally) get is
rejected by courier based on RBL lookups, and I assume the percentage is
similar for other system users. I have a cron job which generates a
daily report on these rejections for me, and anyone else who wants one.
I have my own scripts that I've written for the same purpose. Your
statistics do not accurately describe the situation that I personally see.
At UT Austin, we reject ~95% of all incoming mail at the SMTP dialog
level, because we use Ironport e-mail security appliances that check the
incoming connection against the SenderBase reputation system, and
SenderBase has several hundred different inputs that are used to
calculate an overall score for that sender. They monitor all the major
RBLs (and a lot that you've never heard of), but they also consider what
the registered nameservers are for the sending domain, who the
registered owner of the network is in whois, and all those other things
that you might want to check.
We reject another ~2% of the total with content-based checks.
The number of rejections I see in the report for my personal email
varies between about 200 and 800 or so a day, and has remained in this
range for several years. Frankly, I don't believe rejecting an SMTP
transaction out front makes one whit of difference to spammers, and I've
seen no arguments to indicate that it does.
Do some research on the economics of spam, and how these guys get their
money. It is an entire black economy, and they get paid based on their
deliverability, just like any other bulk mail service.
A huge amount of this spew
comes from Asia, Russia, South America, and my guess is that it's either
coming from virally infected / hacked boxes or from rogue servers that
crank out terabytes of this crap, and in any case the people sending it
don't give a damn whether any particular target (victim!) system rejects
1% or 99% of it.
Some care, some don't. But you don't know in advance which type of
spammer you have connecting to you.
It's just that, by rejecting this stuff out front, one gets the visceral
satisfaction of knowing that some spammer, somewhere _might_ be annoyed
or inconvenienced by seeing the bounce notices from their server. I've
heard all the arguments about CPU usage and system load involved in
accepting and processing spam, but my service is a relatively small one
and my system load generally runs under 1.0, even with all that spam
coming in :)
If more people rejected spam outright during the SMTP dialog, we would
make a measurable impact on the spammer economy. So long as there are
plenty of people who are happy to just throw it away after-the-fact,
then the spammers continue to win.
--
Brad Knowles
<b...@shub-internet.org> If you like Jazz/R&B guitar, check out
LinkedIn Profile: my friend bigsbytracks on YouTube at
<http://tinyurl.com/y8kpxu> http://preview.tinyurl.com/bigsbytracks
------------------------------------------------------
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
