Ken Murchison | 1 Apr 21:35 2003

Proposed MANAGESIEVE changes


Here are the proposed changes to MANAGESIEVE that I mentioned at IETF. 
These have been sent to and accepted by Tim Martin already:

1. Based on the fact that the server no longer auto-issues the
capabilities response (per draft -04), paragraph 3 of section 2.2 should
be changed to something like (stolen from RFC 2595):

      Once TLS has been started, the client MUST discard cached
      information about server capabilities and SHOULD re-issue the
      CAPABILITY command.  This is necessary to protect against
      man-in-the-middle attacks which alter the capabilities list prior
      to STARTTLS.  The server MAY advertise different capabilities
      after STARTTLS.

2. Based on Cyrus Murder/virtdomains work, Rob Siemborski and I propose
the following augmented Sieve URL grammar:

sieveurl = "sieve://" [ [ authinfo " <at> " ] hostport ] "/" scriptname

authinfo = authid [ ";" userid ]

authid = userid = *( unreserved | escaped | 
                     ":" | "&" | "=" | "+" | "$" | "," )

scriptname = *pchar

--

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
(Continue reading)

Matthew Elvey (FM | 3 Apr 20:30 2003

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


>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.org or ietf <at> ietf.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 
(Continue reading)

Ken Murchison | 3 Apr 20:54 2003

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


I was just asked what would happen if this extension is used on an
address such as:

user+detail1+detail2 <at> canonicaldomain.dom

I'm proposing adding the following text to the draft:

"NOTE: If the separator character occurs more than once in the
local-part,
then the address SHOULD be split at the left-most separator."

Does this seem sufficient?  Should this be a MUST instead of a SHOULD? 
Any other thoughts?

--

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Alexey Melnikov | 3 Apr 21:17 2003

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


Ken Murchison wrote:

> I was just asked what would happen if this extension is used on an
> address such as:
>
> user+detail1+detail2 <at> canonicaldomain.dom
>
> I'm proposing adding the following text to the draft:
>
> "NOTE: If the separator character occurs more than once in the
> local-part,
> then the address SHOULD be split at the left-most separator."
>
> Does this seem sufficient?  Should this be a MUST instead of a SHOULD?
> Any other thoughts?

IMHO, this should be MUST and it is sufficient.

Cheers,
Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________
(Continue reading)

michael | 3 Apr 23:58 2003
Picon

Matching NUL characters


Hello,

as defined by RFC 3028, Sieve scripts may not contain NUL characters.
MIME encoded headers may contain them (encoded), though, and there is
currently no way to match them with Sieve.  For that reason I suggest
to change paragraph 2.4.2 of the RFC to define \0 being a representation
of the NUL character.

I know, that's quite a change, but it's quite a bug, too. ;-) Btw, both
Mutt and Outlook Express don't show anything after a MIME encoded NUL
characters, so they simply decode it and, given C strings, terminate the
string that way, because nobody ever thought about how to handle them.
If a sieve implementation is not subject to this bug, then most likely
it could support \0 pretty easy.  Otherwise some work is required anyway
to fix the bug.

While extending the meaning of \, I suggest to use the Java \u notation
to specify unicode characters.  Sieve scripts are written in UTF-8 for
good reasons, but being able to use non-ASCII characters without having
to use UTF-8 would be great.  That's just an idea, though, and not really
required like \0 is.

I am currently writing my own sieve implementation as extension to Exim.
Hacking MIME decoding, I discovered the problem above and Tim Showalter
suggested I join the list.  It's not the first issue I had with the RFC
so far, but the first that asks for a change in the language.

Michael

(Continue reading)

Matthew Elvey (FM | 4 Apr 03:01 2003

Re: Last Call: Sieve -- Subaddress Extension - NUL


Alexey Melnikov wrote:

>Ken Murchison wrote:
>  
>
>>I was just asked what would happen if this extension is used on an
>>address such as:
>>
>>user+detail1+detail2 <at> canonicaldomain.dom
>>
>>I'm proposing adding the following text to the draft:
>>
>>"NOTE: If the separator character occurs more than once in the
>>local-part,
>>then the address SHOULD be split at the left-most separator."
>>
>>Does this seem sufficient?  Should this be a MUST instead of a SHOULD?
>>Any other thoughts?
>>    
>>
>
>IMHO, this should be MUST and it is sufficient.
>
I concur, and since brought this all up, that means there's no 
disagreement.  :)

However, regarding Michael's NUL comment:
Michael, I believe that we are not talking about the same thing, and 
there's nothing to worry about, and no change to the RFC needed.  The 
(Continue reading)

Kjetil Torgrim Homme | 4 Apr 10:11 2003
Picon
Picon

Re: Matching NUL characters


[michael <at> freenet-ag.de]:
>
>   as defined by RFC 3028, Sieve scripts may not contain NUL
>   characters.  MIME encoded headers may contain them (encoded),
>   though, and there is currently no way to match them with Sieve.
>   For that reason I suggest to change paragraph 2.4.2 of the RFC to
>   define \0 being a representation of the NUL character.
>   
>   I know, that's quite a change, but it's quite a bug, too. ;-) Btw,
>   both Mutt and Outlook Express don't show anything after a MIME
>   encoded NUL characters, so they simply decode it and, given C
>   strings, terminate the string that way, because nobody ever
>   thought about how to handle them.

since the wording is quite explicit in the Sieve standard, I'd rather
say that this was intentional.  it complicates implementation to
support the NUL character, for little benefit.

>   If a sieve implementation is not subject to this bug, then most
>   likely it could support \0 pretty easy.  Otherwise some work is
>   required anyway to fix the bug.

I suggest you propose an extension.  an implementation that follows
the current RFC should not be rendered incompatible.

>   While extending the meaning of \, I suggest to use the Java \u
>   notation to specify unicode characters.  Sieve scripts are written
>   in UTF-8 for good reasons, but being able to use non-ASCII
>   characters without having to use UTF-8 would be great.  That's
(Continue reading)

michael | 4 Apr 10:39 2003
Picon

Re: Last Call: Sieve -- Subaddress Extension - NUL


> Michael, I believe that we are not talking about the same thing, and 
> there's nothing to worry about, and no change to the RFC needed.

I think you misunderstood me.  I just jumped into the list and I am
talking about how to match this:

  Subject: =?iso-8859-1?q?=00text?=

Sieve can't do that right now other than by using a pattern match.

Michael

michael | 4 Apr 10:57 2003
Picon

Re: Matching NUL characters


> >   If a sieve implementation is not subject to this bug, then most
> >   likely it could support \0 pretty easy.  Otherwise some work is
> >   required anyway to fix the bug.
>
> I suggest you propose an extension.  an implementation that follows
> the current RFC should not be rendered incompatible.

I thought about an extension, too, but what should be the result
of the following two matches (as specified by the RFC) given
those comparisons, if we have the header

  Subject: =?iso-8859-1?q?abc=00def?=

and the tests:

  header :contains ["Subject"] ["abc"]
  header :contains ["Subject"] ["def"]
  header :matches ["Subject"] ["abc?def"]

An implementation that evaluates the second or third test as false is
broken, isn't it? To fix that, adding NUL support is required.  It
would not shed a good light onto sieve if the above tests only evaluate
as true if the scripts begins with

  require "no_NUL_bug";

And even that would require conforming implementations to artificially
introduce the bug when that extension is not selected.

(Continue reading)

Kjetil Torgrim Homme | 4 Apr 11:58 2003
Picon
Picon

Re: Matching NUL characters


[michael <at> freenet-ag.de]:
>
>   > I suggest you propose an extension.  an implementation that follows
>   > the current RFC should not be rendered incompatible.
>   
>   I thought about an extension, too, but what should be the result
>   of the following two matches (as specified by the RFC) given
>   those comparisons, if we have the header
>   
>     Subject: =?iso-8859-1?q?abc=00def?=
>   
>   and the tests:
>   
>     header :contains ["Subject"] ["abc"]
>     header :contains ["Subject"] ["def"]
>     header :matches ["Subject"] ["abc?def"]
>   
>   An implementation that evaluates the second or third test as false
>   is broken, isn't it?

granted.  good example.

>   > if you want the "\0" escape, you can't express U+ef followed by zero.
>   >
>   >   \uef\0 => U+ef NUL
>   >
>   > "\u0" is so short "\0" is superfluous.  the number of escapes
>   > should be kept to a minimum.
>   
(Continue reading)


Gmane