Ned Freed writes, quoting Mark E. Mallett:
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.
Suppose there were some header field which carried enough identification
to avoid loops. Perhaps a widely supported header field called
"Message-Based-On:" with a list of message-ids. There isn't any such
thing, but suppose there were.
IWould the rules of that sensitive prevent use of Message-Based-On? I
have a feeling that the rules would forbid leaking those message-ids
back out of the sensitive area. If that feeling is right, then there is
a basic conflict between your customer's needs and the IESG/IETF rules.
Arnt
(PS: Another, unrelated reply in a moment.)