On Jul 13, 2007, at 09:05, John C Klensin wrote:
However, I think the IETF benefits from policies whose effect is
to keep the clueless and inconsiderate off our mailing list
until they can be educated.
I think most organizations or lists would benefit from such
policies. But where does the education come from, if not us? Are we
expecting them to attain a certain level of clue at some unspecified
"elsewhere", before they can join up to discuss the GSSAPI or CALSIFY
or something else pretty well removed from needing an understanding
of the workings of the mail systems of the Internet at large? We
certainly aren't giving them any help in that regard with our list
"welcome" message.
I'd be okay (not happy) with a policy of "unsubscribe and send a
friendly form letter explaining why and how to fix it", though I
don't think it's as good as keeping delivery going when that's easy
and doesn't impact the rest of the list membership. But a policy of
simply unsubscribing would likely lead them to the conclusion that
the IETF mail system is broken (and if you consider policies a part
of the system I'd say they'd be right), and that by association, the
IETF is as lame and clueless as we're claiming the subscriber and his
sysadmins are.
IMO, the ideal solution to problems of this sort is to set
accounts to "no postings", such that an incoming message from
the relevant address gets back a message explaining possible
causes and what to do about them. I don't think mailman
supports that capability (at least some versions of LISTSERV and
LISTPROC) did, but I assume that most of the relevant code is
available for dealing with postings by non-subscribers and
attempted posting for people who have been removed from lists
for bad behavior or the equivalent (I hope those two messages
are not the same).
Yes, I think the code would have to be adapted, but most of what's
needed should be there.
Whether "no mail" ("disable mail delivery")
should also be set it a matter of taste. I would think it would
be better to not do that, i.e., to keep delivering the list
messages themselves, as long as mailman and the associated MTAs
have _very_ good loop protection and suppression mechanisms.
I thought about suggesting some ideas to dampen loops if the vacation
autoresponder replies to each of the bounces. But as mailman already
has the capability to bounce mail from a given sender, the issue
already exists, and the details of how to deal with it is off-topic
here.
Whether mailman does currently have a way of coping with the problem
would be on-topic, but I don't know the answer.
However, if someone knows that their MTA sends out "vacation"
messages even to obvious lists and has no mechanism for
suppressing those messages when the incoming message came from a
list of user-supplied addresses, mailman usually makes it fairly
easy for a user to set "disable mail delivery" during an
out-of-office period. It seems to me that repeated failure to
do so after several cycles of "messages to list; postings
disabled; postings reinstated" ought to be sufficient grounds
for a self-inflicted PR action, i.e., banning the person from
posting again from that address without some affirmative
statement that the problem has been fixed, not just logging into
mailman and resetting the flag.
I like that idea.
Anyone here know anything about writing mailing list software? :-)
Ken
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf