On Mon, 13 May 2002, Ken Murchison wrote:
>
>
> "Marc G. Fournier" wrote:
> >
> > I'm playing with the spam extension, and for POP3 users, I want to add, at
> > its simplist, a 'X-Spam-Check: True' header to the email if its spam ...
> > I've done some quick reads of the various drafts, and there appears to be
> > no way of doing this within Sieve ... has anyone worked on something like
> > this?
> >
> > I've thought to modify the code, to extend the spam extension, so that it
> > adds a simple:
> >
> > X-Spam-Score: <True/False> <score> / <threshold>
> >
> > so that if spam is enabled, then it auto-adds this header, but I can't
> > find where in the code to actually add this ... The X-Sieve header is
> > added in lmtpd.c, but before the scoring happens, so that doesn't help ...
> > fillin_header() in sieve/script.c looks good, and is after the spam checks
> > are run/scored, but am not 100% certain of how I should call add_header()
> > for the above ...
> >
> > Can anyone provide some insight on this?
>
> It will be pretty difficult. The current design of lmtpd/sieve was
> never meant to do this. The message is already spooled (in the staging
> area of the first recipient) by the time the sieve filter is run. You'd
> have to have a callback which adds the headers to a NEW spool file and
> then have lmtpd copy over the test of the existing message to this NEW
> file when done (unless you can find some slick way of inserting data
> into the head of a file). You'd be adding a second message copy, which
> I recently spent time correcting (messages used to be spooled to /tmp
> and then copied to the stage).
>
> I know the code pretty well, and personally I wouldn't even attempt it.
> Of course, I'm not a fan of the spam extension.
Okay ... by 'staging area', I take it you mean /var/spool/mail/stage.?
So, a simplistic view of things is ... ?
MTA -> lmtpd -> /var/spool/mail/stage. -> sieve -> hard link to user
-> or bounce
-> or forward
-> or etc ...
Now, ignoring the 'spam extension' to Sieve thing ... and this may be what
Bob is already doing ... but how would you get a 'filter' in front of
sieve, so that it knows the user who its being worked on?
Basically, having spamassassin *in* sieve meant that it ran with that
users preferences for rules, threshold, white lists, etc ... if its moved
out of sieve, then it has to go between lmtpd and sieve, before being
written to stage.? This is why its useless before lmtpd, since it doesn't
know about 'per user rules/whitelists/thresholds' ...
You don't want to break singleinstancestore, if you can at all help it, so
it would have to somehow check if the message to be delivered to UserA
*after* running through the spam filter is still the same as being
delivered to UserB, else write a whole new file for UserB ...
Bob, is this what you are working on? Or am I far out in left field in my
understanding of this?
