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
reviewed?)
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.
Ned
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve