Subject: Re: Last Call: Sieve -- Subaddress Extension to Proposed Standard

From: "Matthew Elvey (FM)" <[email-masked]>
Date: Thu, 03 Apr 2003 10:30:36 -0800

>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
>>>[email-masked] or [email-masked] 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:

[email-masked] ([email-masked] instead of [email-masked])
This canonical form is in the envelope to, which is (I agree) the best address to test against.

Example (trimmed) header

Subject: Welcome to the "wireless" mailing list
From: [email-masked]
To: [email-masked]

2)Does the spec leave undefined  how it would parse

[email-masked]?  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 [email-masked] or 
[email-masked]; didn't seem to make sense at this juncture.

-Matthew Elvey