[Top] [All Lists]

Re: Comments on draft-ietf-sieve-notify-mailto-07.txt

2008-04-03 09:42:02

Michael Haardt wrote:

In section 2.7:

  o  The "To:" header field and the envelope recipient(s) of the
     notification message SHOULD be set to the address(es) specified in
     the URI (including any URI headers where the hname is "to").

I think there is a problem with this text. Surely the envelope recipient is specified in the mailto URI itself, not in the to URI header. (Your example in section 3 confirms that.) For example if mailto URI is "mailto:0123456789(_at_)sms(_dot_)example(_dot_)net?", then the envelope recipient is 0123456789(_at_)sms(_dot_)example(_dot_)net and not evil(_at_)master(_dot_)example(_dot_)com(_dot_)

I think the text is also trying to say that both To: header and envelope to should be set to the same value.
To me, the text is correct.  From draft-duerst-mailto-bis-05, section 2.:

  Also note that it is legal to specify both <to> and an <hfname> whose
  value is "to".  That is,


  is equivalent to


  is equivalent to


Ok. I should have checked this myself.

I think it would be helpful if you/Barry add a clarifying example to demonstrate this.

The text asks for both header and envelope recipients to be set to
the recipients specified in the URI, and reminds the reader that
URIs may contain recipients as URI headers, too.
  o  The "Subject:" field of the notification message MUST contain the
     value defined by the :message notify tag, as described in
     [Notify].  If there is no :message tag and there is a "subject"
     header on the URI, then that value SHOULD be used.

I think this SHOULD should be upgraded to a MUST. Reason: I can see use cases when :message is never used and Subject is specified in the mailto URI itself. So I think

Also, Arnt has raised a good question about whether implementations are allowed to strip/alter garbage in :message or subject URI header. I think this should be addressed as well.
I agree on the MUST, because I can't think of reasons not to use the
specified subject.  Concerning garbage: Broken MIME words are not garbage
- they aren't MIME words, but ASCII data.


MIME words that contain odd
characters are not garbage, either.
I was thinking about embedded NULs, CRs and LFs.

I don't see what could be a valid URI subject header, but not a valid
mail subject header.  If there is something like that, the mailto URI
draft should be changed.  Or MUST, for that matter. ;)
I also have a new question. It might be a stupid one, but I will ask it anyway ;-). How References should be handled? Is the new message allowed to reference the original message? Are References: allowed as mailto URI headers?
That's two independent questions.  First the easy one, on URI references
headers.  Could additional references hurt? I don't see why.  Say,
I send someone a mail, and later notifications on triggering messages
that refer to this mail - that may actually be useful, as they build
a nice thread below the first mail.  We should allow that.

Exactly my thought.

Should the triggering message set "In-reply-to:", thus ignoring an URI header of
the same name? To me, it's not a reply, it is a notification.