Re: [Dovecot] Capability problems dovecot 2.0
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 i...@.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 i...@.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 i...@.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 i...@.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 i...@.com mypassword 0.079922 10.4.1.100 - 10.4.1.172 IMAP Request: 3ihn LOGIN i...@.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
Re: [Dovecot] Capability problems dovecot 2.0
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 i...@.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 i...@.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: 1) The post-login CAPABILITY reply is wrong. Did you set imap_capability setting manually? Remove it. 2) 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 signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Capability problems dovecot 2.0
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: 1) The post-login CAPABILITY reply is wrong. Did you set imap_capability setting manually? Remove it. 2) 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, 1) hihi, sorry, I had one line left. I removed it, but still no luck. 2) 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.00 10.4.1.100 - 10.4.1.171 TCP 4666 143 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 0.24 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 i...@.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.00 10.4.1.100 - 10.4.1.171 TCP 6106 143 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 0.23 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 i...@.com mypassword 0.083921 10.4.1.100 - 10.4.1.171 IMAP Request: ed0l LOGIN i...@.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
Re: [Dovecot] Capability problems dovecot 2.0
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?
diff -r 36311318a958 src/imap/main.c
--- a/src/imap/main.c Mon Jun 01 14:37:18 2009 -0400
+++ b/src/imap/main.c Mon Jun 01 14:40:37 2009 -0400
@@ -109,9 +109,9 @@
/* client doesn't seem to understand tagged capabilities. send
untagged instead and hope that it works. */
o_stream_cork(client-output);
+ client_send_line(client, t_strconcat(tag, Logged in, NULL));
client_send_line(client, t_strconcat(* CAPABILITY ,
str_c(client-capability_string), NULL));
- client_send_line(client, t_strconcat(tag, Logged in, NULL));
o_stream_uncork(client-output);
} else {
client_send_line(client, t_strconcat(
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] Capability problems dovecot 2.0
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 i...@.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 i...@.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
Re: [Dovecot] Capability problems dovecot 2.0
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. :) Fixed: http://hg.dovecot.org/dovecot-2.0/rev/02679d365af7 signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Capability problems dovecot 2.0
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. :) Fixed: http://hg.dovecot.org/dovecot-2.0/rev/02679d365af7 Cool! That did the trick. I'll investigate about the capability stuff now... Regards, Sebastian
Re: [Dovecot] Capability problems dovecot 2.0
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. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Capability problems dovecot 2.0
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
Re: [Dovecot] Capability problems dovecot 2.0
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.
Re: [Dovecot] Capability problems dovecot 2.0
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 / ri...@richw.org / ri...@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.new.facebook.com/profile.php?id=206680
Re: [Dovecot] Capability problems dovecot 2.0
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.
Re: [Dovecot] Capability problems dovecot 2.0
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
Re: [Dovecot] Capability problems dovecot 2.0
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.)
Re: [Dovecot] Capability problems dovecot 2.0
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.
Re: [Dovecot] Capability problems dovecot 2.0
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..
Re: [Dovecot] Capability problems dovecot 2.0
I never said anything about breaking Thunderbird. Sorry if I misinterpreted your response to reg9...@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 / ri...@richw.org / ri...@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.new.facebook.com/profile.php?id=206680
Re: [Dovecot] Capability problems dovecot 2.0
On Tue, 2009-05-26 at 11:20 +, 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.. signature.asc Description: This is a digitally signed message part
