On Tue, Jul 15, 2008 at 10:17:32AM -0400, Barry Leiba wrote:
So, everyone: if you consider yourself an active participant, please
send a message to this mailing list within the next, say, week, stating
(briefly) your position on this. There's no need for a lot of
explanation, because the reasons on both sides are clear.
I'm looking for consensus on one of these:
1. Using Auto-Submitted to avoid loops -- and, therefore, the risk of
loops if we send notifications for auto-submitted messages -- is
sufficiently important that the current "MUST NOT" text should stay.
2. The use cases for notifications on auto-submitted messages are
sufficiently important that the text should be changed. [Please suggest
new text, in this case.]
3. "SHOULD NOT" is an acceptable compromise. The current "MUST NOT"
should be changed to "SHOULD NOT", with some added text to explain the
danger very clearly. [In this case, you can suggest text, or I'll craft
it.]
I can't find any camp to be in, but I feel that #2 is closest. I don't
think that "Auto-Submitted" is a strong indicator of a non-notifiable
message, and as I've said I can imagine cases where it's just the opposite.
I guess that one thing we're trying to work around is the fact that
systems that are the target of a notification message, and that might
pass it on to where it loops back around, can't be relied on to pass
whole headers, and so things like Received counting or looking at (e.g.)
"Delivered-To" can't be counted on as those fields might get stripped.
As might the original "Auto-Submitted" field, so this technique either
relies on this field being preserved, or on one of the downstream notifiers
or forwarders adding one of their own. That all strikes me as kind of
shakey in addition to being a mis-use of this field.
So I feel that it's important to make a note about loop prevention; that
it's hard to do when it's a possibility that most header fields will get
stripped; but that that doesn't make using "Auto-Submitted" any more
palatable. I wish I had text to propose, other than just a strong note
that somehow detecting loops should be a priority of the implementor.
I also think that the "MUST NOT" under discussion is almost certain to
be violated, so I would vote against that.
mm