mime.c

[Matthias Andree]

David Relson <relson at osagesoftware.com> writes:

>>What good is that? I think this constitutes a problem, because a mail
>>can then make bogofilter print something, which might be a robustness or
>>security issue after some future changes. If bogofilter prints errors
>>for local issues (DB corruption, file not found, I/O error), that's
>>fine, but the output should always be independent of the mail contents.
>
> Well, I think there should be a warning when bogofilter encounters an
> unknown mime specification.  It's O.K. by me to use a simple message
> like "unknown mime encoding", rather than a message that quotes part of
> the mail contents.

I respectfully disagree. "b0rken MIME" is perfectly expected input for
bogofilter indeed -- we want to tag that junk, not complain about
it. Apart from the bogosity and possibly stats output, the bogofilter
output should always be the same, regardless of what input
arrives. Fatal exceptions being the other exception ;-)

We can emit our pseudo tokens into the word lists like "mime: missing
end boundary", "mime: nesting error", "mime: nesting too deep" or
something, we can complain in debug mode or with a
report-malformatted-mail-to-syslog option, but just like libraries
should not print unless explicitly requested, neither should
bogofilter.

If we printed errors for malformatted mail, we'd defeat our own purpose:
if regular mail comes in, everything's fine, if offensive mail comes in,
the stderr is spammed. We wanted to hide unsolicited messages from view,
the error message is the exact opposite.

> Of course any spammer who uses a bogus specification risks the message
> being unreadable - which is _not_ their goal.

Spamware isn't written by the brightest guys unless they are insane.

> Matthias,
>
> How would
>

Looks like an incomplete mail to me.

-- 
Matthias Andree