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