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'm in much the same position.
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.
Exactly. One of the main use cases we have for Sieve notify is in what I
believe they call a "sensitive" environment - not cut off completely from the
rest of the world, but with strict rules about what can and cannot cross
boundaries. Since messages, including various sorts of notifications, cannot
leave this environment, the goal is to generate notifications that basically
say "there's soemthing over here you need to look at" but which never say any
more than that and send those out. (Yes, I'm well aware of the potential for
traffic analysis here, but I'm not the one who designed or specified any off
this.) In this use case it is critically important that all messages be able to
generate such a notification. As for loops, they cannot occur since these
notification messages can only leave, not reenter.
I could describe at least one other use-case where notifications cannot be
blocked by auto-submitted fields, but I think this makes the point.
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.
Agreed. FWIW, my suggestion was to add a parameter to auto-submitted that
uniquely identifies the auto-submitter so that that can be checked and loops
detected that way. But this got shot down for some reason I no longer recall.
I also object somewhat to copying Received: fields over that in fact correspond
to hops that a totally different message took. The relationship between the
notification message and the message that triggered it is just too tenuous.
This is a kluge, and IMO not a terribly good one.
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 tried writing text for this some time ago. Didn't get anything worth
posting.
I also think that the "MUST NOT" under discussion is almost certain to
be violated, so I would vote against that.
Our implementation is definitely one that's going to violate it, although we'll
probabky make the check configurable and have it default "on". We simply don't
have a choice here - too many important customers depend on this capability and
if we don't provide it I'm sure someone else will be happy to.
Ned
P.S. I'm also quite worried given the reception the Sieve base got in regards
to the looping potential of redirect that this draft is going to receive at
least one DISCUSS vote from the IESG that's going to be very difficult to
satisfy.