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.
Since message-ids are generated by clients they leak information about what
client someone uses. I don't know if such leakage is acceptable; I suspect not.
IWould the rules of that sensitive prevent use of Message-Based-On?
My guess is yes.
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.
I don't see it. AFAIK nobody is proposing using message-ids or any sort of
information that originates with clients for this. And any identifier that
appears in an auto-submitted field is not comparabie, for several reasons:
(1) MUAs generate auto-submitted fields rarely, and in the cases where they
do they aren't going to insert a parameter we have yet to specify.
(2) The internal MTAs that generate this paramster may do so using their own
names, but those names are already present in other header fields in
notifucations, so this leaks no additional information. It is already
accepted that traffic analysis can be performed here.
(3) Even if for some reason we clients to be able to generate such a parameter,
since this is a new parameter we can specify a one way hash scheme for
it.
In any case, I only mentioned this proposal in passing; the addition of a new
header field to the trace header set is a fairly big deal and I'm not sure it
is warranted to solve this particular problem.
Ned