mailbox classificataion

Matthias Andree matthias.andree at gmx.de
Thu Jan 30 02:36:23 CET 2003


Boris 'pi' Piwinger <3.14 at logic.univie.ac.at> writes:

>>Suppose we did allow "bogofilter < mailbox".  What would the output be?
>>
>>With no options, bogofilter classifies a message and provides an exitcode 
>>of 0 or 1 as its classification.  I don't see an extension of this to a 
>>mailbox.
>
> This is right, but actually I don't see a situation where is
> would be advisable to classify an mbox as a single mail.

So don't do it :-) Seriously, when bogofilter is run in its normal
"filter" mode from procmail, maildrop, whatever, it is given a single
mail. If we would do things REALLY accurate, we'd even switch of From
line detection in this mode, and switch it off if the first line of
input is not a "From " line on the assumption that we then have a single
mail.

There might be some value in enabling -p to treat all messages, but then
again, formail already handles this. It is really one or two lines.

bogofilter is a monster user-interface wise, and it has already been
criticized, and rightly so -- let's not pull existing functionality into
bogofilter when we don't direly need it.

>>Now you have an output that's an expanded mailbox.  You still need to 
>>filter/separate the messages into appropriate files/folders, don't 
>>you?  
>
> Yes, but you may take this classified mbox wherever you like
> before proceeding. But which sense would it make to treat it
> as a single mail?

None. Bogofilter expects a single mail except when it is registering.

>>So, why not use formail/procmail/milter to split the mailbox and give 
>>bogofilter individual messages?
>
> Of course, you can use formail -es, but we support -sSnN
> with mboxes already. Strictly speaking this would not be
> needed.

Strictly speaking, the mailbox-splitting code isn't needed either, but
ESR introduced it and it managed to survive up to now. :-)

> I'm not sure everybody will like it: If you classify an mbox
> (-p or no option) the result will be bogus. So we should
> return either an error exit code or a special code which is
> distinct from the codes for single mails.

I've tried the first approach and caught bug reports, since the mail
procmail passes on to its filters does not have the "^From " lines
escaped -- there's no unison in the input format, and there probably
will never be. There's nothing short of telling bogofilter what the
input is "mbox or single mail". The current implementation of the sSnN
options is inaccurate because it ALWAYS assumes we feed a mailbox, and
piping a single mail into the registering function e. g. from the
suggested mutt macros will give bogus (too high) message counts when a
paragraph in a mail starts with "^From " as in "From my POV ...".

-- 
Matthias Andree




More information about the Bogofilter mailing list