On Sun, Dec 01, 2002 at 06:04:27PM -0600, Russell Mosemann wrote:
> This is not such a good idea. The solution would be to put SpamaAssassin
> in front of postfix, and that would hobble postfix to a large extent.

That's why I want to insert SA at the same place in postfix processing as
the body_checks filtering. I don't want to front-end Postfix, for all of the
reasons you cite. (BTW, I've been more successful with stopping spam with
the smtp_* filtering than I ever was with sendmail.)

If I wanted to simply drop spam on the floor, I could do that now with a
little bit of kludging. I don't. I want to abort the transfer of the spam.
The body_checks filtering does that, but it's both inflexible and
considerably less good at catching spam than SA. (I don't particularly want
to reinvent spam detection; that's why I got SA in the first place.)

As I think about it, perhaps the best way to do this would be to have the
message run through SA (in the form of spamc/spamd, to lessen overhead)
right before the "250 OK: queued as <id>" message is sent; the return code
would then determine whether the message is queued, or else rejected. This
would seem like a pretty simple hook to add, if it's not there already.

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