Subject: editheader interaction with mailto notifications

From: Alexey Melnikov <[email-masked]>
Date: Thu, 03 Apr 2008 19:45:03 +0100

Folks,
I am wondering if editheader should also prohibit deletion of  
Auto-Submitted, as it is used for loop prevention in mailto notify document.

Thoughts?

---

From: Ned Freed <[email-masked]>
Date: Fri, 04 Apr 2008 11:46:17 -0700 (PDT)

> Auto-Submitted, as it is used for loop prevention in mailto notify document.

Seems reasonable to me.

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 4 Apr 2008 21:32:53 +0200

> Auto-Submitted, as it is used for loop prevention in mailto notify 

The reason is IMO insufficient, but the idea is good.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 05 Apr 2008 11:11:07 +0100

> The reason is IMO insufficient, but the idea is good.

Arnt, can you elaborate on why you think the reason is not sufficient?

Thanks,
Alexey

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 5 Apr 2008 21:45:14 +0200

> Arnt, can you elaborate on why you think the reason is not sufficient?

Sorry. I should have done so in the first place. If I had tried to 
formulate my intuitive thoughts I would have ended up with a something 
like: "Editheader SHOULD NOT allow removing Auto-Submitted, because 
it's known to be used for loop prevention. Disturbing someone's loop 
prevention logic is both rude and harmful."

Editheader shouldn't be courteous to mailto-notify because both are 
sieve systems. It should be courteous to everyone because mail loops 
are $#@!$#$!@ painful.

Arnt

---

From: "Mark E. Mallett" <[email-masked]>
Date: Sun, 6 Apr 2008 16:09:58 -0400

> The reason is IMO insufficient, but the idea is good.

I suppose this is as good a place as any to bring this up..  I'm a
bit wary of this:

   > Implementations MUST NOT trigger notifications for messages
   > containing "Auto-Submitted:" header fields with any value other than
   > "No".

and some other similar text.  The stated reason is for loop prevention,
but as written, what it seems to be preventing is cascading
notifications, not loops.  I can easily envision somebody wanting to
trigger a notification based on another notification, e.g.:

   A sends to B
   B sends notify to C
   C sees the notify and wants to notify D as well.

where any of the above could be role accounts or lists.

We have no such prohibitions on redirects, where cascading them is (good
or bad) quite common.  I wouldn't want to see them on mailto notify
either.  Which doesn't negate the fact that I think that one would still
want to take extreme care when generating a notify based on mail with an
Auto-Submitted field in it -- but I would leave that as a caution to a
script writer, not a limitation imposed on the underlying
implementation.

The interesting thing is that this draft specifies some new
Auto-Submitted parameters which *can* be used for loop control.  I think
it would be much more useful to say that if the message contains an
Auto-Submitted header field with any value other than "no" *and* with
either an "owner-email" or "owner-token" field that is associated with
the currently running delivery, then the notification should not be
done.  I sort of wonder if that was what was in mind when these
parameters were added, since they seem perfectly suited to it.

(This should not prohibit other loop control mechanisms such as
the common "Delivered-To" field.)

It's easily possible that I've misinterpreted something..

Yours,
mm

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 7 Apr 2008 12:10:56 +0200

Mark E. Mallett writes:
> I suppose this is as good a place as any to bring this up.. I'm a bit 
> wary of this:
>

(C can do that using redirect as well as notify.)

I don't like notifying about auto-submitted mail. Redirecting is better, 
that gives B's MTA a chance to detect the loop should one occur.

> We have no such prohibitions on redirects, where cascading them is 
> (good or bad) quite common. I wouldn't want to see them on mailto 
> notify either. Which doesn't negate the fact that I think that one 
> would still want to take extreme care when generating a notify based 
> on mail with an Auto-Submitted field in it -- but I would leave that 
> as a caution to a script writer, not a limitation imposed on the 
> underlying implementation.

Not one script writer, but two. B and C. If they are the ones who have 
to be careful, they have to coordinate and be careful together.

I'd prefer to place more emphasis on loop prevention in the standard, 
and demand less care by the n pairs of script writers.

Arnt

---

From: Ned Freed <[email-masked]>
Date: Thu, 10 Apr 2008 07:56:13 -0700 (PDT)

> where any of the above could be role accounts or lists.

Very good point. We have existing users that depend on cascading notifications,
so the way I had planned to implement this is to count auto-submitted fields
and compare against a settable threshhold. The default for the threshhold will
be 1 but operators will be able to set it higher if they choose. 

Depending on what the specifications say the documentation will include
apprpropriate warnings about how this is a standards violation and so on.

> script writer, not a limitation imposed on the underlying

I think that leaves things a little too open. I would suggest that we instead
require checking for Auto-submitted fields but leave open the threshhold at
which notifies are blocked - the same sort of language we have elsewhere
regarding Received: fields.

> parameters were added, since they seem perfectly suited to it.

As I recall this was intended for tracing purposes. However, an alternative
would be to require the use of these paramters and then require that
they be checked.

I worry, however, that not all scripting environments will have the ability to
generate appropriate values for these parameters.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Fri, 18 Apr 2008 16:33:29 -0400

> be 1 but operators will be able to set it higher if they choose. 

There's a problem with that.  RFC 3834 says this, at the end of section 5.1:
    The maximum number of Auto-Submitted fields that may appear in a
    message header is 1.

We could update that here, but there's no reason to think that there 
isn't already code out there that strips extra Auto-Submitted headers, 
and there's every reason to think that setting the threshold > 1 would 
expose one to problems.

I think it's a Bad Idea to send notifications about Auto-Submitted 
messages.  Redirect can do it, and redirect ought to be sticking 
Resent-* headers in.  Those headers are already defined in a way that 
lets one count them.

Barry

---

From: "Mark E. Mallett" <[email-masked]>
Date: Sat, 19 Apr 2008 14:43:08 -0400

>    The maximum number of Auto-Submitted fields that may appear in a

Ouch.  So, Auto-Submitted really isn't a good field to use for loop
control.  If a way to limit the number of cascades is needed (ignoring
for the moment the objection to cascading at all), perhaps some other
trace field could be added.  It might be tempting to add another parameter
to the Auto-Submitted field, but you can't count on those being retained
or maintained.

> and there's every reason to think that setting the threshold > 1 would 

right

> Resent-* headers in.  Those headers are already defined in a way that 

I still disagree about that, if only for the meta-examples I gave before
about cascading notifications.  But that's not all.  If, for example, my
monitoring service sends me a message that the heat in my office is
above a certain threshold, this might be Auto-Submitted, yet I would
want to be able to get a notification of it, using the appropriate
language element to do so.  I imagine other examples could flow easily.

I think you have to be careful with prohibitions, and I believe that
this one would practically guarantee that non-conforming implementations
will arise.

mm

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 21 Apr 2008 09:22:13 -0700

On Apr 19, 2008, at 11:43 AM, Mark E. Mallett wrote:

> So, Auto-Submitted really isn't a good field to use for loop control.

I concur.  Also, as a "notification" is a different best from an "auto  
response", so use of auto-submitted seems a bit wrong.
It seems appropriate to use another mechanism for notification loop  
detection.

-- Kurt

---

From: Michael Haardt <[email-masked]>
Date: Tue, 22 Apr 2008 10:47:24 +0200

> It seems appropriate to use another mechanism for notification loop  

From RFC 3834:

   The purpose of the Auto-Submitted header field is to indicate that
   the message was originated by an automatic process, or an automatic
   responder, rather than by a human; and to facilitate automatic
   filtering of messages from signal paths for which automatically
   generated messages and automatic responses are not desirable.

Notifications originate by an automatic process, not by a human.  We
use this field as intended.

One can argue about using it for loop control.  If somebody is on
vacation, his Sieve script will not respond to automatically generated
alarms and the role account used as sender of these alarms is not
notified about the recipient being away, despite expecting them, as he
would get notified if the recipient mailbox overflowed.  We decided loop
control using widely implemented mechanisms is more important than minor
gripes about missing responses for "vacation".  To me, the same reason
applies here.

Michael