Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]

From: Alexey Melnikov <[email-masked]>
Date: Tue, 01 Apr 2008 20:19:23 +0100

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> Folks, Cyrus and I as chairs need more feedback on whether SHOULDs 
>> need to be changed to MUSTs. See my forwarded reply.
>
> I don't mind making these MUST.
>
> Except that I do just a little, but I'd wiggle even in case of MUST. 
> Details below.
>
>>>>   o  The "Subject:" field of the notification message MUST
>>>
> ...
> If I were to implement notify-mailto, my code might use different RFC 
> 2047 encoding.

This doesn't contradict the MUST, as it says nothing about encodings.

> If the original subject is invalid in some way I wouldn't respond in kind.

Can you clarify?

>>> The part that reads:
>>>
>>>      If ":from" is not specified or is not valid, the envelope 
>>> sender      of the notification message SHOULD be set either to the 
>>>      envelope "to" field from the triggering message, as used by 
>>>      Sieve, or to a fixed email address (so it "comes from the      
>>> notification system"), at the discretion of the implementation.
>>>
>>> already list all possible alternatives, so I don't think it is a 
>>> SHOULD either.
>>
> Those aren't all possible alternatives, so although I don't mind MUST 
> I rather like keeping SHOULD. (One other alternative is a system 
> address with a single-use subaddress.)

Ok, you and Barry have convinced me that this SHOULD is fine.
Also, how about deleting the word "fixed" above?

---

From: Michael Haardt <[email-masked]>
Date: Wed, 02 Apr 2008 10:15:41 +0200

> Also, how about deleting the word "fixed" above?

"Fixed" does indeed not hit the point, but do you have a better
suggestion?

The idea was to allow the system to used a fixed address, or a fixed
addressing scheme, no matter if the variable part is a RFC subadressing
detail or some other kind of subadressing, that can be recognised as such,
telling the mail "comes from the notification system".  The quoted part
tells exactly what was tried to express.  I would appreciate a better
wording, but can't think of any.

It is definitively a SHOULD, if we can't even specify it sharply.

Michael

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 2 Apr 2008 10:15:42 +0200

>> If the original subject is invalid in some way I wouldn't respond in kind.

You thought the syntax of Subject is simple enough for everyone?

Some MTAs will give you a Subject field that contains null bytes, BELs 
and other stuff that really should be encoded.

If the sender uses crapware, you can get a Subject field that contains 
encoded-words, but the encoded-words are just wrong, and the rules in 
RFC 2047 don't produce the result users want.

     Subject: =?iso-8859-1?q?Are you there, Alexey??=

Those are from clueless but innocent senders. Nasty senders can give you 
this and worse:

     Subject: =?us-ascii?q?=0D=0A=0D=0DBody=? text?

There's more. If you want I can dig through our test messages. But these 
examples should be enough.

In these well-considered cases, I would do something other than what the 
mailto-notify document says, and I think I'd be right, so SHOULD seems 
better than MUST to my eyes. But as I said, I don't object to MUST. 
MUST is about valid input, and at least two of those three examples 
aren't valid.

>>>>      sender      of the notification message SHOULD be set either 
>>>>      to the envelope "to" field from the triggering message, as 
>>>>      used by Sieve, or to a fixed email address (so it "comes from 
>>>>      the      notification system"), at the discretion of the 
>>>>      implementation.
>>>>

Fine.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 02 Apr 2008 13:05:17 +0100

>wording, but can't think of any.
I think the following would be better:

 or to an email address associated with the notification system

This avoids the argument about whether there is a single addresse, whether it must be completely static, etc.

>It is definitively a SHOULD, if we can't even specify it sharply.
Agreed.

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 02 Apr 2008 15:47:07 +0200

On Wed, 2008-04-02 at 13:05 +0100, Alexey Melnikov wrote:
> This avoids the argument about whether there is a single addresse,
> whether it must be completely static, etc.

this is *exactly* what I was going to suggest myself :-)

-- 
best wishes,
Kjetil T.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 02 Apr 2008 21:27:47 +0100

> and other stuff that really should be encoded.

MTAs doing that are simply broken.

Now, if a user used encoded-character to specify such garbage in the 
:message value, that is another story. Hmm, I think we need to 
specifically allow implementations to alter Subject in such cases.

> Those are from clueless but innocent senders. Nasty senders can give 
> you this and worse:
>
> There's more. If you want I can dig through our test messages. But 
> these examples should be enough.
>
> In these well-considered cases, I would do something other than what 
> the mailto-notify document says, and I think I'd be right, so SHOULD 
> seems better than MUST to my eyes. But as I said, I don't object to 
> MUST. MUST is about valid input, and at least two of those three 
> examples aren't valid.

Exactly (last sentence). And the MUST doesn't tell anything about encodings.

>>> Those aren't all possible alternatives, so although I don't mind 
>>> MUST I rather like keeping SHOULD. (One other alternative is a 
>>> system address with a single-use subaddress.)
>>

I believe I've already suggested a better replacement for this in 
another message.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 02 Apr 2008 21:25:17 +0100

Barry Leiba wrote:

> Alexey didn't forward my response to Hannes's review, so here's the 
> relevant part of it:

Mea culpa.

> --------------------------------------------------------
> On the SHOULD vs MUST list, Alexey has actually had the same 
> questions.  It's a clarification I've recently put in, because the 
> text had said "is" (as in, "If the mailto URI contains a "body" 
> header, the value of that header is used as the body of the 
> notification message.")
>
> I considered it this way:  In cases where it seemed that it really 
> matters -- that some sense of interoperability of notifications is 
> affected -- I used MUST. Otherwise, I used SHOULD or MAY.  In other 
> words, I tried to avoid using MUST, where MUST wasn't necessary.
>
> Alexey commented to me that it seemed to him that if there was no 
> other reasonable choice, we ought to have MUST.  On the other hand, it 
> seems to me that if there's not a *reason* for MUST, we ought to leave 
> the choice to the implementor (or to whoever configures the system, or 
> whatever), rather than being needlessly specific about something that 
> really doesn't matter.
> --------------------------------------------------------
>
> I'm willing to change to MUST (obviously, I will if that's the WG 
> consensus), but my strong sense is that it's wrong to prescribe 
> behaviour that doesn't matter.  For Sieve notifications, it seems to 
> me that "interoperability" means that one can move a script to another 
> Sieve implementation and get reasonably consistent results in the 
> notifications, such that the user would have a substantially similar 
> experience.

Agreed.

> My sense, there, is that what matters most is the subject of the 
> message, so that's the only MUST (apart from Auto-Submitted, which has 
> a functional purpose).

That make sense.

I would also add SMTP MAIL FROM to this category, as it is frequently 
used for Sieve filtering.

> The other part that's probably important is the body, but there are 
> various reasons for an implementation to want to control the body -- 
> security configuration, notification infrastructure, whatever.

Ok. I wish you added some text to the document stating that. This would 
remove any further questions why it is only a SHOULD.

I wasn't entirely clear of why you chose SHOULD in various places, so 
thanks for clarifying.

> So that's a SHOULD.
>
> In particular, I don't agree with Alexey's thought that if WE can't 
> think of an alternative value for a field, our advice should be MUST.

I would slightly reword this: when using SHOULD one should have an 
example or at least gut feeling of when it can't be violated.

> I much prefer the other approach: if there's not a compelling reason 
> for MUST, make it SHOULD and let the implementation determine whether 
> there's a good reason not to comply with that (remember the meaning of 
> SHOULD).

It is a bit silly to argue this in general case. I would rephrase my 
objections based on the guiding principal you've specified above.

> I normally don't like SHOULD in protocols.  This is a case where I 
> think SHOULD is entirely appropriate.

---

From: Michael Haardt <[email-masked]>
Date: Wed, 02 Apr 2008 22:42:35 +0200

> This avoids the argument about whether there is a single addresse, whether it must be completely static, etc.

Perfect, thanks!

Michael

---

From: "Mark E. Mallett" <[email-masked]>
Date: Sun, 6 Apr 2008 15:51:46 -0400

> it must be completely static, etc.

Sorry to quote so much, but it's all relevant, I think.

Even though it adds another case, I would also consider the example
set by the vacation extension, which says:

     Unless explicitly overridden with a :from parameter, the From field
     SHOULD be set to the address of the owner of the Sieve script.

To me, this is preferable to defaulting to a system-wide notification
address, so I would want to add "the address of the owner of the sieve
script" into the mix as another possibility for a default.  I suppose
that the current wording could be interpreted to mean a fixed address
associated with the user, since it says only "a fixed email address" but
the parenthetical comment '(so it "comes from the notification system")'
almost certainly refines it to mean a fixed system-wide address.

(This might be seen as ironic, since as you may recall that I didn't
like that exact wording in 'vacation', but I did agree with the spirit.
And now the precedent is there so...)

mm

---

From: Michael Haardt <[email-masked]>
Date: Fri, 11 Apr 2008 12:22:41 +0200

Let me try to get rid of the quoted discussion.  We ended up with
this so far:

  If ":from" is not specified or is not valid, the envelope 
  sender of the notification message SHOULD be set either to the 
  envelope "to" field from the triggering message, as used by 
  Sieve, or to an email address associated with the notification system,
  at the discretion of the implementation.

Now you suggest, after we got rid of the fixed address of the notification
system, we should get rid of the fixed envelope "to" field as well and
replace it with "the address of the owner of the Sieve script", which
is what vacation does.  The version would be:

  If ":from" is not specified or is not valid, the envelope 
  sender of the notification message SHOULD be set either to the 
  the address of the owner of the Sieve script,
  or to an email address associated with the notification system,
  at the discretion of the implementation.

Correct so far?

Sounds good to me. :)

Michael

---

From: "Mark E. Mallett" <[email-masked]>
Date: Sat, 12 Apr 2008 14:05:58 -0400

>   at the discretion of the implementation.

I didn't [intend to] suggest getting rid of the envelope-to field from
the list of choices, but only to add an address associated with the
Sieve script to that list.  I think the owner's address is at least as
good a choice for a fixed address as a system-wide one.  It may be
more readable to express it as a list, e.g.:

   If ":from" is not specified or is not valid, the envelope 
   sender of the notification message SHOULD be selected from
   one of the following, at the discretion of the implementation:
     - the envelope "to" field from the triggering message, as used
       by Sieve;
     - the address of the owner of the Sieve script;
     - an email address associated with the notification system.

At any rate, I was attempting to add one thing to the list of choices,
not subtract from it.

mm

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 13 Apr 2008 15:54:31 +0100

>     - the address of the owner of the Sieve script;
But "the envelope "to"..." is "an address of the owner".
If multiple email aliases go to the same mailbox, I think it would be 
better to use the envelope "to", so that a recipient of mailto 
notifications can distinguish between different aliases.

---

From: "Mark E. Mallett" <[email-masked]>
Date: Sat, 19 Apr 2008 14:18:17 -0400

[hmm, missed this until now]

> But "the envelope "to"..." is "an address of the owner".

But not necessarily *the* address of the owner, i.e., not a fixed
address.

Note also that this mention of the "envelope 'to'" should probably be
qualified as "final envelope to" (the word "final") as has been done
elsewhere.

> notifications can distinguish between different aliases.

I see that, too; and I wouldn't want an implementation to be prevented
from doing that.  But see below.

> >    - an email address associated with the notification system.

I'm actually not really happy with that wording "the address of the
owner of the Sieve script" either.  What I am really aiming for (as
quoted above, even) is to allow an implementation to optionally be
configured with an email address associated with notification messages
for any individual mailbox, and that it could choose to use that as a
default return address if present.

I agree that the envelope-to is the best choice if the application
hasn't been configured to use a fixed address.  But I also think that
having the only choice for a fixed address be a system-wide one isn't
fine-grained enough.  So maybe instead of "the address of the owner
of the Sieve script", more like:

  - an email address associated with notification messages sent on
    behalf of the email-address receiving the message;

and it's up to the implementation how that association is made, or
whether it's made at all.  One could actually interpret that to cover a
system-wide address, as well, maybe with some slight fiddling, so that
the other choice (the "email address associated with the notification
system") could be dropped.

This seems awfully trivial but I'm having a hard time being concise
about it, sorry.

mm

---

From: Michael Haardt <[email-masked]>
Date: Tue, 22 Apr 2008 09:52:37 +0200

> system") could be dropped.

How about that?

   If ":from" is not specified or is not valid, the envelope sender of
   the notification message SHOULD be set to an email address associated
   with the recipient or the notification system, at the discretion of
   the implementation (common choices are the final envelope recipient
   or a fixed, system-wide sender).

Widen it once more and I suggest "... SHOULD be set." (no more ;)

Michael