Re: editheader interaction with mailto notifications

[Ned Freed <ned.freed@xxxxxxxxxxx>]

> On Fri, Apr 04, 2008 at 09:32:53PM +0200, Arnt Gulbrandsen wrote:
> >
> > Alexey Melnikov writes:
> > >I am wondering if editheader should also prohibit deletion of
> > >Auto-Submitted, as it is used for loop prevention in mailto notify
> > >document.
> > >
> > >Thoughts?
> >
> > 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.

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.

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

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.

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

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