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