[Top] [All Lists]

Re: editheader interaction with mailto notifications

2008-04-10 08:34:38

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


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

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.