[Dovecot] Capability problems dovecot 2.0
Hi,
I had some problems connecting TB 2.x with dovecot 2.0. TB2 complained about not being an IMAP4 server. TB 3 worked. It seems that dovecot 2.0 doesn't return capabilities when queried. Maybe some wrong config, thoug?
Here are the debug logs from TB2 comparing dovecot 2.0 (not working) and dovecot 1.2 (working):
Dovecot 2.0:
NA:CreateNewLineFromSocket: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5] Dovecot ready.
NA:SendData: 1 capability
ReadNextLine [stream=26c2d60 nb=15 needmore=0] NA:CreateNewLineFromSocket: * CAPABILITY
ReadNextLine [stream=26c2d60 nb=28 needmore=0] NA:CreateNewLineFromSocket: 1 OK Capability completed.
ProcessCurrentURL: aborting queued urls NA:SendData: 2 logout
Dovecot 1.2:
NA:CreateNewLineFromSocket: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5] Dovecot ready.
NA:SendData: 1 capability
ReadNextLine [stream=27dcf50 nb=303 needmore=0] NA:CreateNewLineFromSocket: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH QUOTA AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5
ReadNextLine [stream=27dcf50 nb=28 needmore=0] NA:CreateNewLineFromSocket: 1 OK Capability completed.
NA:SendData: 2 authenticate plain
ReadNextLine [stream=27dcf50 nb=4 needmore=0] NA:CreateNewLineFromSocket: +
NA:SendData: Logging suppressed for this command (it probably contained authentication information) ReadNextLine [stream=27dcf50 nb=266 needmore=0] NA:CreateNewLineFromSocket: 2 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH QUOTA] Logged in
A:SendData: 3 namespace
And all goes well...
TB3 seems to be fine without extra capability stuff.
Regards, Sebastian
On Tue, 2009-05-26 at 11:20 +0000, ja nein wrote:
Hi,
I had some problems connecting TB 2.x with dovecot 2.0. TB2 complained about not being an IMAP4 server. TB 3 worked. It seems that dovecot 2.0 doesn't return capabilities when queried. Maybe some wrong config, thoug?
I think you can set imap_capability setting manually, but yeah, it's broken currently. I'm not exactly sure how it should be implemented now. Should doveconf do it? Should Dovecot master process do it? Should there be a completely new binary for it? Hmm..
TB3 seems to be fine without extra capability stuff.
Does it still ask for the CAPABILITY command? One solution could actually be that Dovecot just stops giving the full CAPABILITY before logging in. I did some tests for this recently, and it looked like as long as the capability is forcibly pushed to the client after login, most clients will use it. v1.2+ already does this when proxying to an IMAP server with different capabilities than what were advertised for the client previously. I haven't tried it with Outlook though, that could be the one client that ignores it..
Am 27.05.2009 04:44, schrieb Timo Sirainen:
TB3 seems to be fine without extra capability stuff.
Does it still ask for the CAPABILITY command? One solution could actually be that Dovecot just stops giving the full CAPABILITY before logging in. I did some tests for this recently, and it looked like as long as the capability is forcibly pushed to the client after login, most clients will use it. v1.2+ already does this when proxying to an IMAP server with different capabilities than what were advertised for the client previously. I haven't tried it with Outlook though, that could be the one client that ignores it..
Well,
as from the TB debug logs, both versions use the capability command before the login sequence. I couldn't think of any reason why not to give the capabilities when being asked for, but I don't know the RFC's or whatever else is dealing with that kind of problem.
In my opinion, dovecot should give capabilities, regardless if before or after login sequence. What would be the problem of it or why would it be intented to be removed. It would actually just break with a rather common client and change behaviour to all previous versions.
Regards, Sebastian
On May 27, 2009, at 2:22 AM, reg9009 wrote:
In my opinion, dovecot should give capabilities, regardless if
before or after login sequence. What would be the problem of it or
why would it be intented to be removed. It would actually just break
with a rather common client and change behaviour to all previous
versions.
The problem is that the capabilities depend on what plugins are
loaded. It's also possible to have different plugins loaded for
different users, so the capability reply might depend on the user
logging in. So in such setups there's no way to give the correct
capability before the username is known. Even without that problem the
way to get the list of capabilities from plugins is pretty horrible
code and if there's a way to get rid of it I'd like that.
While I recognize that Timo has some valid points here with regard to determining capabilities before vs. after login, I definitely would consider breaking compatibility with Thunderbird to be a MAJOR, MAJOR showstopper, regardless of the reasons for doing it.
-- Rich Wales / richw@richw.org / richw@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.new.facebook.com/profile.php?id=206680
On May 27, 2009, at 2:40 AM, Rich Wales wrote:
While I recognize that Timo has some valid points here with regard to determining capabilities before vs. after login, I definitely would consider breaking compatibility with Thunderbird to be a MAJOR, MAJOR showstopper, regardless of the reasons for doing it.
I never said anything about breaking Thunderbird.
I never said anything about breaking Thunderbird.
Sorry if I misinterpreted your response to reg9009@yahoo.de (when he said that your proposed change "would actually just break with a rather common client and change behaviour to all previous versions").
-- Rich Wales / richw@richw.org / richw@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.new.facebook.com/profile.php?id=206680
Timo Sirainen schrieb:
On May 27, 2009, at 2:22 AM, reg9009 wrote:
In my opinion, dovecot should give capabilities, regardless if before or after login sequence. What would be the problem of it or why would it be intented to be removed. It would actually just break with a rather common client and change behaviour to all previous versions.
The problem is that the capabilities depend on what plugins are loaded. It's also possible to have different plugins loaded for different users, so the capability reply might depend on the user logging in. So in such setups there's no way to give the correct capability before the username is known. Even without that problem the way to get the list of capabilities from plugins is pretty horrible code and if there's a way to get rid of it I'd like that.
Hmm, that's indeed a problem. Well, for the plugins depending on different users I don't have an answer. But I think TB is using the capability command again after login. I'll check.
For gathering the capabilities of plugins, etc. Would it be a viable solution to demand the plugins to pass capabilities at the point where the plugin registers/loads itself? That way it may not be that ugly?
I have to apologize, I'm not that deep coder, so some ideas might be simple spoken... :)
Regards, Sebastian
On May 27, 2009, at 2:48 AM, reg9009 wrote:
Hmm, that's indeed a problem. Well, for the plugins depending on different users I don't have an answer. But I think TB is using the capability command again after login. I'll check.
It's not, but if it's force-fed the new capability it'll use it.
For gathering the capabilities of plugins, etc. Would it be a viable solution to demand the plugins to pass capabilities at the point where the plugin registers/loads itself? That way it may not be that ugly?
The problem is that Dovecot's IMAP code is split to pre-login and post-
login processes. The pre-login processes don't load any plugins, only
the post-login processes do. But the capability is needed in the pre-
login process. So the way it works with v1.x is that when you start
dovecot it'll execute the imap post-login binary with a "dump-
capability" flag enabled, which basically loads the plugins and tells
the current capability string to Dovecot master process. This has
caused all kinds of problems in past and I'm sure as there will be
more trouble with that in future.
The alternative that I'm thinking right now is that in the pre-login
process Dovecot would only advertise those capabilities that are
actually useful before login. Then after login it would send an
updated capability reply to the client. The important question here
is: Are there any clients that don't update their capabilities? So far
I've tested Apple Mail, Thunderbird and Alpine and they're fine with
it. The most important question here is do Outlook and OE update that
list? (Or does OE use any extensions anyway? Outlook uses IDLE anyway.)
Timo Sirainen schrieb:
For gathering the capabilities of plugins, etc. Would it be a viable solution to demand the plugins to pass capabilities at the point where the plugin registers/loads itself? That way it may not be that ugly?
The problem is that Dovecot's IMAP code is split to pre-login and post-login processes. The pre-login processes don't load any plugins, only the post-login processes do. But the capability is needed in the pre-login process. So the way it works with v1.x is that when you start dovecot it'll execute the imap post-login binary with a "dump-capability" flag enabled, which basically loads the plugins and tells the current capability string to Dovecot master process. This has caused all kinds of problems in past and I'm sure as there will be more trouble with that in future.
The alternative that I'm thinking right now is that in the pre-login process Dovecot would only advertise those capabilities that are actually useful before login. Then after login it would send an updated capability reply to the client. The important question here is: Are there any clients that don't update their capabilities? So far I've tested Apple Mail, Thunderbird and Alpine and they're fine with it. The most important question here is do Outlook and OE update that list? (Or does OE use any extensions anyway? Outlook uses IDLE anyway.)
Ok. Your suggestion makes sense. If you would do it that way, I'm happy to test with different (Outlook, OE, etc.) clients to crosscheck if they've got a problem with that and, if not, honor new capabilities.
Regards, Sebastian
On Wed, 2009-05-27 at 09:03 +0200, reg9009 wrote:
The alternative that I'm thinking right now is that in the pre-login process Dovecot would only advertise those capabilities that are actually useful before login. Then after login it would send an updated capability reply to the client. The important question here is: Are there any clients that don't update their capabilities? So far I've tested Apple Mail, Thunderbird and Alpine and they're fine with it. The most important question here is do Outlook and OE update that list? (Or does OE use any extensions anyway? Outlook uses IDLE anyway.)
Ok. Your suggestion makes sense. If you would do it that way, I'm happy to test with different (Outlook, OE, etc.) clients to crosscheck if they've got a problem with that and, if not, honor new capabilities.
Implemented it now to v2.0: http://hg.dovecot.org/dovecot-2.0/rev/5f64f935e64b
You could test this by first verifying with older Dovecot or another IMAP server that Outlook/OE/etc. actually uses some IMAP extension, such as IDLE. Use e.g. Dovecot's rawlog or some traffic sniffer. After this try Dovecot v2.0 and see if it's still using the extension.
Timo Sirainen schrieb:
Implemented it now to v2.0: http://hg.dovecot.org/dovecot-2.0/rev/5f64f935e64b
You could test this by first verifying with older Dovecot or another IMAP server that Outlook/OE/etc. actually uses some IMAP extension, such as IDLE. Use e.g. Dovecot's rawlog or some traffic sniffer. After this try Dovecot v2.0 and see if it's still using the extension.
Cool, I'll try and give feedback. I'll test with dovecot 1.2 to crosscheck behaviour and get back, probably tomorrow.
Regards, Sebastian
Timo Sirainen schrieb:
Implemented it now to v2.0: http://hg.dovecot.org/dovecot-2.0/rev/5f64f935e64b
You could test this by first verifying with older Dovecot or another IMAP server that Outlook/OE/etc. actually uses some IMAP extension, such as IDLE. Use e.g. Dovecot's rawlog or some traffic sniffer. After this try Dovecot v2.0 and see if it's still using the extension.
Ok, here are my first results. Unfortunately, Outlook/OE actually doesn't work with dovecot 2.0. Here are the traffic logs in comparison to doveot 1.2. Tell me, if you need more detailed traffic. Plain and login mechanisms are enabled on both versions. Note that dovecot 2.0 complains about login command...
With TB 2.x/3, everything works fine.
Dovecot 2.0:
0.010447 10.4.1.171 -> 10.4.1.100 IMAP Response: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5] Dovecot ready. 0.066383 10.4.1.100 -> 10.4.1.171 IMAP Request: ipxc CAPABILITY 0.066459 10.4.1.171 -> 10.4.1.100 IMAP Response: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5 0.074466 10.4.1.100 -> 10.4.1.171 IMAP Request: ydqb LOGIN "info@xxxx.com" "mypassword" 0.085791 10.4.1.171 -> 10.4.1.100 IMAP Response: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5 70.430669 10.4.1.100 -> 10.4.1.171 IMAP Request: 6atb LOGIN "info@xxxx.com" "mypassword" 70.430837 10.4.1.171 -> 10.4.1.100 IMAP Response: 6atb BAD Error in IMAP command LOGIN: Unknown command. 71.572186 10.4.1.171 -> 10.4.1.100 IMAP Response: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5] Dovecot ready. 71.583362 10.4.1.100 -> 10.4.1.171 IMAP Request: rf7f CAPABILITY 71.583447 10.4.1.171 -> 10.4.1.100 IMAP Response: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5 71.591756 10.4.1.100 -> 10.4.1.171 IMAP Request: 3zq7 LOGIN "info@xxxx.com" "mypassword" 71.595471 10.4.1.171 -> 10.4.1.100 IMAP Response: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5 72.547817 10.4.1.171 -> 10.4.1.100 IMAP Response: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5] Dovecot ready. 72.557798 10.4.1.100 -> 10.4.1.171 IMAP Request: wavo CAPABILITY 72.557859 10.4.1.171 -> 10.4.1.100 IMAP Response: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5 72.564687 10.4.1.100 -> 10.4.1.171 IMAP Request: zvi8 LOGIN "info@xxxx.com" "mypassword" 72.568293 10.4.1.171 -> 10.4.1.100 IMAP Response: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5 72.773022 10.4.1.171 -> 10.4.1.100 IMAP [TCP Retransmission] Response: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5
Dovecot 1.2:
0.011031 10.4.1.172 -> 10.4.1.100 IMAP Response: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5] Dovecot ready. 0.016913 10.4.1.172 -> 10.4.1.100 IMAP Response: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5] Dovecot ready. 0.065276 10.4.1.100 -> 10.4.1.172 IMAP Request: u4j5 CAPABILITY 0.065406 10.4.1.172 -> 10.4.1.100 IMAP Response: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH QUOTA AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5 0.069692 10.4.1.100 -> 10.4.1.172 IMAP Request: rukl CAPABILITY 0.069810 10.4.1.172 -> 10.4.1.100 IMAP Response: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH QUOTA AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5 0.075379 10.4.1.100 -> 10.4.1.172 IMAP Request: gdwb LOGIN "info@xxxx.com" "mypassword" 0.079922 10.4.1.100 -> 10.4.1.172 IMAP Request: 3ihn LOGIN "info@xxxx.com" "mypassword" 0.370437 10.4.1.172 -> 10.4.1.100 IMAP Response: 3ihn OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH QUOTA] Logged in 0.370540 10.4.1.172 -> 10.4.1.100 IMAP Response: gdwb OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH QUOTA] Logged in 0.377995 10.4.1.100 -> 10.4.1.172 IMAP Request: afrf IDLE 0.378134 10.4.1.172 -> 10.4.1.100 IMAP Response: + idling 0.382945 10.4.1.100 -> 10.4.1.172 IMAP Request: frdt IDLE
On Mon, 2009-06-01 at 12:40 +0200, reg9009 wrote:
0.074466 10.4.1.100 -> 10.4.1.171 IMAP Request: ydqb LOGIN "info@xxxx.com" "mypassword" 0.085791 10.4.1.171 -> 10.4.1.100 IMAP Response: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5 70.430669 10.4.1.100 -> 10.4.1.171 IMAP Request: 6atb LOGIN "info@xxxx.com" "mypassword"
So it saw the CAPABILITY response, but apparently not the tagged OK response, and then it timed out and tried again later? But two things:
The post-login CAPABILITY reply is wrong. Did you set imap_capability setting manually? Remove it.
Did Dovecot really not send OK reply or did Outlook just ignore it? Hmm. Does this help? http://hg.dovecot.org/dovecot-2.0/rev/8ecbc7fefeb2
So it saw the CAPABILITY response, but apparently not the tagged OK response, and then it timed out and tried again later? But two things:
The post-login CAPABILITY reply is wrong. Did you set imap_capability setting manually? Remove it.
Did Dovecot really not send OK reply or did Outlook just ignore it? Hmm. Does this help? http://hg.dovecot.org/dovecot-2.0/rev/8ecbc7fefeb2
Hi,
hihi, sorry, I had one line left. I removed it, but still no luck.
I tried your patch, unfortunately no lock, too.
The effect on Outlook/OE is that it keeps asking for the password...
Again, TB ok.
Here's the Output from Outlook Express and Outlook (10.4.1.100 being the client).
Outlook Express:
0.000000 10.4.1.100 -> 10.4.1.171 TCP 4666 > 143 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 0.000024 10.4.1.171 -> 10.4.1.100 TCP 143 > 4666 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 0.009113 10.4.1.100 -> 10.4.1.171 TCP 4666 > 143 [ACK] Seq=1 Ack=1 Win=65535 Len=0 0.009390 10.4.1.171 -> 10.4.1.100 IMAP Response: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5] Dovecot ready. 0.017003 10.4.1.100 -> 10.4.1.171 IMAP Request: ekbc CAPABILITY 0.017016 10.4.1.171 -> 10.4.1.100 TCP 143 > 4666 [ACK] Seq=140 Ack=18 Win=5840 Len=0 0.017064 10.4.1.171 -> 10.4.1.100 IMAP Response: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5 0.031096 10.4.1.100 -> 10.4.1.171 IMAP Request: f1pb LOGIN "info@xxxx.com" "mypassword" 0.034449 10.4.1.171 -> 10.4.1.100 IMAP Response: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH 0.190491 10.4.1.100 -> 10.4.1.171 TCP 4666 > 143 [ACK] Seq=57 Ack=551 Win=64985 Len=0
Outlook:
0.000000 10.4.1.100 -> 10.4.1.171 TCP 6106 > 143 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 0.000023 10.4.1.171 -> 10.4.1.100 TCP 143 > 6106 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 0.004025 10.4.1.100 -> 10.4.1.171 TCP 5521 > 143 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 0.004033 10.4.1.171 -> 10.4.1.100 TCP 143 > 5521 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 0.012960 10.4.1.100 -> 10.4.1.171 TCP 6106 > 143 [ACK] Seq=1 Ack=1 Win=65535 Len=0 0.013235 10.4.1.171 -> 10.4.1.100 IMAP Response: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5] Dovecot ready. 0.016882 10.4.1.100 -> 10.4.1.171 TCP 5521 > 143 [ACK] Seq=1 Ack=1 Win=65535 Len=0 0.017119 10.4.1.171 -> 10.4.1.100 IMAP Response: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5] Dovecot ready. 0.073274 10.4.1.100 -> 10.4.1.171 IMAP Request: 4zn6 CAPABILITY 0.073299 10.4.1.171 -> 10.4.1.100 TCP 143 > 6106 [ACK] Seq=140 Ack=18 Win=5840 Len=0 0.073371 10.4.1.171 -> 10.4.1.100 IMAP Response: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5 0.076474 10.4.1.100 -> 10.4.1.171 IMAP Request: knp1 CAPABILITY 0.076485 10.4.1.171 -> 10.4.1.100 TCP 143 > 5521 [ACK] Seq=140 Ack=18 Win=5840 Len=0 0.076546 10.4.1.171 -> 10.4.1.100 IMAP Response: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5 0.079959 10.4.1.100 -> 10.4.1.171 IMAP Request: o5bw LOGIN "info@xxxx.com" "mypassword" 0.083921 10.4.1.100 -> 10.4.1.171 IMAP Request: ed0l LOGIN "info@xxxx.com" "mypassword" 0.086463 10.4.1.171 -> 10.4.1.100 IMAP Response: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH 0.089829 10.4.1.171 -> 10.4.1.100 IMAP Response: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH 0.280062 10.4.1.100 -> 10.4.1.171 TCP 5521 > 143 [ACK] Seq=57 Ack=551 Win=64985 Len=0 0.280156 10.4.1.100 -> 10.4.1.171 TCP 6106 > 143 [ACK] Seq=57 Ack=551 Win=64985 Len=0
Regards, Sebastian
Timo Sirainen schrieb:
On Mon, 2009-06-01 at 20:29 +0200, reg9009 wrote:
The effect on Outlook/OE is that it keeps asking for the password...
Hmh. What about with the attached patch? I guess it then at least logs in, but does it use IDLE?
unfortunately the patch doesn't work either. But I think I've got the cause:
Outlook Express working with dovecot 1.2:
0.010098 10.4.1.172 -> 10.4.1.100 IMAP Response: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5] Dovecot ready. 0.031029 10.4.1.100 -> 10.4.1.172 IMAP Request: 447p CAPABILITY 0.031086 10.4.1.172 -> 10.4.1.100 IMAP Response: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH QUOTA AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5 0.044316 10.4.1.100 -> 10.4.1.172 IMAP Request: 4q67 LOGIN "info@xxxx.com" "mypassword" 0.066054 10.4.1.172 -> 10.4.1.100 IMAP Response: 4q67 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH QUOTA] Logged in 0.080616 10.4.1.100 -> 10.4.1.172 IMAP Request: gb5g IDLE
same Outlook Express not working with dovecot 2.0:
59.755482 10.4.1.171 -> 10.4.1.100 IMAP Response: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5] Dovecot ready. 59.764561 10.4.1.100 -> 10.4.1.171 IMAP Request: 2rzz CAPABILITY 59.764624 10.4.1.171 -> 10.4.1.100 IMAP Response: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5 59.786662 10.4.1.100 -> 10.4.1.171 IMAP Request: lfjo LOGIN "info@xxxx.com" "mypassword" 59.790349 10.4.1.171 -> 10.4.1.100 IMAP Response: lfjo Logged in
Note the answer to the login request. I think dovecot 2.0 always missed the starting "OK ...". Maybe this is the problem?
Regards, Sebastian
On Mon, 2009-06-01 at 21:05 +0200, reg9009 wrote:
Note the answer to the login request. I think dovecot 2.0 always missed the starting "OK ...". Maybe this is the problem?
Oh, yes, that's it! When I wrote the code I noticed that the line looked a bit short. I thought it might have been because it was missing '.' at the end that all other commands had, but it must have been the lack of OK that kept nagging my subconsciousness. :)
Timo Sirainen schrieb:
Oh, yes, that's it! When I wrote the code I noticed that the line looked a bit short. I thought it might have been because it was missing '.' at the end that all other commands had, but it must have been the lack of OK that kept nagging my subconsciousness. :)
Cool! That did the trick. I'll investigate about the capability stuff now...
Regards, Sebastian
The alternative that I'm thinking right now is that in the pre-login process Dovecot would only advertise those capabilities that are actually useful before login. Then after login it would send an updated capability reply to the client. The important question here is: Are there any clients that don't update their capabilities?
RFC says: A server MAY send capabilities automatically, by using the CAPABILITY response code in the initial PREAUTH or OK responses, and by sending an updated CAPABILITY response code in the tagged OK response as part of a successful authentication. It is unnecessary for a client to send a separate CAPABILITY command if it recognizes these automatic capabilities.
So that's valid approach and any client should support it.
On May 27, 2009, at 3:15 AM, Max Ivanov wrote:
The alternative that I'm thinking right now is that in the pre- login process Dovecot would only advertise those capabilities that are actually
useful before login. Then after login it would send an updated capability
reply to the client. The important question here is: Are there any clients
that don't update their capabilities?RFC says: A server MAY send capabilities automatically, by using the CAPABILITY response code in the initial PREAUTH or OK responses, and by sending an updated CAPABILITY response code in the tagged OK response as part of a successful authentication. It is unnecessary for a client to send a separate CAPABILITY command if it recognizes these automatic capabilities.
So that's valid approach and any client should support it.
Most IMAP clients are violaing IMAP RFC in many other ways already
anyway. And that doesn't actually require clients to use the
capability, just says it's unnecessary to ask it..
participants (5)
-
ja nein
-
Max Ivanov
-
reg9009
-
Rich Wales
-
Timo Sirainen