obsolete and unknown options

[David Relson]

On Thu, 29 Jul 2004 11:02:45 -0800
jerry wrote:

> > 
> > This has contributed to loss of mail by 2 people who were using the
> > removed options, but didn't have proper recovery logic in their
> > procmail/maildrop scripts. This morning I removed the "unknown
> > option" error exit and released bogofilter-0.92.4.  With that
> > change, using obsoleted options (or totally bogus options) generates
> > a message to stderr and bogofilter runs using the remaining (valid)
> > options.
> >
> Ok, I plead guilty, I was one that had not upgraded since 0.14.5 and
> had problems with the new version 0.92.0, it was deleting all emails, 
> regardless of being spam or ham. This has now been corrected, I'll
> send another message with the info on how I corrected this problem.
> 
> Your statement "but didn't have proper recovery logic in their
> 	 procmail/maildrop scripts" leads me to ask, are you refering to
> 	 
> the:
> 	:0e
> { EXITCODE=75 HOST }
> located in .procmailrc file? I have/had this code in my .procmailrc
> file and still the mail was deleted, maybe there's another problem ?

Yep.  That's the error recovery code.  The info you sent me privately
didn't show _where_ it is in procmailrc.  In the wrong place, it's
ineffective AFAIK.

"bogofilter -f" exits with EX_ERROR (3) in 0.92.4 because '-f' is an
unknown option.  With proper error recovery, the MDA will repeatedly run
procmail expecting that the exit 75 will go away.  When I've had a
problem, it has resulted in multiple unfiltered copies of the message
being delivered, not in messages being lost.

You also reported the following:

$ bogofilter -Q
# bogofilter version 0.92.0

robx        = 0.415000  # (4.15e-01)
robs        = 0.001000  # (1.00e-03)
min_dev     = 0.375000  # (3.75e-01)
ham_cutoff  = 0.500000  # (5.00e-01)
spam_cutoff = 0.500000  # (5.00e-01)
ns_esf      = 1.000000  # (1.00e+00)
sp_esf      = 1.000000  # (1.00e+00)

and that your procmail rc contains:

:0H
* ^X-Bogosity: Spam, tests=bogofilter
* ? bogofilter
/dev/null

Just checking the headers is OK to do, but I'd worry about the accuracy.
 Bogofilter is fast and can easily process the whole message.  However
if
it's working fine for you, I can't complain.

"* ^X-Bogosity: Spam" will react only to properly tagged spam, so
shouldn't cause all email to be lost.

That leaves the "* ? bogofilter" line and the value of 0.500000 for
spam_cutoff as the remaining cause of all mail being lost (presumably
due to being sent to /dev/null).  Perhaps you should use bogofilter's
current default values (changed in 0.17.5) for robx, robs, min_dev, etc.

> > I should have realized this would be controversial :-<  Now I have
> > another idea:
> 
> 
> I don't think it's controversial, just some things need to be more
> clear, perhaps some plain english explaination of what has
> changed,what needa changing in regards to the .cf file and some simple
> examples of how to use the options pertaining to both bogofilter and
> bogoutil to utilize all of the potential of bogofilter

Undoubtedly some there's room for improvement in the explanations. There
is information in the man pages for bogofilter, bogoutil, and bogolexer.
 The FAQ has a number of examples.  The RELEASE.NOTES.* files describe
notable changes. As always there's the conflict between too little and
too much info.

...[snip]...

David