Ken Murchison wrote:
The IESG wrote:
The IESG has received a request to consider Sieve -- Subaddress
Extension <draft-murchison-sieve-subaddress-05.txt> as a Proposed
Standard. This has been reviewed in the IETF but is not the product
of an IETF Working Group.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg(_at_)ietf(_dot_)org or ietf(_at_)ietf(_dot_)org mailing lists by 2003-4-25.
Just sent in an update. You can grab it from here until it gets posted:
ftp://ftp.oceana.com/pub/drafts/draft-murchison-sieve-subaddress-06.txt
http://www.oceana.com/ftp/drafts/draft-murchison-sieve-subaddress-06.txt
Ken, looks good. 4 comments:
1)You might find FastMail's subdomain detail implementation interesting,
as documented at
http://www.fastmail.fm/docs/faqparts/AliasesAndVirtualDomains.htm#SubDomain
.
It meshes well with your proposed extension - this comment is just an
FYI, not a request for any change.
It exists because many systems don't allow + in email addresses, and
because it's cool.
By the time SIEVE sees the email, however, the address has been
converted, so Sieve can see the canonical form that your extension
understands:
matthewselvey+lists(_dot_)bawug(_at_)f-m(_dot_)Dom
(user+detail(_at_)canonicaldomain(_dot_)Dom instead of
detail(_at_)alias(_dot_)alternatedomain(_dot_)Dom)
This canonical form is in the envelope to, which is (I agree) the best address
to test against.
Example (trimmed) header
Received: ... for <matthewselvey+lists(_dot_)bawug(_at_)f-m(_dot_)Dom>; Fri, 28
Mar 2003 17:23:09 -0500 (EST)
X-Delivered-to: <lists(_dot_)bawug(_at_)me2004(_dot_)sent(_dot_)Dom>
Received: ... for <lists(_dot_)bawug(_at_)me2004(_dot_)sent(_dot_)Dom>; Fri, 28
Mar 2003 17:23:08 -0500 (EST)
Subject: Welcome to the "wireless" mailing list
From: wireless-request(_at_)lists(_dot_)bawug(_dot_)Dom
To: lists(_dot_)bawug(_at_)me2004(_dot_)sent(_dot_)Dom
2)Does the spec leave undefined how it would parse
user+detail1+detail2(_at_)canonicaldomain(_dot_)Dom? It seems to assume only
one separator character.
I suggest :user reference the "leftmost separator" and :detail reference the
"rightmost separator".
That would leave detail1 unextractable by this extension however.
3)Suggested correction:
envelope :detail ["to", "cc", "bcc"] "foo"
is nonsense; envelopes don't have "cc" or "bcc"; eliminate them.
4)(Question for anyone on the list:)
- Apropos use of the null key ("") in this extension:
Should
header :contains "Subject" ""
return true for all mail with a Subject header?
Perhaps its an implementation error , but this type| of test doesn't work on FastMail (which uses Cyrus IMAP); exists must be used.
My reading of the spec is that this should ("MUST") work.
Let me know what you think. I didn't email iesg(_at_)ietf(_dot_)org or
ietf(_at_)ietf(_dot_)org; didn't seem to make sense at this juncture.
-Matthew Elvey