[Top] [All Lists]

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

2010-03-24 16:55:45
On 03/24/2010 02:35 AM, Chris Newman wrote:
> 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 :-).

That's how I implemented it.

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.

> 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;max(_at_)example(_dot_)org"
when we also have
    envelope :from :is "max(_at_)example(_dot_)org"

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.

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

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.

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

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

sieve mailing list