Subject: I-D Action:draft-ietf-sieve-notify-mailto-08.txt

From: [email-masked]
Date: Wed, 9 Jul 2008 08:00:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title           : Sieve Notification Mechanism: mailto
	Author(s)       : B. Leiba, M. Haardt
	Filename        : draft-ietf-sieve-notify-mailto-08.txt
	Pages           : 16
	Date            : 2008-07-09

This document describes a profile of the Sieve extension for
notifications, to allow notifications to be sent by electronic mail.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-mailto-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 15 Jul 2008 13:07:58 +0100

>notifications, to allow notifications to be sent by electronic mail.
Folks,
I believe Barry addressed all outstanding issues with the document but one:

 Should a notification be generated if an Auto-Submitted header field 
exists (apart from "no")?

Barry commented on this issue:

I still don't see clear support for changing this, and I still worry 
that it's dangerous. There are certainly use cases for it, but since 
this is a major way we're suggesting avoidance of notification loops, I 
think it's a Very Bad Idea.

-08 still has the MUST NOT. I'd strongly prefer to leave it that way.

===
I tend to agree with Barry. I think the last round of discussion 
suggested that the WG has no consensus on this issue. So my 
recommendation is to leave the current text as is and publish the 
document. *If* there is enough support later for allowing notifications 
on notifications, the document can be revised(, or a small extension to 
it can be published). But for now I think it is more important to 
publish the document.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 15 Jul 2008 07:49:41 -0600

> it can be published). But for now I think it is more important to 

+1

/psa

---

From: Barry Leiba <[email-masked]>
Date: Tue, 15 Jul 2008 10:17:32 -0400

> it can be published). But for now I think it is more important to 

Despite my strong opinion on this point, I think it's not sufficient to 
say that if there's not a call to change it, the current "MUST NOT" text 
stays.  At one point we had some level of consensus for the current 
text, but there's been enough dissent that we explicitly need new consensus.

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

Let's try to get clear consensus on this.  I propose that in the event 
of no clear consensus, we have to go with (3).

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 15 Jul 2008 15:42:15 +0100

Barry Leiba wrote:

> sufficiently important that the text should be changed.  [Please 
> suggest new text, in this case.]
>
> danger very clearly.  [In this case, you can suggest text, or I'll 
> craft it.]

Now that you mention this I prefer SHOULD NOT.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 15 Jul 2008 09:10:11 -0600

> Now that you mention this I prefer SHOULD NOT.

So I take it that means:

    Implementations SHOULD NOT trigger notifications for messages
    containing "Auto-Submitted:" header fields with any value other than
    "No".

Then I assume we want to add a clause after that saying something like 
"because notifications triggered by such messages can result in mail loops."

/psa

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 16 Jul 2008 10:08:36 +0200

+1

> 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 could go along with that, assuming suitable wording, but I find it 
difficult to come up with such wording. IMO there is considerable value 
in having a really simple rule on Auto-Submitted and loops.

Arnt

---

From: Michael Haardt <[email-masked]>
Date: Fri, 18 Jul 2008 14:57:09 +0200

> sufficiently important that the current "MUST NOT" text should stay.

I vote for this.  It's simple and effective, exactly how loop avoidance
should be.

Michael

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 21 Jul 2008 14:45:56 -0400

> I vote for this.  It's simple and effective, exactly how loop avoidance

Shutting down the mail system would also be simple and effective.

---

From: "Mark E. Mallett" <[email-masked]>
Date: Mon, 21 Jul 2008 16:15:30 -0400

> danger very clearly.  [In this case, you can suggest text, or I'll craft 

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

---

From: Ned Freed <[email-masked]>
Date: Mon, 21 Jul 2008 14:44:57 -0700 (PDT)

> 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

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.

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

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

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 22 Jul 2008 12:33:14 +0200

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 22 Jul 2008 12:47:48 +0200

Ned Freed writes:
> 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.

These are two of the three (or four) options I'm aware of. The third is 
to accept that mail loops happen, but make them less harmful by slowing 
them down. A thousand messages per day isn't so bad, at least not 
compared to 100,000.

It's also possible to combine. The document could say "If the incoming 
message has an Auto-Submitted field, a return-path of <>, or other 
signs that it was automatically generated, then the outgoing 
notification MUST be delayed by at least two minutes", with reference 
RFC 4865 informatively.

I'm not really in favour of such a rule. I like the simple 
Auto-Submitted rule. I'm just mentioning this since it is a 
possibility, since we need to find some compromise rule that everyone 
can live with, and this is an area we haven't discussed.

Arnt

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Tue, 22 Jul 2008 11:46:00 +0000

> > and loops detected that way. But this got shot down for some reason I 

If we could trust that Auto-submitted doesn't get clobbered, it would
suffice to say that a message containing an "Auto-submitted:
auto-notified" header should be silently ignored.

Unfortunately, I don't think we can trust that Auto-submitted is truly
handled as a trace header (ie. multiple instance header) in the
multitude of homegrown applications out there sending automatic
responses.

> notification MUST be delayed by at least two minutes", with reference 

This is just too ugly.  Users will be forcing implementers to add an
override for this behaviour.

> can live with, and this is an area we haven't discussed.

Here's an alternative compromise:  An implementation can not send a
notification in response to a message with "Auto-submitted: !no" unless
the number of Received headers in the notification messages is higher
than in the original message.

-- 
regards,
Kjetil T.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 22 Jul 2008 13:50:34 +0200

Kjetil Torgrim Homme writes:

>>  These are two of the three (or four) options I'm aware of. The third 
>>  is to accept that mail loops happen, but make them less harmful by 
>>  slowing them down. A thousand messages per day isn't so bad, at 
>>  least not compared to 100,000.
>>
>>  It's also possible to combine. The document could say "If the 
>>  incoming message has an Auto-Submitted field, a return-path of <>, 
>>  or other signs that it was automatically generated, then the 
>>  outgoing notification MUST be delayed by at least two minutes", 
>>  with reference RFC 4865 informatively.
>

Sure. I'd make the period configurable in my own code, down to 1 second. 
What about it?

>>  possibility, since we need to find some compromise rule that 
>>  everyone can live with, and this is an area we haven't discussed.
>
> notification in response to a message with "Auto-submitted: !no" 
> unless the number of Received headers in the notification messages is 
> higher than in the original message.

You mean by generating dummy fields?

I'm not in favour, but I can live with that too if that's what it takes 
to get WG consensus, IESG blessing and an RFC.

Arnt

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Tue, 22 Jul 2008 14:05:40 +0200

On Tue, 2008-07-22 at 13:50 +0200, Arnt Gulbrandsen wrote:
> Received: by <host> (dummy inserted by sieve); <date>
> Received: by <host> (dummy inserted by sieve); <date>
> Received: by <host> (dummy inserted by sieve); <date>

I think I'd prefer if this trick wasn't mentioned explicitly, but yes, I
think that would be a valid implementation.  The draft says

        The "Received:" fields from the triggering message MAY be
        retained in the notification message [...]

and I personally would prefer it if implementations chose that route.

> to get WG consensus, IESG blessing and an RFC.

ok.
-- 
regards,
Kjetil T.

---

From: "Nigel Swinson" <[email-masked]>
Date: Tue, 22 Jul 2008 14:00:43 +0100

> Let's try to get clear consensus on this.  I propose that in the event of 
> no clear consensus, we have to go with (3).

I'm with option 3 just now.  My reasons, some of which have already been 
touched on:

I think the intent of sieve-notify was to do things like notify mobile 
devices, or at least devices with some limited resources that the user has 
more immediate access to.  Re-scanning the abstract seems to back this up. 
As such I think those devices are very unlikely to auto-reply to anything, 
or if they do, then it may not be until they make a connection and receive 
the notification, which would lead for a very slow mail loop.  But then what 
I think the intent of sieve-notify is, and what it'll get used for can of 
course be completely different.

Sieve-notify-mailto is therefore in some ways a poor fit with sieve-notify, 
cos the target could very very easily be capable and willing to auto-reply, 
in which case mail loops become much more likely and dangerous (hence we are 
having this discussion).  If the purpose of sieve-notify-mailto is to hide 
sensitive information from the inbound message, then I wonder if it's better 
handled by modifying redirect rather than piggy backing onto sieve-notify, 
then we're not adding to the existing mail loop concerns created by the use 
of redirect, and standard loop prevention mechanisms apply.  I think the use 
cases proposed to make folks vote for option 2 would be better handled by an 
alternative notification mechanism like SMS where no auto-reply is expected, 
and therefore there's a greatly reduced loop risk.  Option 1/3 both try to 
create a "no auto-repsonse" mimicing what is expected by the other 
sieve-notify mechanisms that it was originally designed for.

So this whole discussion has made me very reluctant to go anywhere near 
implementing sieve-notify-mailto, rather sticking to SMS notifications and 
redirect if I can.

Nigel

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 22 Jul 2008 15:15:04 +0200

Nigel Swinson writes:
> So this whole discussion has made me very reluctant to go anywhere 
> near implementing sieve-notify-mailto, rather sticking to SMS 
> notifications and redirect if I can.

I wanted to do the same thing, but then I found out that the base notify 
document says you MUST implement mailto.

Arnt

---

From: Ned Freed <[email-masked]>
Date: Tue, 22 Jul 2008 08:04:34 -0700 (PDT)

> 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

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

---

From: Ned Freed <[email-masked]>
Date: Tue, 22 Jul 2008 10:05:47 -0700 (PDT)

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

> As noted above, I think this is very different from redirect, because we
> are generating a new message to a (presumably fixed) recipient, not
> forwarding or responding to an existing message.

FWIW, the Sieve variables extensions makes variable (in the sense that they
depend on the input message) possible. For example:

require ["notify", "mailto"];
if address :matches "from" "*" {
  notify :message "blah blah"
              :importance "3"
              "mailto:${1}";
}

However, given that addresses can be and sometimes are handled by the routing
fabric in fairly perverse ways, including various highly dynamic routing
schemes, I don't think this changes the situation much if at all.

				Ned

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 23 Jul 2008 12:43:11 +0200

On Tue, 2008-07-22 at 21:31 -0400, Jeffrey Hutzelman wrote:
> Kjetil Torgrim Homme <[email-masked]> wrote:
> That seems problematic, if any of the servers mentioned in those headers 
> also appear on the path the notification takes and are using them to do 
> loop detection.

does anyone do this?  such a scheme will be wrought with false positives
in the presence of forwarding or even mailing lists, unless they expose
detailed recipient information, which would conflict with privacy
concerns.

> The notification, which in fact is a _new_ message, has 
> _not_ been received or processed by those servers.

its existence is a direct and automatic consequence of the original
message, so I don't think it is unreasonable to be able to trace it back
to the Prime Mover, as the ancient Greeks would say.

> What's the point of this?  Is it to drive the count of Received headers in 
> notifications up so high that they don't actually get through?

basically, yes :-)

seriously, the hop count limits are generally generous, so I don't think
this will be a problem in practice.  e.g., your server adds one
Received, and mine adds three.  Majordomo at IMC introduces 4 more hops,
which brings the total to 8.  that's a lot of lee-way for additional
forwarding servers.
-- 
regards,
Kjetil T.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 26 Jul 2008 22:02:27 +0100

>detected that way. But this got shot down for some reason I no longer recall.
I thought "owner-token" described in section 2.7.1 is your parameter?