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