On 2004-11-11, Craig Sanders <[EMAIL PROTECTED]> wrote: > On Thu, Nov 11, 2004 at 09:25:52PM +0000, John Goerzen wrote: > a few comments, though: > > 1. "synchronization detection" - postfix has done this for years, except that > it's called "reject_unauth_pipelining". you enable it as one of the > smtpd_*_restrictions.
Thanks. I was not aware of that. > 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.) 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. > the filter takes too long to run (SpamAssassin, for example, could take ages > to > complete regardless of whether it's run from exim or postfix...especially if > it's doing DNSRBL and other remote lookups), and he recommends that you don't > do it. > > other MTAs blithely ignore the potential problem and tell you to go ahead and > do it. No, you're quite right, and I have seen all those warnings. 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. > 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. > 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? > 6 body checks (VIRUS) > 12 header checks (VIRUS) > 15 RBL taiwan.blackholes.us I assume you are blocking an en *entire country* here? > 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. > 28 RBL hongkong.blackholes.us > 39 RBL brazil.blackholes.us I have to talk to people in this country, too. > 76 Local access rule: Helo command rejected > 114 Relay access denied > 145 SpamAssassin score far too high > 148 body checks (Spam) > 163 Local address forgery > 200 strict 7-bit headers > 202 RBL dul.dnsbl.sorbs.net Ditto on this one. > 212 RBL sbl-xbl.spamhaus.org I catch a LOT of spammers with that one, and very little, if any, collateral damage. > 253 header checks (Spam) > 288 Need FQDN address > 297 Recipient Domain Not Found > 429 RBL list.dsbl.org > 517 Local access rule: Client host rejected > 687 Greylisted delivery attempt > 717 Dynamic IP Trespass > 1361 RBL cn-kr.blackholes.us Have to talk to Chinese people too... > 1463 Sender Domain Not Found > 4779 User unknown I am stunned at how many attempts I get to send mail to non-existant accounts, too. > 6422 Recipient address rejected > 6970 Local access rule: Sender address rejected > 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. Anyway, thanks for the info. It's always interesting to see what other people are doing. And now I know where not to mail you from. :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
