Subject: [sieve] review of draft-freed-sieve-notary-06

From: Chris Newman <[email-masked]>
Date: Tue, 23 Mar 2010 18:35:57 -0700

Section 4:

>   orcpt -  Match the original recipient, or ORCPT, value in decoded
>      form associated with the TO address used in the SMTP RCPT TO

The term "in decoded form" is vague and can be interpreted different ways 
(for example, I might consider removal of the "rfc822;" prefix to be part 
of decoding :-).

I suggest this say "with xtext encoding (RFC 3461 section 4) removed".

Section 6:

>   notify-value = DQUOTE notify-esmtp-value DQUOTE

The "notify-esmtp-value" can be interpreted to allow comments, empty comma 
fields and folding whitespace.  You either have to outlaw that in prose or 
have a bit more detail.  I suggest:

   notify-value = DQUOTE ("NEVER" / notify-esmtp-list) DQUOTE

   notify-esmtp-list = notify-list-element *("," notify-list-element)

>   The notify-esmtp-value production is defined in Section 4.1 of
        ^^^^^^^^^^^^^^^^^^
        notify-list-element

Author's Address:

>   Sun Microsystems
    Oracle

Q: Is there a reason this didn't deal with FUTURERELEASE (4865) at the same 
time?

		- Chris

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 24 Mar 2010 10:01:33 +0100

On 03/24/2010 02:35 AM, Chris Newman wrote:
> The term "in decoded form" is vague and can be interpreted different
> ways (for example, I might consider removal of the "rfc822;" prefix to
> be part of decoding :-).

That's how I implemented it.

I see it was wrong. (Ned, did I complain about missing examples when I 
reviewed?)

> I suggest this say "with xtext encoding (RFC 3461 section 4) removed".

I'd prefer that a script sees addresses in only one format.

Why is this justifiable:
    envelope :orcpt :is "rfc822;[email-masked]"
when we also have
    envelope :from :is "[email-masked]"

That difference sounds like a good way to trip up human script authors.

> Q: Is there a reason this didn't deal with FUTURERELEASE (4865) at the
> same time?

Futurerelease seems to go dead. I'm the only implementer AFAICT, and 
it's been three years already.

(Repeating myself: Delaying mail is a fine way to make mail loops 
harmless. Just a 30-second delay changes a 2000-per-hour loop into a 
100-per-hour loop, much easier for operators to handle.)

Arnt

---

From: [email-masked]
Date: Wed, 24 Mar 2010 14:38:13 -0700 (PDT)

> I suggest this say "with xtext encoding (RFC 3461 section 4) removed".

That doesn't really work as a replacement for "in decoded form", so I changed
the item to read:

Match the original recipient, or ORCPT, value associated with the TO address
used in the SMTP RCPT TO command that resulted in this message getting
delivered to this user, with xtext encoding removed. The syntax and semantics
of the ORCPT parameter are defined in Section 4.2 of [RFC 3461]. 

> >   The notify-esmtp-value production is defined in Section 4.1 of

Changed.

>     Oracle

Changed ;-)

> Q: Is there a reason this didn't deal with FUTURERELEASE (4865) at the same

Because Sieve is defined as operating at or around the time of final delivery.
Future release information cannot be present at that point. Delivery-by, OTOH,
last right up to the final delivery point, same as notary.

				Ned

---

From: [email-masked]
Date: Wed, 24 Mar 2010 14:45:55 -0700 (PDT)

> I see it was wrong. (Ned, did I complain about missing examples when I

Well, seeing as how there's an example of how to use orcpt that
includes the rfc822; prefix, I'm not sure what else is needed here.

>     envelope :from :is "[email-masked]"

Because not all ORCPT values in practice are RFC 822 addresses.

> That difference sounds like a good way to trip up human script authors.

I agree, but there's not much I can do about it. Like it or not, there are
other email systems out there and one of the design goals of NOTARY was to
allow interoperable notifications.

> it's been three years already.

We also implement it and I believe we have some people using it. But it makes
no sense to have tests for it in a Sieve extension given that Sieve operates at
or around delivery time. Futurerelease operates at submit time.

> 100-per-hour loop, much easier for operators to handle.)

Agreed; there are use cases people seem to be unaware of.

				Ned

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 24 Mar 2010 15:26:23 -0700

Hi Ned,
Totally a nit, but the first use of "SMTP" in the introduction should have 
a reference.
Also there needs to be "Intended status: Standards Track" on the top (to 
placate one idnit warning - the other two warnings are fine I think).

-- 
Cyrus Daboo

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 25 Mar 2010 13:16:56 +0100

> includes the rfc822; prefix, I'm not sure what else is needed here.

I think you added that after my review ;) Good thing I didn't release 
the code.

> Because not all ORCPT values in practice are RFC 822 addresses.

Good point (he says, in a sad voice).

Arnt