On Wed, 2010-08-04 at 14:04 +0100, pod wrote:
> The case seems clear for STARTTLS; you advertise only non-plaintext AUTH
> mechanisms and LOGINDISABLED initially and after successful STARTTLS you
> can advertise plaintext AUTH mechanisms and remove LOGINDISABLED.
Yes.
> I must
> confess I am h
"A.L.E.C" writes:
> On 04.08.2010 12:25, Craig Whitmore wrote:
>
>> Looking at the RFC.. and if dovecot is doing this then its going against
>> the RFC and doing it wrong. As it says "This listing of capabilities is
>> not dependent upon connection state or user."
>>
>> http://tools.ietf.org/sear
Timo Sirainen wrote:
> On 4.8.2010, at 12.27, Charles Marcus wrote:
>> yes, per user capabilities are a future possibility):
> Not just a future possibility, but they already are possible. Just
> have userdb return different mail_plugins setting for different
> users.
I stand pleasantly corrected
On Wed, 2010-08-04 at 12:50 +0200, A.L.E.C wrote:
> On 04.08.2010 12:25, Craig Whitmore wrote:
>
> > Looking at the RFC.. and if dovecot is doing this then its going against
> > the RFC and doing it wrong. As it says "This listing of capabilities is
> > not dependent upon connection state or user.
On 4.8.2010, at 12.27, Charles Marcus wrote:
>> I have a question regarding the IMAP CAPABILITY command behavior of
>> Dovecot 2.0.rc3.
>>
>> While connecting to a Dovecot 1.2.4 server and requesting the supported
>> capabilities, Dovecot returns all capabilities:
>
> Timo's last response to thi
Christian Affolter wrote:
> Hi
>
> I have a question regarding the IMAP CAPABILITY command behavior of
> Dovecot 2.0.rc3.
>
> While connecting to a Dovecot 1.2.4 server and requesting the supported
> capabilities, Dovecot returns all capabilities:
Timo's last response to this - and there have be
On 04.08.2010 12:25, Craig Whitmore wrote:
Looking at the RFC.. and if dovecot is doing this then its going against
the RFC and doing it wrong. As it says "This listing of capabilities is
not dependent upon connection state or user."
http://tools.ietf.org/search/rfc1730#section-6.1.1
http://too
>
> Doing the same on 2.0.rc3, will return only a limited set of supported
> capabilities:
Looking at the RFC.. and if dovecot is doing this then its going against
the RFC and doing it wrong. As it says "This listing of capabilities is
not dependent upon connection state or user."
http://tools.
Hi
I have a question regarding the IMAP CAPABILITY command behavior of
Dovecot 2.0.rc3.
While connecting to a Dovecot 1.2.4 server and requesting the supported
capabilities, Dovecot returns all capabilities:
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE
STARTTLS AUTH=PLAI
