[Spambayes] deployment for mailman lists

Skip Montanaro skip@pobox.com
Mon Nov 4 22:38:27 2002


    Guido> But the key is that *you* are the list's main administrator and
    Guido> in charge of the initial setup.  So *you* should set it up to
    Guido> minimize your pain (which includes constant worries about lost
    Guido> mail due to false positives in the spam filter).

Correct, but regardless of my abilities in this particular case, the
*default* for new mailing lists - those created by ~mailman/bin/newlist -
should be to not delete the spam.  The administrator of the site has to run
that.  The moderator of the list (who generally won't have shell access to
the machine running Mailman) will then get her chance to go through and
fiddle the bits.

    Guido> I believe that while Mailman is relatively easy to set up, it
    Guido> requires (at least) typical mail admin skills, and a mail admin
    Guido> already has in his/her head ideas about the cost of lost mail.
    Guido> You seem to have been burned by this, and as a consequence I
    Guido> believe you're on the conservative side.  As long as the
    Guido> consequences are clear when a list admin chooses to enable spam
    Guido> filtering, I think the default should be for convenience, not for
    Guido> liability.

It has nothing to do with getting burned, I just have relevant current
experience dealing with less technical lists.  There are tons of
non-technical folks out there running Mailman-managed mailing lists.
Consider that many hosting companies like Hostway make this available to
their customers.  Every other mail-handling tool I've ever seen (sendmail,
fetchmail, procmail, etc) goes to great lengths to avoid losing mail.  Why
shouldn't Mailman?

    Guido> There's no way you can design a web moderation interface to deal
    Guido> well with manually moderating 200 spams per day.  IMO if you show
    Guido> *all* spam in the moderation interface, the kind of non-techie
    Guido> moderator that you describe is *more* likely to make mistakes
    Guido> (rejecting ham or approving spam) than in the default that I
    Guido> propose.

I'm not saying that you have to design an interface to deal with moderating
200 spams a day.  I'm also not saying it's a one-time-only setting.  Still,
by making the default for held spam messages be "discard" instead of
"defer", Mailman could make it a one-click operation to delete all 200 with
one "Submit All Data" click from the moderation interface.  I haven't used
Mailman 2.1 yet, but I think that was something Barry had hoped to make a
configuration option as well.

    Guido> You've made this same (or a very similar) point many times, and
    Guido> while I agree with you that it's bad to delete spam in many
    Guido> setups, I strongly disagree in this case.

Only because you seem to continually misunderstand what I'm saying.  I am
*only* saying it's bad to delete spam by default when the list is first
created.  Let the list moderator decide, "I can't handle all this crap,
please delete it for me".

I see two scenarios:

    1.  An existing mailing list is converted to a new Mailman+Spambayes
        setup.  The moderator is either (a) thankful that all the spam which
        had previously shown up on the list is now somewhere he can deal
        with it, or (b) he was already doing something to deflect most/all
        the spam, so doesn't see much of it in the moderation interface.

    2. A brand new mailing list is setup with Mailman+Spambayes.  As a new
       list, it should not be getting 200 spams per day.  The moderator will
       have time to figure out how to change the settings on the list to
       delete spam instead of hold it.

I just don't understand why you have a hard time understanding that
out-of-the-box Mailman+Spambayes should not delete spam.  It's a one-click
change for Greg or Barry, or whoever controls python-list.  Why not err on
the side of caution?

Skip




More information about the Spambayes mailing list