[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: editheader interaction with mailto notifications
> 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
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.