[Spambayes] Beyond Spambayes

Seth Goodman sethg at GoodmanAssociates.com
Fri Feb 24 00:34:56 CET 2006

On Thursday, February 23, 2006 3:01 PM -0600,
netsecurity at sound-by-design.com wrote:

> From this point of view it is my opinion that we'd all be better
> off if the mail did not get delivered in the first place. This is
> why I suggest that adding an additional layer of robustness might
> prove useful.

I agree with you, but with a caveat.  If you run a SMTP server (incoming
MTA), the responsibility you assume for every message you accept is that
you will either deliver it to the final recipient or send a notice to
the original sender explaining why it couldn't be delivered.  Since spam
has forged return addresses, it is not possible to send non-delivery
notifications.  Silently discarding mail that you've accepted breaks the
assumptions behind SMTP and makes email less reliable for all of us.

The answer is to reject, i.e. not accept in the first place, spam
messages during the SMTP transaction.  It is then the problem of the
sending system as to what to do with the undeliverable message.  If
stuck with enough of these, they may actually be forced to clean up
their act as to what _they_ accept for delivery.  In any case, the key
is in refusing to accept unwanted mail from the sending system, not
accepting and then silently discarding it.

While an individual user with Spambayes can glance at their spam folder
and decide what to delete, nobody gets that chance when the server
silently discards messages, and the sender isn't notified.  In that case
the system has simply failed and no one can find out why.  Since the
classifier that can avoid false positives has yet to be invented, it is
very important to not silently delete suspected spam, especially at the
server level.

Seth Goodman

More information about the SpamBayes mailing list