Re: Autoreply

[Ken Raeburn <raeburn at MIT.EDU>]

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.org
https://www1.ietf.org/mailman/listinfo/ietf