On Sat, 2008-12-20 at 19:35 +0900, Stephen J. Turnbull wrote: > > Courier doesn't need milters. Maildrop can be run in what's called > > "embedded mode" which is effectively the same thing. > x` > No, it's not the same, not for the purpose of deciding whether > *Courier* needs milters.
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. Maildrop in embedded mode _is_ a milter - a highly programmable one. Using maildrop, an email can be fed to any program for analysis - shell script, SpamAssassin, etc. - which need not be SMTP-aware, and the output and exit code of said program can be used to determine the course of an SMTP session. Yes, it's desirable when possible to reject problem email at the front door, but it's not a religion with me. I've done my time in the spam-fighting trenches, probably more than most mail admins. I do understand email pretty well, and know how to implement decisions I make about how to handle problem email. It's just these decisions are probably not the same ones you'd make. I'm not going to change my fundamental decisions on how I handle problem emails on my system, which aren't doctrinaire and may not be e-politically-correct by some standards, but I've kept this thread going because I rather selfishly find that occasionally someone tosses out a Good Idea that I may be able to use :-) 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. 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. 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. 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 :) -- Lindsay Haisley | "Everything works | PGP public key FMP Computer Services | if you let it" | available at 512-259-1190 | (The Roadie) | http://pubkeys.fmp.com http://www.fmp.com | | ------------------------------------------------------ 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