Subject: Autoreply: Last Call: draft-duerst-archived-at (The Archived-At Message Header Field) to Proposed Standard

From: [email-masked]
Date: Thu, 12 Jul 2007 16:07:06 +0200

I am out (on vacation :) ) until next 16 July. See you then.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 12 Jul 2007 15:57:00 +0100

Hi all,

I don't think this bounces, neither the thread they have originated are
useful for anyone ...

So I instruct here the secretariat to *automatically* take the appropriate
measures with this case and any other similar one in the future, such as
restricting (only) postings from the bouncing email address until the poster
comes back from vacations (or whatever) and confirm to the secretariat that
appropriate measures have been taken to avoid this happening again with
his/her email.

Regards,
Jordi as Sergeant-at-arm

> De: <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Thu, 12 Jul 2007 16:07:06 +0200
> Para: <[email-masked]>
> Asunto: Autoreply: Last Call: draft-duerst-archived-at (The Archived-At
> Message Header Field) to Proposed Standard
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 12 Jul 2007 17:33:50 +0200

On 12-jul-2007, at 16:57, JORDI PALET MARTINEZ wrote:

> comes back from vacations (or whatever)

That doesn't help much, because then we all still get private  
vacation messages. Please kick these people off the list.

---

From: Ken Raeburn <[email-masked]>
Date: Thu, 12 Jul 2007 12:04:16 -0400

> vacation messages. Please kick these people off the list.

Switching them over to getting the list in digest mode should also  
take care of that, I would think...

Ken

---

From: Douglas Otis <[email-masked]>
Date: Thu, 12 Jul 2007 19:03:52 -0700

On Jul 12, 2007, at 8:33 AM, Iljitsch van Beijnum wrote:

>> So I instruct here the secretariat to *automatically* take the  
>> appropriate measures with this case and any other similar one in  
>> the future, such as restricting (only) postings from the bouncing  
>> email address until the poster comes back from vacations (or  
>> whatever)
>

The web interface for Mailman allows subscribers to re-enable their  
account to receive messages when deliveries bounce too often.  As  
such an account might become "disabled" without notice.  In the  
subscriber's management web-page, a message could indicate that a  
reason for messages being disabled may also include use of auto- 
replies.  Not sending to such an account responding with auto- 
responses takes care of the problem.  Such auto responses will appear  
as duplicate messages and should be rather easy to automatically  
detect.   Disabling the account in this manner should be painless,  
where of course a subscriber would then need to notice a lack of  
traffic.  This lack of traffic should prompt them to check their  
account status, and click the enable radio button.

-Doug

---

From: Ken Raeburn <[email-masked]>
Date: Fri, 13 Jul 2007 02:00:57 -0400

On Jul 12, 2007, at 22:03, Douglas Otis wrote:
> responses takes care of the problem.  Such auto responses will  
> appear as duplicate messages and should be rather easy to  
> automatically detect.   Disabling the account in this manner should  
> be painless, where of course a subscriber would then need to notice  
> a lack of traffic.  This lack of traffic should prompt them to  
> check their account status, and click the enable radio button.

Shutting off their list email when we don't need to seems kind of  
drastic.  Perhaps I'm overly sensitive to it, having been dropped  
from a list in the past for the crime of not having an MX host up and  
accepting messages 100% of the time (i.e., no greylisting and no  
downtime allowed).  And after coming back from a week's vacation,  
while poring over hundreds of messages, I doubt the first thing on my  
mind would be, "oh, I don't seem to have piles of mail from the IETF  
list flaming about autoreply bots and NATs, maybe I should check my  
subscription".

Like I suggested before, switching them to digest mode would still  
get the list content to them.  While the autoresponders would  
presumably still answer those messages, the replies would not be to  
individual contributors.  They'd presumably be to the list (where we  
could suspend their posting privileges while they're away, and of  
course notify them that they have to contact the list admins to get  
them restored, or teach mailman to treat certain autoreply messages  
as administrivia to be filtered out), or to a list management address  
(where, if mailman can't be taught to deal automatically, it would  
"merely" be the list admins' problem).

It shouldn't be hard to convince mailman that subjects matching  
patterns "^out of office autoreply:" or "^autoreply:", for example,  
should be rejected (bounced to sender) or discarded (distasteful to  
me, on the miniscule chance that someone would have the misfortune to  
select a subject like "autoreply: useful practice or tool of the  
devil?" for a legitimate message on email reply bots, that would  
quietly never get delivered).  In fact, I suspect doing so would  
address 95% of the problems, without having to suspend anyone's  
mail.  Though fully automated processing of such messages would mean  
autoreply messages saying "Joe has moved, please update your list to  
send to [email-masked]" would never be seen...

So, maybe "^out of office autoreply" should be discarded or bounced,  
and "^autoreply:" should be held for moderation just in case, with  
the normal response being to switch to digest mode, suspend posting  
privileges (bouncing the autoreply messages back into the offender's  
mailbox, to ensure some incentive exists for them to fix the  
problem), and send a warning note?

Ken

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 13 Jul 2007 11:09:45 +0200

> drastic.

So people who are SO inconsiderate that they not only send vacation  
messages for messages sent to mailinglists, which is clearly  
extremely undesirable behavior, but even worse, send those messages  
to the LIST, should be spared all possible inconvenience?

Sure, that makes sense.

> me, on the miniscule chance that someone would have the misfortune  
> to select a subject like "autoreply: useful practice or tool of the  
> address 95% of the problems, without having to suspend anyone's mail.

Just unsubscribe anyone who sends autoreplies to the mailinglist and  
be done with it.

I'm sure we can find a former AD to provide an introduction to email  
filtering on the sunday before the IETF if we ask nicely for those of  
us who plan on taking that up as a hobby.

---

From: Ken Raeburn <[email-masked]>
Date: Fri, 13 Jul 2007 06:35:28 -0400

> to the LIST, should be spared all possible inconvenience?

Certainly not.  But that doesn't mean we need to be equally  
inconsiderate in response, when a small amount of effort can produce  
results nearly as good -- or better.

For example, if all the "out of office autoreply:" messages to the  
list get thrown out automatically, the issue never comes up for a  
certain subset of the people we're talking about.  Rejecting all  
messages with "autoreply" subjects also takes care of a portion of  
the problem.  Those probably require a little more effort than  
unsubscribing a list member, but it should be much less than  
unsubscribing everyone who runs a lame autoresponder over the course  
of the next year.

Of course, those only deal with automatic replies to the list itself,  
not to individual posters.

The effort required to implement "set digest flag for recipient, add  
recipient to auto-reject list, and send this form letter" would be  
more than a couple minutes' development work, at least for someone  
not intimately familiar with mailman, but need happen only once  
(unless it's tightly integrated into mailman, the upstream developers  
don't incorporate it, the next release requires rewriting it, etc).   
If it's done right, invoking it when individuals complain to the list  
admins about a subscriber should be about as easy as unsubscribing  
the person.  Similar effort could streamline the restoring of a  
subscriber's posting rights when they return (and let them fix the  
digest setting, if they care).  Adding a new "no-send" flag that is  
changeable by the subscriber, and when set prevents them from sending  
to the list, would be a bit more work, but would remove the second  
half of the ongoing imposition on the list admins.

If stopping all mail to these recipients is deemed to be the only  
way, then setting the "too many bounces" flag and letting mailman  
send its occasional reminders about the suspended account is probably  
friendlier than simply removing the address.

That's assuming the list admins are going to go ahead and change one  
person's subscription based on another person's complaint, without  
verifying the problem themselves.  You could automate the whole "send  
probe message and suspend account on receipt of autoreply" process,  
if you wanted to try to streamline that part of the list admin job.

I have no idea how many people use mail systems that send autoreplies  
to the individual contributors.  Certainly I haven't been deluged  
with such replies in response to my recent messages here.

Granted, none of my solutions prevent the user from restoring his non- 
digest posting-allowed configuration and then going off on vacation  
again, just as unsubscribing someone doesn't prevent him from re- 
subscribing and going off on vacation again.  Though bouncing all the  
autoreply messages back into his mailbox should provide some  
incentive for him to fix the problem.  (And I suppose in some ways it  
might be less friendly than unsubscribing, depending on one's  
perspective, mail server quota, etc.)

Ah, but no, these people are evil -- monstrous -- and must be removed  
from our sight!  Why stop at unsubscribing them?  Unsubscribe their  
friends; unsubscribe their mothers!  Let's mailbomb them with copies  
of RFCs on proper mail system practices, until their servers fall  
over.  That'll teach 'em!

Ken

---

From: John C Klensin <[email-masked]>
Date: Fri, 13 Jul 2007 09:05:56 -0400

--On Friday, 13 July, 2007 06:35 -0400 Ken Raeburn
<[email-masked]> wrote:

>...
>> So people who are SO inconsiderate that they not only send
>> vacation   messages for messages sent to mailinglists, which
>> is clearly   extremely undesirable behavior, but even worse,
>> send those messages   to the LIST, should be spared all
>> possible inconvenience?
> 
> inconsiderate in response, when a small amount of effort can
> produce results nearly as good -- or better.
> 
> For example, if all the "out of office autoreply:" messages to
> the list get thrown out automatically, the issue never comes
> up for a certain subset of the people we're talking about.
> Rejecting all messages with "autoreply" subjects also takes
> care of a portion of the problem.  Those probably require a
> little more effort than unsubscribing a list member, but it
> should be much less than unsubscribing everyone who runs a
> lame autoresponder over the course of the next year.
>...
> If stopping all mail to these recipients is deemed to be the
> only way, then setting the "too many bounces" flag and letting
> mailman send its occasional reminders about the suspended
> account is probably friendlier than simply removing the
> address.
>...
> Ah, but no, these people are evil -- monstrous -- and must be
> removed from our sight!  Why stop at unsubscribing them?
> Unsubscribe their friends; unsubscribe their mothers!  Let's
> mailbomb them with copies of RFCs on proper mail system
> practices, until their servers fall over.  That'll teach 'em!

Ken,

I largely agree with you.  The goal should be to stop the
behavior, especially the effect on list readers and those
posting, not to punish anyone.

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.

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).  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.

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.

      john

---

From: Keith Moore <[email-masked]>
Date: Fri, 13 Jul 2007 09:17:55 -0400

> until they can be educated.
Problem is, such a policy wouldn't be educating the clueless system or
network administrator or mail service provider who implemented the
broken autoresponder; it would merely be penalizing his customer.  Few
of us operate our own mail systems any more.

One of the problems with autoresponders is that the person who uses them
is the last one to know how well they work.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 13 Jul 2007 15:37:32 +0200

> is the last one to know how well they work.

These are all highly important considerations, except for one thing:  
if the offenders aren't unsubscribed, posters still receive their  
messages, even if the list doesn't.

If the end result is that people who are burdened by such  
autoresponders either

1. stop using them, or
2. temporarily unsubscribe during their absense

that's completely fine with me. Just suffering the bad behavior  
because we feel bad for the users of these systems doesn't help anyone.

Earlier today I was still getting mail on behalf of [email-masked]  
despite my best efforts instructing my many layers of spam detection  
and mail filtering to reject these messages, by the way.

Just unsubscribe the people who do this, trying to optimize the  
situation beyond this is a complete waste of time. And fighting a  
waste of time by wasting more time pretty much defeats the purpose.

---

From: Keith Moore <[email-masked]>
Date: Fri, 13 Jul 2007 09:47:02 -0400

> messages, even if the list doesn't.

True, but the posters only receive as many responder messages as they
send to the list, which (for reasonable posters) bounds the problem
somewhat.  At worst this means dozens of useless autoresponder messages
are sent, whereas if the messages are sent to the list, we're talking
tens or maybe hundreds of thousands of useless messages.  Sure it's
irritating for those posters, but it's not horrible.  And I at least had
no trouble writing a procmail rule to discard them.

Keith

---

From: Ken Raeburn <[email-masked]>
Date: Fri, 13 Jul 2007 12:54:52 -0400

> 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.

> 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")

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.

> mailman and resetting the flag.

I like that idea.

Anyone here know anything about writing mailing list software? :-)

Ken

---

From: Douglas Otis <[email-masked]>
Date: Fri, 13 Jul 2007 15:20:41 -0700

On Jul 13, 2007, at 9:54 AM, Ken Raeburn wrote:

>> to keep the clueless and inconsiderate off our mailing list until  
>> they can be educated.
>
> 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.
>
> 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.

Why write code to _accommodate_ auto-response senders?  Mailman  
already has a mechanism in place for bounces.  This mechanism will  
not "unsubscribe" the account, but instead disables messages from  
being delivered.  At some point, recipients will become aware of a  
problem.  The archives will contain messages missed, and confirm a  
cessation.  Suspending delivery ensures auto-responses are not made  
to other list posters as well.  Everyone will be happier except those  
sending auto-replies.  TT.

In the case of ongoing bounces, it is not possible to notify  
recipients of an altered status or how they might reinstate  
delivery.  However, it will be far more educational to _not_ issue  
notifications in the auto-response case as well.  Disabling delivery  
of messages without notification require the clueless to  
investigate.  This lesson may be shared with IT staff when they  
becoming part of a really clueless recipient's investigation.  The IT  
staff are also best able to ensure future notifications are curtailed.

In the Mailman management page, indicate the repeated sending of  
messages like "I'm on vacation" may be a reason for delivery to  
become disabled.  Problem solved with an effective educational  
component included.

-Doug