[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[csmith-dev] csmith-bugs list config change
This morning I changed the configuration of the <email@example.com>
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
This new change should eliminate spam sent to the list, unless it is sent by a
subscriber or a previously approved poster :-).
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
(Aside: The <firstname.lastname@example.org> 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
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.
Eric Eide <email@example.com> . University of Utah School of Computing
http://www.cs.utah.edu/~eeide/ . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX