On Mar 24, 2010, at 2:01 AM, Arnt Gulbrandsen wrote:
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?)
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"
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.
FYI, the former Sun Messaging Server (now Oracle) has had FUTURERELEASE support
since
the 7.0 version -- that's as of July 2008.
Regards,
Kristin
(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
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve