[Top] [All Lists]

Re: editheader interaction with mailto notifications

2008-04-07 03:29:37

Mark E. Mallett writes:
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.

(C can do that using redirect as well as notify.)

I don't like notifying about auto-submitted mail. Redirecting is better, that gives B's MTA a chance to detect the loop should one occur.

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.

Not one script writer, but two. B and C. If they are the ones who have to be careful, they have to coordinate and be careful together.

I'd prefer to place more emphasis on loop prevention in the standard, and demand less care by the n pairs of script writers.