Antispam and antispoofing measures in MTAs are *definitely* a form of
firewalling, just dealing with application data instead of packets.
That's one reason I insist on giving my production mail setup a strong
sense of direction, and why the ability to have different Postfix
instances listening on different addresses with different rules is so
valuable.

WRT /offers/ REJECT -- I thought we had gone on to discussing how to
deal with various common aspects of Jess's spam problem, but hey, if
a DROP action there is what you'd rather do then that's fine. I have
told a couple of folks I implemented the silent DROP against the
postfix-20010228-pl04 distrib, and it only works for filtering done
in "cleanup" so far, but I agree that it's damn useful. Since most of
the spam-filtering occurs in header_checks / body_checks anyways, even
this limited capability helps reduce the bandwidth and queue space that
rejection otherwise entails.

I can attempt to dig out my patches and post them if folks want, but
frankly I would trust Wietse to implement it the right way and make it
behave uniformly across all the places where checks are done. It's a
little harder than you might think because even if you want to DROP as
early as in smtpd_client_restrictions, you have to fake acceptance of
the ENTIRE message and then silently dump it on the floor. That was
more coding than I wanted to do [and/or trust myself to get right] at
the time.

There's also this legacy school of thought that you must never, ever
drop mail unless you absolutely can't deliver it to postmaster or write
it to /tmp/dead.letter or whatever, but I've long since dismissed that
as so much bunkum.

_H*
-
To unsubscribe, send mail to majordomopostfix.org with content
(not subject): unsubscribe postfix-users

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]