[Dovecot] [POP3] RFC2449 conformance?
RFC2449 Section 5 ("Capabilities available in the AUTHORIZATION state MUST be announced in both states.") requires that POP3 extensions offered in Authentication state MUST be offered in Transaction state as well, this affects the "SASL" extension.
This is a CVS version that is a couple of days old (the old 0.99.10 wouldn't run on Linux 2.6 because it has tighter resource limiting):
+OK dovecot ready. capa +OK CAPA TOP USER UIDL RESP-CODES SASL PLAIN . user SECRET +OK pass VERYSECRET +OK Logged in. capa +OK CAPA TOP USER UIDL RESP-CODES . quit +OK Logging out.
-- Matthias Andree
On Sun, Nov 02, 2003 at 11:38:07PM +0100, Matthias Andree wrote:
RFC2449 Section 5 ("Capabilities available in the AUTHORIZATION state MUST be announced in both states.") requires that POP3 extensions offered in Authentication state MUST be offered in Transaction state as well, this affects the "SASL" extension.
Hmm.. So it seems. Available auth capabilities would have to be saved and sent to pop3 process since they're generated by asking from login processes what they support. Added in TODO.
On Mon, 3 Nov 2003 07:56:29 +0200, Timo Sirainen tss@iki.fi wrote:
On Sun, Nov 02, 2003 at 11:38:07PM +0100, Matthias Andree wrote:
RFC2449 Section 5 ("Capabilities available in the AUTHORIZATION state MUST be announced in both states.") requires that POP3 extensions offered in Authentication state MUST be offered in Transaction state as well, this affects the "SASL" extension.
Hmm.. So it seems. Available auth capabilities would have to be saved and sent to pop3 process since they're generated by asking from login processes what they support. Added in TODO.
While we're at it, does Dovecot support PIPELINING? If so, advertising it in Transaction state might improve performance of some clients.
-- Matthias Andree
participants (2)
-
Matthias Andree
-
Timo Sirainen