[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: