A plugin would be able to do this -- and that's probably the best way to
do it, since it's pretty gross and unlikely to work for more than a few
hundred users in total ;)
See the existing plugins for examples of forking processes safely. (DCC
for example)
--j.
Jeffrey W. Baker writes:
> There's a bug (4029) which is resolved as WONTFIX but which I think
> deserves more attention. The problem is with DSNs and bounce messages
> which are in reply to mail which was never sent. In various places this
> is called backscatter, collateral damage, whatever. I call it
> irrelevant daemon mail.
>
> I think there is a pretty good way to solve this problem. The message
> can be initially flagged as a bounce message/DSN, which is pretty easy.
> If the message body or attachments makes reference to a message ID which
> is in the user's FCC (sent folder) then the mail is tagged with
> DSN_RELEVANT. If the message body or attachments reference a message
> ID, but the message ID does _not_ appear in the user's FCC, then the
> message gets to be DSN_IRRELEVANT. Otherwise the message will be
> DSN_UNKNOWN. The user can then apply the desired score to these (my
> choice would be -5, +5, and 0 respectively).
>
> The only hitch is how to access the user's FCC. Personally, I use
> dovecot, so I can access my by forking /usr/lib/dovecot/imap and using
> this very simple code:
>
> $c = Mail::IMAPClient->new(
> Socket => *DOVECOT
> , State => 'Authenticated'
> );
>
> $c->select($fcc_folder_name);
>
> foreach my $id (@msgid) {
> my ($res);
>
> $id =~ s/["'<>\r\n]//g;
>
> $res = $c->search('HEADER', 'Message-Id', qq/<$id>/);
>
> if (defined($res) && $res > 0) {
> # Do something smart here
> last;
> }
> }
>
> $c->logout();
>
> Pretty straightforward?
>
> So the main issues are how to allow the user to specify the means of
> accessing the FCC (via IMAP would be my first implementation, but I'd
> allow for development of other ways ranging all the way down to
> grep(1)), and, since I'm completely new to this SpamAssassin thing, how
> to safely fork the subprocess as that user. That's allowed, right?
>
> I do realize that there exist some custom rules for handling virus
> reports and the like, but I like the exactness of this implementation a
> bit better. By the way, I've been using this system, via procmail
> outside of spamassassin, for years and it works great.
>
> Your thought will be quite welcome.
>
> -jwb
