Subject: draft-ietf-sieve-notify-mailto-10.txt

From: Barry Leiba <[email-masked]>
Date: Thu, 04 Dec 2008 10:06:57 -0500

I've just posted a final version of draft-ietf-sieve-notify-mailto.  It resolves 
all the last-call and IESG issues, including Cullen's DISCUSS position, which he 
should be clearing when he reviews this version.

There are some editorial changes to fix some nits and some old references.
The substantive changes are these:

Changed in "2.7.1.  The Auto-Submitted header field":

   The auto-notified Auto-Submitted field MUST include one or both of
   the following parameters:

This makes at least one of the "owner-*" parameters required, so that we can be 
sure that an accidental recipient of notification messages will have a way to 
contact the sending domain and get the problem fixed.

Added to "5.  Security Considerations":

   Email addresses specified as recipients of notifications might not be
   owned by the entity that owns the Sieve script.  As a result, a
   notification recipient could wind up as the target of unwanted
   notifications, either through intent (using scripts to mount a mail-
   bomb attack) or by accident (an address was mistyped or has been
   reassigned).  The situation is arguably no worse than any other in
   which a recipient gets unwanted email, and some of the same
   mechanisms can be used in this case.  But those deploying this
   extension have to be aware of the potential extra problems here,
   where scripts might be created through means that do not adequately
   validate email addresses, and such scripts might then be forgotten
   and left to run indefinitely.

   In particular, note that the Auto-Submitted header field is required
   to include a value that a recipient can use when contacting the
   source domain of the notification message (see Section 2.7.1).  That
   value will allow the domain to track down the script's owner and have
   the script corrected or disabled.  Domains that enable this extension
   MUST be prepared to respond to such complaints, in order to limit the
   damage caused by a faulty script.

   Problems can also show up if notification messages are sent to a
   gateway into another service, such as SMS.  Information from the
   email message is often lost in the gateway translation, and in this
   case critical information needed to avoid loops, to contact the
   script owner, and to resolve other problems might be lost.
   Developers of email gateways should consider these issues, and try to
   preseve as much information as possible, including what appears in
   email trace headers and Auto-Submitted.

Please comment quickly if you have a problem with any of this.  Otherwise, the 
new draft will go through with these changes.

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 04 Dec 2008 16:36:55 +0000

Barry Leiba wrote:

> I've just posted a final version of draft-ietf-sieve-notify-mailto.  
> It resolves all the last-call and IESG issues, including Cullen's 
> DISCUSS position, which he should be clearing when he reviews this 
> version.
>
> This makes at least one of the "owner-*" parameters required, so that 
> we can be sure that an accidental recipient of notification messages 
> will have a way to contact the sending domain and get the problem fixed.

I think this is needed in order to comply with the traceability 
requirement specified in the Sieve notify document.

> Please comment quickly if you have a problem with any of this.  
> Otherwise, the new draft will go through with these changes.

This looks good to me.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 4 Dec 2008 17:53:36 +0100

Fine stuff.

Arnt

---

From: Michael Haardt <[email-masked]>
Date: Fri, 05 Dec 2008 16:31:54 +0100

>    the following parameters:

Fine with me, but now it is required: Who is responsible for setting
that address in the owner-email? The implementation? The user? Is it
related to ":from"?

Since the point is to identify the sender, I suppose the implementation
is responsible for the values of owner or token, but we should make
that clear.  An example for the owner could be the envelope recipient
of the triggering message (for those who can't imagine what the owner
might be).

Michael

---

From: Barry Leiba <[email-masked]>
Date: Fri, 05 Dec 2008 10:36:08 -0500

> is responsible for the values of owner or token

The point is not to identify the "sender"; it's to identify the owner of the 
sieve script, and that's all made clear in section 2.7.1.  Only the 
implementation knows how to do that.  I don't think there's more that needs to be 
said there.

Barry

---

From: Michael Haardt <[email-masked]>
Date: Fri, 05 Dec 2008 17:10:01 +0100

> implementation knows how to do that.  I don't think there's more that needs to be 

I disagree and would appreciate adding

  It is up to the implementation if ":from" sets the parameter value.

before the example in section 2.7.1.  That allows an implementation not
to do that, exposing the script owner, or allowing it if it can be sure
the information is correct, offering more privacy.  Either way, it says
the implementation is authoritative for setting the value.  I feel as
it is, it may be misunderstood, because in the example in section 3 the
owner is identical to the sender, but just coincidentally so.

It does not change the current semantics, but expresses what is obvious
to you and possibly not as obvious to somebody else.  The largest
misunderstanding about common sense is it being common, isn't it? ;)

Michael

---

From: Barry Leiba <[email-masked]>
Date: Fri, 05 Dec 2008 11:20:07 -0500

>   It is up to the implementation if ":from" sets the parameter value.

Absolutely not.
It is critical that the value represent the *owner* of the script, and that is 
the *only* criterion that's relevant.  The "from" might or might not be the same 
as the owner, and has no direct bearing on this.

Barry

---

From: Michael Haardt <[email-masked]>
Date: Fri, 05 Dec 2008 18:39:48 +0100

> as the owner, and has no direct bearing on this.

If the owner has multiple addresses, he may want to use a certain one.
Do I get you right in that the choice MUST be made outside Sieve and
the implementation MUST NOT use the value of ":from" for a hint?

If so:

  The sender address specified by ":from" MUST NOT set the parameter
  value, the value MUST be set by the implementation to the owner of
  the script.

That would be consistent with the choice of the token, but as you can
see from my first interpretation, something needs to be said about this.

Michael

---

From: Barry Leiba <[email-masked]>
Date: Fri, 05 Dec 2008 13:19:56 -0500

>> the *only* criterion that's relevant.  The "from" might or might not be the
>> same  as the owner, and has no direct bearing on this.
>

I'm not saying that the implementation should or should not use ":from" to set 
this.  I'm saying that the ownership of the script and what to put in the owner-* 
parameter(s) is known only to the implementation, and that we can give NO advice 
on this other than to say, as we have, that it's a value that can be used to 
contact the owner.

I don't think Michael and I are going to agree on this, so I'd like to hear from 
other WG participants.  Does anyone else have an opinion?

Barry

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 5 Dec 2008 20:48:51 +0100

Barry Leiba writes:
> I don't think Michael and I are going to agree on this, so I'd like to 
> hear from other WG participants.  Does anyone else have an opinion?

owner-* is not something that's displayed often, so it's not important 
what's there as long as it's correct. In the case of From I think it's 
important to have the preferred form of the address, but owner-* is not 
displayed often enough.

For this reason I think it's better to give the implementation all of 
the responsibility, and not even give the script author a chance to 
typo.

My two cents.

Arnt

---

From: Michael Haardt <[email-masked]>
Date: Fri, 05 Dec 2008 21:37:25 +0100

> the responsibility, and not even give the script author a chance to 

I think we talk about two issues here: Do we need more text to describe
the parameter value for owner? Barry says no, I say yes.

The next is: Who may influence the value?

We agree on so far is that ":from" does not set the owner unconditionally,
and not even on the condition it is accepted as sender for sure.
We further agree that sender and owner may differ.

The example contains the common case of owner and sender being equal
and I want to make sure that people reading the text know for sure
that's not a fixed rule.  The value may be any other address as well,
as long as it belongs to the owner.

I don't consider of the frequency of display important, but the fact
that the value may unveil which mailbox the notification originated from,
violating my privacy looking at the networks the notification may cross.

That does not mean I would like to see ":from" influencing the
owner.  All I would like to specify is WHO is responsible, so
people using Sieve can be sure WHO to address for a changed
owner address, should they care.  If we say

  The parameter value depends on the implementation and may or may
  not be related to the sender of the notification message.  The only
  requirement is that the address reaches the owner of the script.

all my issues would be addressed, because it defines who is responsible
and that I can not expect ":from" to hide my identity, but that I
must look at what the implementation has to offer, and it allows the
implementation to use e.g. encrypted owner addresses or anything else.

Michael

---

From: Ned Freed <[email-masked]>
Date: Sat, 06 Dec 2008 17:14:48 -0800 (PST)

> the responsibility, and not even give the script author a chance to

+1

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 09 Dec 2008 11:20:50 +0000

>the parameter value for owner? Barry says no, I say yes.
I am largely with Barry on this. See below.

>violating my privacy looking at the networks the notification may cross.
I think you are asking for owner-token being used instead of owner-email.

>  The parameter value depends on the implementation
>
So far so good.

>  and may or may
>  not be related to the sender of the notification message.
>
But it is *always* related to the sender of the notification in some way.

>  The only
I don't think this is even true. The only requirement is that the 
sysadmin operating the system that is running the Sieve engine can 
figure out which Sieve script (and for which user) generated a notification.

>implementation to use e.g. encrypted owner addresses or anything else.

I would not argue against having another example, that shows that 
owner-email can be different.

---

From: Michael Haardt <[email-masked]>
Date: Tue, 09 Dec 2008 12:49:25 +0100

> I think you are asking for owner-token being used instead of owner-email.

The owner-token may solve the problem, but there is no technical reason
to restrict owner-email not doing that as well, plus giving a mail
address instead of letting the victim figure out who to ask.

> >  The parameter value depends on the implementation

I would be glad to see that included!

> figure out which Sieve script (and for which user) generated a notification.

Now I am really confused.  I thought the owner would be the user the
script belongs to, not the admin of the sending system.  The admin should
always be able to figure out abuse.

Anyway: If we can agree on "it's implementation-dependent", we don't
have to define further terms, and it addresses all my issues.

> owner-email can be different.

Perhaps that's a good idea, despite showing something that depends on
the implementation, but at least people see it does!

Michael

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 09 Dec 2008 15:20:53 +0000

>address instead of letting the victim figure out who to ask.
I agree. But saying that owner-email is or isn't related to :from is of 
no help in this case.

>script belongs to, not the admin of the sending system.
>
Correct. But it doesn't mean that it is reachable via email ;-).
My point is that the requirement to be "reachable" might be too strong 
for some deployments.

>The admin should always be able to figure out abuse.
>