Re: exim or postfix
On 2004-11-11, Craig Sanders <cas@taz.net.au> 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. :-)
Reply to: