[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[csmith-bugs] csmith-bugs list config change



SYNOPSIS

This morning I changed the configuration of the <csmith-bugs@flux.utah.edu>
mailing list.  Previously, it was an open list: anyone/anything could post to
it.  Now, posts from most non-members are held for moderation.

People who have previously sent reports to csmith-bugs are on a whitelist of
approved senders.  New bug reporters will be added to the whitelist in the
future.

This new change should eliminate spam sent to the list, unless it is sent by a
subscriber or a previously approved poster :-).

DETAILS

The rest of this message is list-management details.  You can stop reading now
if you don't care about the history and philosophy.

When I created the csmith-bugs list, I deliberately configured it as an open
list in order to encourage bug reports.  Nobody wants to subscribe to a list
just to report a bug!  Of course an open list also attracts spam, but I
considered this the price to be paid by those of us who would subscribe to
csmith-bugs.  I thought it was the right trade-off at the time: it was the
configuration that minimized the barrier to bug reporting and also minimized my
list-administration effort.

(Aside: The <csmith-dev@flux.utah.edu> mailing list is configured differently.
That list is closed: only subscribers may post to that list.  To discuss Csmith
you must "join the community.")

The open configuration of the csmith-bugs list worked fine until recently.
Nowadays, the combination of spam volume, low bug-report volume, MDA policy,
and Mailman bounce-processing policy has become a problem.

The current problem is that I and other Utah folks have been becoming
unsubscribed from the csmith-bugs mailing list.  This happens because the Utah
School of Computing bounces much spam, which Mailman interprets as a delivery
error, which leads Mailman to suspend our list subscriptions and ultimately (if
not contravened) unsubscribe us from the list.

My solution to this problem was the change I made today.  I changed the
csmith-bugs list to moderate posts from most non-subscribers.  Non-subscribers
can still report bugs easily, but unless the sender is recognized, he or she
will receive a notice that his or her message has been held for moderation.
Legitimate reports will be approved and their senders will be added to the
non-subscriber whitelist.

This change will keep the csmith-bugs list mostly open.  It also has the
advantage of knocking out most/all spam, which will keep us Utah folks from
being unsubscribed from the list.  The cost is the time required to moderate
posts, which I expect to be small (but unfortunately ongoing!).

An alternative solution, which I did not implement, would be to disable
bounce-processing for the csmith-bugs mailing list.  I did not implement this
because I believe that bounce processing is generally worthwhile, and in any
case it would do nothing to cut down on list spam.  (I could disable
bounce-processing in addition to moderation, but that seemed unnecessary.)

So we will see how this new csmith-bugs list configuration goes.  Of course I
expect that it will be fine, and I expect that the effort required to moderate
will be low.  Subscribers to the csmith-bugs list will enjoy the absence of
spam.  But: If the moderation effort turns out to be too high, I will switch to
Plan B, disabling bounce processing.

Thanks ---

Eric.

-- 
-------------------------------------------------------------------------------
Eric Eide <eeide@cs.utah.edu>  .         University of Utah School of Computing
http://www.cs.utah.edu/~eeide/ . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX