On 30 Sep 2008, at 09:36, Ken Murchison wrote:
Given your follow-up email about too many config options, should we combine this with the existing rfc3028_strict option?
I don't think the point of that comment was to say that there are "too many" per se. Just that "technically better" does not trump "breaks clients". I desire to move in the direction of "technically better", while being allowed to manage the transition. You need the options.
Personally, I don't think it's a great idea to combine this option with rfc3028_strict. I suspect most people leave rfc3028_strict on. Forcing them to relax address checking to get the legacy utf-7/-8 behavior seems like the wrong approach. But maybe it doesn't matter. Kind of depends on what the clients do. I notice FM has a nice chart of sieve clients.
And speaking of what sieve clients do, it seems like some expect managesieve to respond with a capability list after AUTHENTICATION, while some don't. I gather the Internet-Draft for managesieve changed recently. The Cyrus code implementing this seems to change between 2.3.12p1 and 2.3.12p2. This breaks some significant clients, in addition to making it very challenging to upgrade a murder environment incrementally. timsieved proxying and sivtest now expect servers to return the capability after authentication. Since old servers don't, they just hang in a read.
I'm thinking of two new options: one which controls whether timsieved and sivtest expect draft-martin-managesieve-08 or draft-martin- managesieve-09 AUTHENTICATE behavior; and a second one which controls whether timsieved sends capability after AUTHENTICATE a la draft- martin-managesieve-09 or doesn't a la draft-martin-managesieve-08:
sieve_expect_draft-martin-managesieve-08_authenticate: sieve_do_draft-martin-managesieve-08_authenticate: Comments? :wes