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
