individual User spamassassin settings during lmtp delivery

[Kendrick Vargas]

Just wanted to chime in on this thread and note that this also answers
Nick Fisher's question of why I do my setup (multiple instances of
postfix) the way I do.

On Mon, 19 Jan 2004, Romeo Benzoni wrote:

> Start Header!
> On Mon, 2004-01-19 at 16:24, James A. Pattie wrote:
> > Start Header!
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Rob Siemborski wrote:
> > | On Mon, 19 Jan 2004, Romeo Benzoni wrote:
> > |
> > |
> > |>So my specific questions are:
> > |>
> > |>1. is my approach wide of the mark or are there better, smarter
> > |>solutions to achieve this?  (I've read about people doing this using a
> > |>deliver wrapper which calls spamassassin and then deliver. but I don't
> > |>like this kind of "fork and exec orgies")
> > |
> > |
> > | Implementing the spam sieve extension is probably a better way of doing
> > | this (rather than wedging it into deliver() directly).
> >
> > Or you could use MailScanner to scan the e-mails as they come into the box and
> > then the delivering instance of your mta (sendmail, exim, etc.) just does normal
> > ltmp.  MailScanner attempts to be pretty resource friendly as it scans bunches
> > of e-mails at a time (if they are available) rather than forking off multiple
> > spamassassin instances, etc.
>
> for now I'll do virus and spamassassin processing during smtp stage, but
> at the smtp stage I'll have no clue what local users this message gets
> to. so I can't load individual spam rules on a per user basis. I'll have
> a preforked spamassassassin process which does not need forking on every
> message. so me intention was to move the spamassassin stuff from the
> smtp stage to the lmtp stage. Implementing this stuff on [S|L]MTP proxy
> is another solution. there is one provided with spamassassin but I don't
> know how well tested and stable it is. third possible implementation was
> the sieve spam draft mentioned by rob.

I was pretty much in the same predicament as you, but I wasn't using
sendmail. I use postfix (which, in my personal opinion ran buttloads
better than my sendmail setup), but anyways...

My original setup used the SMTP filtering in Postfix to redirect messages
through the various filters (virus and spam) before being delivered.
Unfortunately, due to my lack of configuring skills at the time, I ended
up with a scenario where everything was forved through the virus scanner
(good), as well as through the spam scanner (bad), for both incoming and
outgoing email. This, of course, sucked for performance. Furthermore, some
of my users wanted to be able to turn off spamassassin completely, and I
had no way of doing that.

In my second setup I wanted to be able to force all mail (in and out)
through the virus scanner, and only selectively do spamassassin for
incoming users that actually want to be scanned for spam. I figured I
could just specifiy a content filter for the two incoming SMTP instances I
run (one on port 25 for regular connections and one on 2025 for
connections from friends that are on ISP's blocking outgoing 25). Both
instances require SMTP AUTH for relaying. I then thought that I could use
a MySQL based transport table and some interesting queries to determine
the "nexthop" for internal mail, thus allowing external mail to just go
out, and then selectively choose whether the next hop was spampd or the
lmtp port.

Well, as I found out, this was easier said than done. My biggest problem
was that recipient rewriting (virtual table stuff) wasn't happening before
the transport table was hit. This was fine as long as people weren't
mailing the virtual addresses. The big problem there was that it's the
virtual addresses that I tend to use in webforms that get the spam which I
want scanned :-)

I ended up going with dual instances of postfix. The first instance did
the usual things. The second instance was pretty much the filtering
instance. Mail coming into the first instance was forced through the virus
filter. The virus filter then spit things out to the second postfix
instance. The second instance is supposed to either forward things out to
the net (for outbound stuff), or forward things on to the smtp spam filter
or optionally bypass that and go straight to the mail store.

This meant that in the second instance, I had the SMTP based spam filter
defined as the default local transport, and I would use the transport maps
to define the post-processing smtp listener for the first instance as the
next hop in case I had to bypass the spam filtering. The spam filter (if
used) would dump it's traffic out to the post-processing smtp listener on
the first instance of postfix too. This meant that regardless of the path,
local mail eventually ended up on the post-processing smtp listener of the
first instance. In the first instance, I defined the cyrus lmtp as the
mailbox transport.  Thus mail made it to it's final destination in cyrus.

For virus scanning I used amavis-ng. For spam scanning I used spampd with
a hack to allow for user spam preference loading via SQL. It has been
working well as far as I can tell.
			-peace

-- 
Let he who is without clue kiss my ass