On Mon, 13 May 2002, Ken Murchison wrote:
>
>
> "Marc G. Fournier" wrote:
> >
> > On Mon, 13 May 2002, Cyrus Daboo wrote:
> >
> > > Hi,
> > >
> > > --On Monday, May 13, 2002 1:57 PM -0400 Ken Murchison <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > | 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.
> > >
> > > Quick question: where does the X-Sieve header get added, and would it be
> > > possible to use that to add extra info?
> >
> > in savemsg() in lmtp.c ... and tried that ... unfortunately, that is
> > before the sieve filtering happens, so there is nothing to write yet ...
> >
> > from Ken's email, and what I've been able to follow, lmtp writes the email
> > to a file before parsing through sieve ...
> >
> > Ken, is there a reason why it doesn't just hold it in memory?
>
> I don't know for certain, you'd have to ask Larry. You probably _could_
> hold it in memory, but then you are essentially blowing up
> singleinstancestore (or making it far more difficult), because each user
> could end up having their own unique copy of the message.
Okay, you've lost me here ... regardless of where along the chain the spam
filter is run, each user is going to potentially end up with their own
unique copy of the message ...
If I have 10 users that get delivered an email, and they all have the
default 'spamassassin settings', then singleinstancestore will attempt to
save storage space by using hardlinks between them ... if one of those
users decides that he feels his threshold is too high (we're looking at
implementing Spamassassin with a default high threshold, and those that
wish to, can lower it), and lowers it, then if that same mail now triggers
the filter, that one user will get his own unique message, while the other
9 will still make use of the singleinstancestore ...
The only time this would be guaranteed *not* to happen is if 'per user
preferences' are not available ...
Now, I'm curious as to how holding the "temporary message" in memory would
change this ... in fact, I would think it would simplify things, depending
on how its implemented ...
For instance, very quick thought(s) ... actually, this might work better
'on disk', but ...
1. when a message comes in destined for multiple recipients, process a
copy of that message through the appropriate filters for recipient one ...
before writing it to disk, take a 'checksum' of the message, then write to
disk.
2. for recipient two, you need to process the filters again, but this
time, before writing it to disk, compare its checksum against teh first
one ... if the same, use singleinstancestore, else write a new copy ...
3. repeat step 2 for subsequent recipients ...
you are effectively doing that right now ... each recipient of a message
gets checked for the existence of a sieve filter, and that gets processed
... if it bounces/rejects/forwards, the appropriate action is taken ...
else use singleinstancestore ... all that needs to be added is a check
*after* the sieve filtering (or last filter, however that gets setup) that
checks to make sure that the message for that recipient isn't a duplicate
of what was written for another recipient ...
Then it would be too easy to have lmtp do:
for i in list of recipients
filter message through spam filter for recipient i
filter message through sieve filter for recipient i
if(chksum(i-1) == chksum(i))
create hard link
else
write unique message
all you need to do is "save" the checksum of the resultant message after
the filters, so memory consumption should be negligible, and as soon as
that message is finished, it would be released anyway ...
