Re: [Dovecot] Dovecot ok for port 110, but not for SSL (beginner asking)
Thank you for your reply. I read the page you link to. As I understand I should set the ssl-parameter in 10-ssl.conf to "yes" or "required". I should also have permissions like this: root@deb7:/etc/dovecot/conf.d# ls -l /etc/ssl/*/dovecot.pem -r--r--r-- 1 root root 1326 Nov 3 14:24 /etc/ssl/certs/dovecot.pem -r 1 root root 1704 Nov 3 14:24 /etc/ssl/private/dovecot.pem root@deb7:/etc/dovecot/conf.d# Other information on the page, as I understand, has to do with more "advanced" setups than mine. I still have the same problem. When I set ssl parameter to yes/required I can still not connect to port 995. This time I set ssl=verbose. This is what the log shows when I try to connect with ssl. Nov 8 08:42:25 deb7 dovecot: pop3-login: Warning: SSL: where=0x10, ret=1: before/accept initialization [12.12.12.7] Nov 8 08:42:25 deb7 dovecot: pop3-login: Warning: SSL: where=0x2001, ret=1: before/accept initialization [12.12.12.7] Nov 8 08:42:25 deb7 dovecot: pop3-login: Warning: SSL: where=0x2001, ret=1: SSLv3 read client hello A [12.12.12.7] Nov 8 08:42:25 deb7 dovecot: pop3-login: Warning: SSL: where=0x2001, ret=1: SSLv3 write server hello A [12.12.12.7] Nov 8 08:42:25 deb7 dovecot: pop3-login: Warning: SSL: where=0x2001, ret=1: SSLv3 write certificate A [12.12.12.7] Nov 8 08:42:25 deb7 dovecot: pop3-login: Warning: SSL: where=0x2001, ret=1: SSLv3 write server done A [12.12.12.7] Nov 8 08:42:25 deb7 dovecot: pop3-login: Warning: SSL: where=0x2001, ret=1: SSLv3 flush data [12.12.12.7] Nov 8 08:42:25 deb7 dovecot: pop3-login: Warning: SSL: where=0x2002, ret=-1: SSLv3 read client certificate A [12.12.12.7] Nov 8 08:42:25 deb7 dovecot: pop3-login: Warning: SSL: where=0x2002, ret=-1: SSLv3 read client certificate A [12.12.12.7] Nov 8 08:42:25 deb7 dovecot: pop3-login: Warning: SSL: where=0x2001, ret=1: SSLv3 read client key exchange A [12.12.12.7] Nov 8 08:42:25 deb7 dovecot: pop3-login: Warning: SSL: where=0x2001, ret=1: SSLv3 read finished A [12.12.12.7] Nov 8 08:42:25 deb7 dovecot: pop3-login: Warning: SSL: where=0x2001, ret=1: SSLv3 write change cipher spec A [12.12.12.7] Nov 8 08:42:25 deb7 dovecot: pop3-login: Warning: SSL: where=0x2001, ret=1: SSLv3 write finished A [12.12.12.7] Nov 8 08:42:25 deb7 dovecot: pop3-login: Warning: SSL: where=0x2001, ret=1: SSLv3 flush data [12.12.12.7] Nov 8 08:42:25 deb7 dovecot: pop3-login: Warning: SSL: where=0x20, ret=1: SSL negotiation finished successfully [12.12.12.7] Nov 8 08:42:25 deb7 dovecot: pop3-login: Warning: SSL: where=0x2002, ret=1: SSL negotiation finished successfully [12.12.12.7] Nov 8 08:42:25 deb7 dovecot: pop3-login: Warning: SSL alert: where=0x4008, ret=256: warning close notify [12.12.12.7] Nov 8 08:42:25 deb7 dovecot: pop3-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=12.12.12.7, lip=13.13.13.239, TLS: Disconnected, session= Nov 8 08:42:26 deb7 dovecot: pop3-login: Warning: SSL: where=0x10, ret=1: before/accept initialization [12.12.12.7] Nov 8 08:42:26 deb7 dovecot: pop3-login: Warning: SSL: where=0x2001, ret=1: before/accept initialization [12.12.12.7] Nov 8 08:42:26 deb7 dovecot: pop3-login: Warning: SSL: where=0x2001, ret=1: SSLv3 read client hello A [12.12.12.7] Nov 8 08:42:26 deb7 dovecot: pop3-login: Warning: SSL: where=0x2001, ret=1: SSLv3 write server hello A [12.12.12.7] Nov 8 08:42:26 deb7 dovecot: pop3-login: Warning: SSL: where=0x2001, ret=1: SSLv3 write certificate A [12.12.12.7] Nov 8 08:42:26 deb7 dovecot: pop3-login: Warning: SSL: where=0x2001, ret=1: SSLv3 write server done A [12.12.12.7] Nov 8 08:42:26 deb7 dovecot: pop3-login: Warning: SSL: where=0x2001, ret=1: SSLv3 flush data [12.12.12.7] Nov 8 08:42:26 deb7 dovecot: pop3-login: Warning: SSL: where=0x2002, ret=-1: SSLv3 read client certificate A [12.12.12.7] Nov 8 08:42:26 deb7 dovecot: pop3-login: Warning: SSL: where=0x2002, ret=-1: SSLv3 read client certificate A [12.12.12.7] Nov 8 08:42:26 deb7 dovecot: pop3-login: Warning: SSL: where=0x2001, ret=1: SSLv3 read client key exchange A [12.12.12.7] Nov 8 08:42:26 deb7 dovecot: pop3-login: Warning: SSL: where=0x2001, ret=1: SSLv3 read finished A [12.12.12.7] Nov 8 08:42:26 deb7 dovecot: pop3-login: Warning: SSL: where=0x2001, ret=1: SSLv3 write change cipher spec A [12.12.12.7] Nov 8 08:42:26 deb7 dovecot: pop3-login: Warning: SSL: where=0x2001, ret=1: SSLv3 write finished A [12.12.12.7] Nov 8 08:42:26 deb7 dovecot: pop3-login: Warning: SSL: where=0x2001, ret=1: SSLv3 flush data [12.12.12.7] Nov 8 08:42:26 deb7 dovecot: pop3-login: Warning: SSL: where=0x20, ret=1: SSL negotiation finished successfully [12.12.12.7] Nov 8 08:42:26 deb7 dovecot: pop3-login: Warning: SSL: where=0x2002, ret=1: SSL negotiation finished successfully [12.12.12.7] Nov 8 08:42:26 deb7 dovecot: pop3-login: Warning: SSL alert: where=0x4008, ret=256: warning close notify [12.12.12.7] Nov 8 08:42:26 deb7 dovecot: pop3-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=12.12.12.7, lip=13.13.
[Dovecot] pop3 exim4 dovecot
Hi, I have an exim4 and dovecot system. The system has multiple accounts. Exim4 is receiving emails in the /var/mail/user files and dovecot is configured to use /home/user/mail (mbox) folder. I have one account that dovecot is not processing replies/bounces/etc... The data is being written in the /var/mail/user file by exim4 but as far as dovecot is aware there is nothing in the pop3 inbox. Can anyone suggest how I can enable dovecot to know that the data is in the /var/mail/user file and deliver it to the pop3 inbox for this account? -- Patrick Shirkey Boost Hardware Ltd
Re: [Dovecot] Android ICS stock client and IMAP Capability issue.
Am 08.11.2012 01:18, schrieb Massimiliano Cianelli: > Yes, different teams, but I think Google is still a lot more reasonable >>company to deal with things like this than Microsoft. Although >>surprisingly even Microsoft appears to support SPECIAL-USE in the next >>Outlook(?) client. yeah it works, but they had bugged it for my last tests, mail in sent folder ( which is corect in use by SPECIAL-USE ) always stay unread, seems they have had design problems using now a standard outgoing folder, however there is a bug report about that and they anounced to fix it, but it isnt in my last tests after the last upgrade, if they dont fix it you cant use the sent folder via imap in a handy way , and you have to disable the feature in total ( this point was changed also ), and need to set this function via filter wizard like long time ago outlook versions needed it Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
Re: [Dovecot] Android ICS stock client and IMAP Capability issue.
Am 08.11.2012 00:24, schrieb Massimiliano Cianelli: > Hi, > > Yes w/o prefix work as expected, try to add a prefix like courier does (eg. > Inbox.) It will not work as expected. I see you point, but as i have seen other mail clients have problems with prefix namespace in the past, i am using the most unproblematic setup, there will never be an universal best config for all imap software existing, dont try to find it > > Due I'm upgrading an old installed server, I've to keep everything as much > transparent I can... it includes IMAP folder and subscription. look at dovecot migration sites for examples, but it may stay a problem ever ,that some imap clients with broken stuff do not behave proper after migration again this should be fixed on the client side > > Looking at that I've encountered that issue, and analyzed for fix it (thank > you open source), not everyone will want to use/use k9.. but you can be 100% > sure the stock client is there. thats right, but if its failing with some servers, it has to be fixed at the "source of evil" first *g, anyway i dont see the point dovecot related, but your info is usefull anyway > > Due that Google act like BlackBerry, Microsoft,etc.. (hovewer they will not > fix it soon, or really respect the rfc), it's much simple add Namespace on > prelogin banner then wait or have to tell someone to install another client > for that mailbox. > > I didn't know the history, but looking at change log seems that idle as been > put back to prelogin client for some kind of compatibility with their service. > > Anyway, the most important reason that got me to subscribe the mailing list > for write those emails, is share with the community that problem and provide > a solution.. for someone in the future that have the same problem and will > search on internet for a solution (like I've does.. before analyze it on my > own). > > If the workaround will be added to the wiki or will be put in the source.. > the important thing is that there is a solution simple and fast (two.. the > source modify, and the configuration file) and someone can find it.. > > (Sarcastic) And if the mayans were right we can't wait for google to fix it :p Dovecot has mass of config parameter, try find out what set best to workaround your problem, then post it to the wiki, it will be welcomed > > Best Regards > Sent from Galaxy Nexus > > Robert Schetterer ha scritto: > >> Am 07.11.2012 08:13, schrieb Massimiliano Cianelli: >>> Hello, >>> >>> My phone: >>> Android ics 4.1.2 on galaxy nexus. >>> And yes, stock mean the default client that come with the os in IMAP mode. >>> >>> I already know about that configuration parameter, but it will display two >>> time namespace in postlogin capabilities, and so I like much more to adjust >>> the source code to fix the issue. >>> >>> Yes there is k9 but I didn't like it too much, I prefer the stock client >>> and is much important to keep compatibility with stock client then >>> user-installed client. >>> >>> About the issue on Google code, there is thr issue on google code... but >>> Google is a lot slow in fixing those things. >>> http://code.google.com/p/android/issues/detail?id=1811 >>> >>> In a few hour I'll update the issue noticing where is hidden the problem. >>> >>> Regards >>> Sent from Galaxy Nexus >> >> Hi , i shortly tested this with android sdk jelly bean 4.1.1 and "my >> setup" dovecot 2.1.10 with included orginal android mail app in imap mode, >> ,leaving IMAP prefix blank, everything works as expected, no double >> shown inbox, namespace problems etc >> so you might have to fit your namespace setup. >> Also you might follow allready given advice from here. >> >> Anyway , i understand you using "stock client" >> but you have to understand that the producers of mail clients >> optimize their stuff fitting best in their own server structure >> making money with it, therefor their motivation coding better imap code >> is not very high, same case is for outlook and microsoft >> however, i would say, fixing bugs is on the google site here, looks like >> there is patch >> at >> http://code.google.com/p/android/issues/detail?id=1811 >> and the issue seems long known >> >> i dont see any hard relation to dovecot in this case >> meanwhile using k9mail seems the best way to workaround >> there are lots of other bugs around android versions >> over the years i dont expect google to fix them >> >> >>> >>> Robert Schetterer ha scritto: >>> Am 06.11.2012 07:08, schrieb Ben Morrow: > At 6AM +0100 on 6/11/12 you (Massimiliano Cianelli) wrote: >> Hi, >> >> My setup: >> Dovecot 2 latest, installed to replace courrier IMAP, and off course >> configured with the dot separator and all folder under INBOX.*. >> >> The problem: >> My phone was driving me mad during the test, due that it will only >> recognize Inbox. >> >> How found the solution: >> I've started sniffing IMAP tra
Re: [Dovecot] Android ICS stock client and IMAP Capability issue.
* Timo Sirainen : > Yes, different teams, but I think Google is still a lot more reasonable > company to deal with things like this than Microsoft. Although surprisingly > even Microsoft appears to support SPECIAL-USE in the next Outlook(?) client. confirmed. p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
Re: [Dovecot] maildir and end-of-line encoding
On Wed, 2012-11-07 at 17:33 +0200, Timo Sirainen wrote: > Dovecot automatically adds CRs where necessary. Even within the same file > there can be mixed LF/CRLF lines. Can you detail this a bit, or point me to the specific code areas? 1) Is only CR added? Or also LF? 2) What happens e.g. when LFCR is found? Is that then "doubled" to CRLFCR or even CRLFCRLF? 3) When does it "add" these chars? Only when using dovecot-lda? Or also when some other MDA places files into e.g. a maildir? I did some reading on the RFC 5322 which says: - new mails must not have single CR or LF, both may only occur as CRL - but from the previous RFCs, it allows existing messages to have CR and LF alone, in which case they are not newlines as CRLF, but rather the CR and LF characters in the their meaning as control characters. 4) So from that point of view... automatic conversion may actually "corrupt" things in a strict sense. (One should hope of course, that only few people use(d) CR or LF alone to get their control character meaning... but rather that these are just cases of accidents.) 5) I agree with you that mails should be stored with CRLF, as this is their native format and I found nothing on the maildir[++] standards that would forbid that (neither that would encourage it). But for mbox there are "definitions" that _always_ LF is used (AFAIU, even on non-UNIX platforms. 6) I went through my mails and basically I found everything: CR, LF, CRLF and even LFCR. Now I have no real idea how to deal with that? Keep all as is? Make all LFs CRLFs and/or all CFs to CRLFs? What about the LFCRs? Handle them as group and perhaps swap them to CRLF. Or doing the same as with single LFs and CRs. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] Android ICS stock client and IMAP Capability issue.
If you give a look to Google code there are a lot of important bugs keep open from years. I like a lot android... but they have to spent a little more on it. Only in that way it will be the best mobile os around. Now it have some goods and some bads things.. like every os around us.. the only big good thing... it is open. Timo Sirainen ha scritto: >Yes, different teams, but I think Google is still a lot more reasonable >company to deal with things like this than Microsoft. Although >surprisingly even Microsoft appears to support SPECIAL-USE in the next >Outlook(?) client. > >On 8.11.2012, at 2.01, Massimiliano Cianelli wrote: > >> Yes, but namespace is in prelogin... and anyway they will say that >the team which will make the gmail app is different then the email app. >> >> IMHO there is only a commercial reason.. keep people use gmail and >force company and private to use Google apps... in that way they will >not have issue and have push delivery (also called IMAP idle that is >not supported). >> >> Timo Sirainen ha scritto: >> >>> Even gmail itself isn't advertising all capabilities before login: >>> >>> * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST >CHILDREN >>> X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH AUTH=XOAUTH2 >>> >>> vs. >>> >>> * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST >CHILDREN >>> X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE >>> >>> UIDPLUS especially has been very widely used long before gmail. I >guess >>> they also don't want to advertise unnecessary capabilities before >login >>> and have determined that all the important clients supporting >UIDPLUS >>> support receiving after it post-login. >>> >>> On 8.11.2012, at 1.48, Massimiliano Cianelli wrote: >>> I've noticed an error in my sentence about the change log, it was >>> referred to blackberry.. not to Google Google need only 'namespace', I will try to update the issue (due >>> that every IMAP server that will respect the rfc will not work as >>> expected in that condition).. pointing the problem on post login >>> capability... and we will see when Google will want to fix it. Regards Timo Sirainen ha scritto: > On 8.11.2012, at 1.24, Massimiliano Cianelli wrote: > >> Due that Google act like BlackBerry, Microsoft,etc.. (hovewer >they > will not fix it soon, or really respect the rfc), it's much simple >>> add > Namespace on prelogin banner then wait or have to tell someone to > install another client for that mailbox. >> >> I didn't know the history, but looking at change log seems that >>> idle > as been put back to prelogin client for some kind of compatibility >>> with > their service. > > Luckily the big ones only needed IDLE to work. I'm hoping to avoid > adding anything else. > > And Dovecot is currently the most widely used IMAP server, so I >>> think > there's a good chance of client developers actually fixing their > clients. -- testing k9 >> >> -- Inviato dal mio cellulare Android con K-9 Mail. Sent from Galaxy Nexus
Re: [Dovecot] Android ICS stock client and IMAP Capability issue.
Yes, different teams, but I think Google is still a lot more reasonable company to deal with things like this than Microsoft. Although surprisingly even Microsoft appears to support SPECIAL-USE in the next Outlook(?) client. On 8.11.2012, at 2.01, Massimiliano Cianelli wrote: > Yes, but namespace is in prelogin... and anyway they will say that the team > which will make the gmail app is different then the email app. > > IMHO there is only a commercial reason.. keep people use gmail and force > company and private to use Google apps... in that way they will not have > issue and have push delivery (also called IMAP idle that is not supported). > > Timo Sirainen ha scritto: > >> Even gmail itself isn't advertising all capabilities before login: >> >> * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN >> X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH AUTH=XOAUTH2 >> >> vs. >> >> * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN >> X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE >> >> UIDPLUS especially has been very widely used long before gmail. I guess >> they also don't want to advertise unnecessary capabilities before login >> and have determined that all the important clients supporting UIDPLUS >> support receiving after it post-login. >> >> On 8.11.2012, at 1.48, Massimiliano Cianelli wrote: >> >>> I've noticed an error in my sentence about the change log, it was >> referred to blackberry.. not to Google >>> >>> Google need only 'namespace', I will try to update the issue (due >> that every IMAP server that will respect the rfc will not work as >> expected in that condition).. pointing the problem on post login >> capability... and we will see when Google will want to fix it. >>> >>> Regards >>> >>> Timo Sirainen ha scritto: >>> On 8.11.2012, at 1.24, Massimiliano Cianelli wrote: > Due that Google act like BlackBerry, Microsoft,etc.. (hovewer they will not fix it soon, or really respect the rfc), it's much simple >> add Namespace on prelogin banner then wait or have to tell someone to install another client for that mailbox. > > I didn't know the history, but looking at change log seems that >> idle as been put back to prelogin client for some kind of compatibility >> with their service. Luckily the big ones only needed IDLE to work. I'm hoping to avoid adding anything else. And Dovecot is currently the most widely used IMAP server, so I >> think there's a good chance of client developers actually fixing their clients. >>> >>> -- testing k9 >>> > > -- Inviato dal mio cellulare Android con K-9 Mail.
Re: [Dovecot] Android ICS stock client and IMAP Capability issue.
Yes, but namespace is in prelogin... and anyway they will say that the team which will make the gmail app is different then the email app. IMHO there is only a commercial reason.. keep people use gmail and force company and private to use Google apps... in that way they will not have issue and have push delivery (also called IMAP idle that is not supported). Timo Sirainen ha scritto: >Even gmail itself isn't advertising all capabilities before login: > >* CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN >X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH AUTH=XOAUTH2 > >vs. > >* CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN >X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE > >UIDPLUS especially has been very widely used long before gmail. I guess >they also don't want to advertise unnecessary capabilities before login >and have determined that all the important clients supporting UIDPLUS >support receiving after it post-login. > >On 8.11.2012, at 1.48, Massimiliano Cianelli wrote: > >> I've noticed an error in my sentence about the change log, it was >referred to blackberry.. not to Google >> >> Google need only 'namespace', I will try to update the issue (due >that every IMAP server that will respect the rfc will not work as >expected in that condition).. pointing the problem on post login >capability... and we will see when Google will want to fix it. >> >> Regards >> >> Timo Sirainen ha scritto: >> >>> On 8.11.2012, at 1.24, Massimiliano Cianelli wrote: >>> Due that Google act like BlackBerry, Microsoft,etc.. (hovewer they >>> will not fix it soon, or really respect the rfc), it's much simple >add >>> Namespace on prelogin banner then wait or have to tell someone to >>> install another client for that mailbox. I didn't know the history, but looking at change log seems that >idle >>> as been put back to prelogin client for some kind of compatibility >with >>> their service. >>> >>> Luckily the big ones only needed IDLE to work. I'm hoping to avoid >>> adding anything else. >>> >>> And Dovecot is currently the most widely used IMAP server, so I >think >>> there's a good chance of client developers actually fixing their >>> clients. >> >> -- testing k9 >> -- Inviato dal mio cellulare Android con K-9 Mail.
Re: [Dovecot] Android ICS stock client and IMAP Capability issue.
Even gmail itself isn't advertising all capabilities before login: * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH AUTH=XOAUTH2 vs. * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE UIDPLUS especially has been very widely used long before gmail. I guess they also don't want to advertise unnecessary capabilities before login and have determined that all the important clients supporting UIDPLUS support receiving after it post-login. On 8.11.2012, at 1.48, Massimiliano Cianelli wrote: > I've noticed an error in my sentence about the change log, it was referred to > blackberry.. not to Google > > Google need only 'namespace', I will try to update the issue (due that every > IMAP server that will respect the rfc will not work as expected in that > condition).. pointing the problem on post login capability... and we will see > when Google will want to fix it. > > Regards > > Timo Sirainen ha scritto: > >> On 8.11.2012, at 1.24, Massimiliano Cianelli wrote: >> >>> Due that Google act like BlackBerry, Microsoft,etc.. (hovewer they >> will not fix it soon, or really respect the rfc), it's much simple add >> Namespace on prelogin banner then wait or have to tell someone to >> install another client for that mailbox. >>> >>> I didn't know the history, but looking at change log seems that idle >> as been put back to prelogin client for some kind of compatibility with >> their service. >> >> Luckily the big ones only needed IDLE to work. I'm hoping to avoid >> adding anything else. >> >> And Dovecot is currently the most widely used IMAP server, so I think >> there's a good chance of client developers actually fixing their >> clients. > > -- testing k9 >
Re: [Dovecot] Android ICS stock client and IMAP Capability issue.
I've noticed an error in my sentence about the change log, it was referred to blackberry.. not to Google Google need only 'namespace', I will try to update the issue (due that every IMAP server that will respect the rfc will not work as expected in that condition).. pointing the problem on post login capability... and we will see when Google will want to fix it. Regards Timo Sirainen ha scritto: >On 8.11.2012, at 1.24, Massimiliano Cianelli wrote: > >> Due that Google act like BlackBerry, Microsoft,etc.. (hovewer they >will not fix it soon, or really respect the rfc), it's much simple add >Namespace on prelogin banner then wait or have to tell someone to >install another client for that mailbox. >> >> I didn't know the history, but looking at change log seems that idle >as been put back to prelogin client for some kind of compatibility with >their service. > >Luckily the big ones only needed IDLE to work. I'm hoping to avoid >adding anything else. > >And Dovecot is currently the most widely used IMAP server, so I think >there's a good chance of client developers actually fixing their >clients. -- testing k9
Re: [Dovecot] Android ICS stock client and IMAP Capability issue.
On 8.11.2012, at 1.24, Massimiliano Cianelli wrote: > Due that Google act like BlackBerry, Microsoft,etc.. (hovewer they will not > fix it soon, or really respect the rfc), it's much simple add Namespace on > prelogin banner then wait or have to tell someone to install another client > for that mailbox. > > I didn't know the history, but looking at change log seems that idle as been > put back to prelogin client for some kind of compatibility with their service. Luckily the big ones only needed IDLE to work. I'm hoping to avoid adding anything else. And Dovecot is currently the most widely used IMAP server, so I think there's a good chance of client developers actually fixing their clients.
Re: [Dovecot] Android ICS stock client and IMAP Capability issue.
Hi, Yes w/o prefix work as expected, try to add a prefix like courier does (eg. Inbox.) It will not work as expected. Due I'm upgrading an old installed server, I've to keep everything as much transparent I can... it includes IMAP folder and subscription. Looking at that I've encountered that issue, and analyzed for fix it (thank you open source), not everyone will want to use/use k9.. but you can be 100% sure the stock client is there. Due that Google act like BlackBerry, Microsoft,etc.. (hovewer they will not fix it soon, or really respect the rfc), it's much simple add Namespace on prelogin banner then wait or have to tell someone to install another client for that mailbox. I didn't know the history, but looking at change log seems that idle as been put back to prelogin client for some kind of compatibility with their service. Anyway, the most important reason that got me to subscribe the mailing list for write those emails, is share with the community that problem and provide a solution.. for someone in the future that have the same problem and will search on internet for a solution (like I've does.. before analyze it on my own). If the workaround will be added to the wiki or will be put in the source.. the important thing is that there is a solution simple and fast (two.. the source modify, and the configuration file) and someone can find it.. (Sarcastic) And if the mayans were right we can't wait for google to fix it :p Best Regards Sent from Galaxy Nexus Robert Schetterer ha scritto: >Am 07.11.2012 08:13, schrieb Massimiliano Cianelli: >> Hello, >> >> My phone: >> Android ics 4.1.2 on galaxy nexus. >> And yes, stock mean the default client that come with the os in IMAP mode. >> >> I already know about that configuration parameter, but it will display two >> time namespace in postlogin capabilities, and so I like much more to adjust >> the source code to fix the issue. >> >> Yes there is k9 but I didn't like it too much, I prefer the stock client and >> is much important to keep compatibility with stock client then >> user-installed client. >> >> About the issue on Google code, there is thr issue on google code... but >> Google is a lot slow in fixing those things. >> http://code.google.com/p/android/issues/detail?id=1811 >> >> In a few hour I'll update the issue noticing where is hidden the problem. >> >> Regards >> Sent from Galaxy Nexus > >Hi , i shortly tested this with android sdk jelly bean 4.1.1 and "my >setup" dovecot 2.1.10 with included orginal android mail app in imap mode, >,leaving IMAP prefix blank, everything works as expected, no double >shown inbox, namespace problems etc >so you might have to fit your namespace setup. >Also you might follow allready given advice from here. > >Anyway , i understand you using "stock client" >but you have to understand that the producers of mail clients >optimize their stuff fitting best in their own server structure >making money with it, therefor their motivation coding better imap code >is not very high, same case is for outlook and microsoft >however, i would say, fixing bugs is on the google site here, looks like >there is patch >at >http://code.google.com/p/android/issues/detail?id=1811 >and the issue seems long known > >i dont see any hard relation to dovecot in this case >meanwhile using k9mail seems the best way to workaround >there are lots of other bugs around android versions >over the years i dont expect google to fix them > > >> >> Robert Schetterer ha scritto: >> >>> Am 06.11.2012 07:08, schrieb Ben Morrow: At 6AM +0100 on 6/11/12 you (Massimiliano Cianelli) wrote: > Hi, > > My setup: > Dovecot 2 latest, installed to replace courrier IMAP, and off course > configured with the dot separator and all folder under INBOX.*. > > The problem: > My phone was driving me mad during the test, due that it will only > recognize Inbox. > > How found the solution: > I've started sniffing IMAP traffic on my server and ended up with one > difference: > On courier it ask for namespace, on dovecot it won't. > > I gives a better look, and noticed that courier show namespace > capability on prelogin banner, adding it too solved the problem. > > Reason: > Android ICS stock client seems do not honor the capability gived after > the login. See http://wiki2.dovecot.org/Upgrading/2.0?highlight=%28capability%29 ; you need to set imap_capability and/or get your client fixed. Ben >>> >>> Hi, first ,what is the exact meaning of >>> >>> "Android ICS stock client" >>> >>> do you mean default included email client in standard android in imap >>> mode, when yes, which version of Android , i like to test my own >>> however is there changelog/code etc at google for this behave? >>> >>> conf example >>> >>> # Override the IMAP CAPABILITY response. If the value begins with '+', >>> # add the given capabilities
Re: [Dovecot] Issues with VANISHED CHANGEDSINCE
Quoting Timo Sirainen : On 8.11.2012, at 0.34, Michael M Slusarz wrote: Quoting Michael M Slusarz : I see your point, but the problem is that is not intuitive when reading the RFC. One part of the RFC defines the behavior of VANISHED (EARLIER) as only returning changes since the mod-sequence given. And you are correct that another part of the RFC says that, essentially, a server is allowed to break this required response. I'm thinking that this is more of an issue with the way the RFC is written. I'll move this over to the imap protocol list to get further input. Sigh. Never mind. For some reason, I completely ignored (missed?) this part of the RFC: Note: A server that receives a mod-sequence smaller than , where is the value of the smallest expunged mod-sequence it remembers minus one, MUST behave as if it was requested to report all expunged messages from the provided UID set parameter. So you are right, I was wrong, and the world is good. I wonder how much would it help if you a) Used the uidset/seqset parameters with SELECT command We *do* use this information. However, this is not (necessarily) useful for the activesync query that was the genesis of this thread. A bit of background on our MUA design is necessary. For Horde/IMP, all IMAP server configuration is done through the IMP application. As part of this configuration, a cache backend can be configured. There are multiple potential users of this IMAP object. Within IMP itself, multiple sessions can be open at any one time. Additionally, several views of IMP, our dynamic view and our smartmobile view, have another cache of messages kept on the browser side. Finally, the ActiveSync library also uses the IMAP object configured by IMP. Anytime the IMAP object is accessed, we are syncing the mailbox with the IMP-configured cache. For QRESYNC, we use the SELECT/EXAMINE uidset parameter. The problem is that any particular view may not be sync'd to the same state as the IMP cache. For example, if someone is using the web application and their phone is syncing via ActiveSync, it is quite likely that the activesync cached mod-sequence value will NOT equal the IMP cached mod-sequence value. So this is when explicitly calling FETCH VANISHED CHANGEDSINCE is needed. The good news: once we get the CHANGEDSINCE FETCH information, we don't need to do a separate flags sync since this information has already been cached within the IMAP object (via either the CHANGEDSINCE call or, more likely, a previous FETCH call in another session). Further optimization: in the case where the original QRESYNC/CONDSTORE sync matches the mod-sequence of whatever object/view is accessing the IMAP object, which should be the most common occurrence, there is no need to perform any additional FETCH/SEARCH calls since we cache the results of the initial mailbox sync and return this data. Might be a long-winded explanation, but just wanted to show why FETCH VANISHED CHANGEDSINCE MUST be used by a client even if taking advantage of QRESYNC SELECT/EXAMINE syncing. In other words - I'd like to think that my imap implementation is not broken :) b) Dovecot implemented it slightly better than required by RFC: http://www.ietf.org/mail-archive/web/lemonade/current/msg04771.html I spent a week or so trying to cache message sequence number -> UID mapping. And determined it was more trouble than it was worth. The gains from more compact VANISHED responses in SELECT/EXAMINE are minimal compared to the expense to track them. And the only other reason for tracking - the possibility that EXPUNGEs return EXPUNGED responses instead of VANISHED if the UIDs of the actually expunged messages are needed - can be worked around by doing a UID SEARCH call after the EXPUNGE is over and comparing to the list of UIDs that were given to UID EXPUNGE (with the further optimization that I cache MSN->UID while in a mailbox, which should catch the "STORE (\Deleted)/EXPUNGE" common when using a Trash mailbox or immediate message deletion). Unless I am missing something else that MSNs are necessary? michael
Re: [Dovecot] Issues with VANISHED CHANGEDSINCE
Quoting Timo Sirainen : On 8.11.2012, at 0.08, Michael M Slusarz wrote: I'm not sure changing the defaults is a good idea. But if someone does want to use a particular dovecot server as the backend for activesync clients, for example, it would probably make sense to allow these values to be tweaked via the config files. (I can see an organization having a "normal" IMAP server and a "activesync" IMAP server that differ in these details, and also in things like IDLE timeouts). Well .. I hate adding more settings. :) There are way too many already. Ideally Dovecot would automatically do the right thing anyway. Just like it already caches only those things that are needed. It could also increase these values when QRESYNC is used, or even better to actually have the separate expunge log that I mentioned. Thinking about this more, this can really all be handled by proper MUA design. In short, it is never a good idea to send a '1:*' UID range to a VANISHED CHANGEDSINCE FETCH. It remains a reasonable MUA design decision to not send the actual cached UID list to the FETCH command: if this cached UID list is thousands of messages long, obtaining this list, (optionally) sequence set compressing, and sending via the command may take more time/resources than it saves. But a MUA should, at a minimum, keep track of the minimum UID it is aware of in order to limit the possible response. This is a trivial amount of extra overhead and would prevent a large number of spurious VANISHED UIDs to need to be traversed. michael
Re: [Dovecot] Issues with VANISHED CHANGEDSINCE
On 8.11.2012, at 0.34, Michael M Slusarz wrote: > Quoting Michael M Slusarz : > >> I see your point, but the problem is that is not intuitive when reading the >> RFC. One part of the RFC defines the behavior of VANISHED (EARLIER) as only >> returning changes since the mod-sequence given. And you are correct that >> another part of the RFC says that, essentially, a server is allowed to break >> this required response. >> >> I'm thinking that this is more of an issue with the way the RFC is written. >> I'll move this over to the imap protocol list to get further input. > > Sigh. Never mind. For some reason, I completely ignored (missed?) this part > of the RFC: > > Note: A server that receives a mod-sequence smaller than , > where is the value of the smallest expunged mod-sequence > it remembers minus one, MUST behave as if it was requested to report > all expunged messages from the provided UID set parameter. > > So you are right, I was wrong, and the world is good. I wonder how much would it help if you a) Used the uidset/seqset parameters with SELECT command and optionally b) Dovecot implemented it slightly better than required by RFC: http://www.ietf.org/mail-archive/web/lemonade/current/msg04771.html
Re: [Dovecot] Issues with VANISHED CHANGEDSINCE
Quoting Michael M Slusarz : I see your point, but the problem is that is not intuitive when reading the RFC. One part of the RFC defines the behavior of VANISHED (EARLIER) as only returning changes since the mod-sequence given. And you are correct that another part of the RFC says that, essentially, a server is allowed to break this required response. I'm thinking that this is more of an issue with the way the RFC is written. I'll move this over to the imap protocol list to get further input. Sigh. Never mind. For some reason, I completely ignored (missed?) this part of the RFC: Note: A server that receives a mod-sequence smaller than , where is the value of the smallest expunged mod-sequence it remembers minus one, MUST behave as if it was requested to report all expunged messages from the provided UID set parameter. So you are right, I was wrong, and the world is good. michael
Re: [Dovecot] Issues with VANISHED CHANGEDSINCE
On 8.11.2012, at 0.08, Michael M Slusarz wrote: >> These defines in mail-transaction-log-private.h anyway can be changed to >> make it much less likely to see your problem: >> >> /* Rotate when log is older than ROTATE_TIME and larger than MIN_SIZE */ >> #define MAIL_TRANSACTION_LOG_ROTATE_MIN_SIZE (1024*32) >> /* If log is larger than MAX_SIZE, rotate regardless of the time */ >> #define MAIL_TRANSACTION_LOG_ROTATE_MAX_SIZE (1024*1024) >> #define MAIL_TRANSACTION_LOG_ROTATE_TIME (60*5) >> >> /* Delete .log.2 files older than this many seconds. Don't be too eager, >> older files are useful for QRESYNC and dsync. */ >> #define MAIL_TRANSACTION_LOG2_STALE_SECS (60*60*24*2) >> >> Maybe the defaults could be changed.. > > I'm not sure changing the defaults is a good idea. But if someone does want > to use a particular dovecot server as the backend for activesync clients, for > example, it would probably make sense to allow these values to be tweaked via > the config files. (I can see an organization having a "normal" IMAP server > and a "activesync" IMAP server that differ in these details, and also in > things like IDLE timeouts). Well .. I hate adding more settings. :) There are way too many already. Ideally Dovecot would automatically do the right thing anyway. Just like it already caches only those things that are needed. It could also increase these values when QRESYNC is used, or even better to actually have the separate expunge log that I mentioned.
Re: [Dovecot] Issues with VANISHED CHANGEDSINCE
Quoting Timo Sirainen : On 6.11.2012, at 3.49, Michael J Rubinsky wrote: That would require infinitely storing the modseq of when each message was expunged. Not very nice. Also the RFC talks a lot about this situation. The SELECT command has two optional parameters to optimize it. The RFC *does* indicate that a server implementation could, strictly speaking, be considered in compliance without remembering modsequences for all expunged messages, but it does explicitly discourage such implementations. From RFC 5162 [4.1]: Strictly speaking, a server implementation that doesn't remember mod- sequences associated with expunged messages can be considered compliant with this specification. Such implementations return all expunged messages specified in the UID set of the UID FETCH (VANISHED) command every time, without paying attention to the specified CHANGEDSINCE mod-sequence. Such implementations are discouraged, as they can end up returning VANISHED responses that are bigger than the result of a UID SEARCH command for the same UID set. This is talking about a server that doesn't permanently remember ANY modseqs for expunges. Dovecot remembers them, not not infinitely. It also gives advice to avoid infinitely storing the modsequences such as "expiring" sequences associated with older expunged messages, but assigning a single modsequence value to all of the expired expunged messages. Dovecot behaves as the section 4.3 describes. Note especially: Note that indefinitely storing information about expunged messages can cause storage and related problems for an implementation. .. Hence, implementations are encouraged to adopt strategies to protect against such storage problems, such as limiting the size of the queue used to store mod-sequences for expunged messages and "expiring" older records when this limit is reached. When the selected implementation-specific queue limit is reached, the oldest record(s) are deleted from the queue (note that such records are located at the queue head). For all such "expired" records, the server needs to store a single mod-sequence, which is the highest mod-sequence for all "expired" expunged messages. This is exactly what Dovecot does. There is a single modseq associated with all the previously expunged messages. If you try to request expunges for that modseq, it returns all of the expunged messages, which is what you're seeing as a problem. I see your point, but the problem is that is not intuitive when reading the RFC. One part of the RFC defines the behavior of VANISHED (EARLIER) as only returning changes since the mod-sequence given. And you are correct that another part of the RFC says that, essentially, a server is allowed to break this required response. I'm thinking that this is more of an issue with the way the RFC is written. I'll move this over to the imap protocol list to get further input. michael
Re: [Dovecot] Issues with VANISHED CHANGEDSINCE
Quoting Timo Sirainen : On 6.11.2012, at 3.49, Michael J Rubinsky wrote: These defines in mail-transaction-log-private.h anyway can be changed to make it much less likely to see your problem: /* Rotate when log is older than ROTATE_TIME and larger than MIN_SIZE */ #define MAIL_TRANSACTION_LOG_ROTATE_MIN_SIZE (1024*32) /* If log is larger than MAX_SIZE, rotate regardless of the time */ #define MAIL_TRANSACTION_LOG_ROTATE_MAX_SIZE (1024*1024) #define MAIL_TRANSACTION_LOG_ROTATE_TIME (60*5) /* Delete .log.2 files older than this many seconds. Don't be too eager, older files are useful for QRESYNC and dsync. */ #define MAIL_TRANSACTION_LOG2_STALE_SECS (60*60*24*2) Maybe the defaults could be changed.. I'm not sure changing the defaults is a good idea. But if someone does want to use a particular dovecot server as the backend for activesync clients, for example, it would probably make sense to allow these values to be tweaked via the config files. (I can see an organization having a "normal" IMAP server and a "activesync" IMAP server that differ in these details, and also in things like IDLE timeouts). michael
Re: [Dovecot] dovecot-lda not correct folder
Am 07.11.2012 16:23, schrieb Timo Sirainen: On 30.10.2012, at 7.33, tony.blue.mailingl...@gmx.de wrote: -m optionalfolder, without the dot. Also you may need to set lda_mailbox_autocreate=yes if it doesn't already exist. Thanks Timo, that was the solution of my problem.
Re: [Dovecot] No manpage for "doveadm fts" command
on Wed Nov 07 2012, Timo Sirainen wrote: > On 1.11.2012, at 16.38, Dave Abrahams wrote: > >> Just wanted to make sure this issue was registered separately from the >> overall confusion I'm exploring in another thread, even though I mention >> this there too. > > Yes, and dsync also needs to be moved into doveadm sync/backup. And > some other things. Feel free to write :) I'm still trying to figure out what these things do, which is why I'm looking for a manpage. I'm not exactly in a position to write anything. -- Dave Abrahams BoostPro Computing Software DevelopmentTraining http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
Re: [Dovecot] 2.2.alpha1 (626a9df21e62): LMTP Core Dump
> On 1.11.2012, at 12.27, Thomas Leuxner wrote: > >> Nov 1 11:16:14 spectre dovecot: lmtp(17245): Fatal: master: service(lmtp): >> child 17245 killed with signal 11 (core dumped) > .. >> #0 0x7f6174db3d35 in mail_storage_service_lookup (ctx=0x1160640, >> input=0x7fff905265d0, user_r=, error_r=> out>) at mail-storage-service.c:1013 >> 1013mail-storage-service.c: No such file or directory. >> in mail-storage-service.c >> (gdb) bt full > > Fixed a few days ago: http://hg.dovecot.org/dovecot-2.2/rev/1ad12af6efe4 Thanks and confirmed. smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] acl and subfolder
- Message de Timo Sirainen - Date: Wed, 7 Nov 2012 18:18:12 +0200 De: Timo Sirainen Objet: Re: [Dovecot] acl and subfolder À: Laurent Foucher Cc: dovecot@dovecot.org On 7.11.2012, at 10.25, Laurent Foucher wrote: I'm using dovecot 2.0.16 and i would like to use acl for subfolder. The file dovecot-acl is well written in both folder test and the subfolder test/Test : cat /home/user2/Maildir/.test.Test/dovecot-acl user=user1 ilrws cat /home/user2/Maildir/.test/dovecot-acl user=user1 ilprws When user1 want to list, the folder test is well shown, but not the subfolder test/Test. v2.1 has a nice and helpful "doveadm acl debug" command to tell what is wrong. imap(user1): Debug: acl: Mailbox not in dovecot-acl-list: Partages/user2/test/Test I guess this is the reason. See if deleting dovecot-acl-list helps. I deleted dovecot-acl-list and unfortunately my problem persit. -- - Laurent Foucher binR7lRCt2BrQ.bin Description: Clé publique PGP
Re: [Dovecot] Solr 4.0 - lucene - FTS
On 2012-11-07 11:29 AM, Timo Sirainen wrote:
On 7.11.2012, at 18.21, Charles Marcus wrote:
On 2012-11-07 10:14 AM, Timo Sirainen wrote:
Specifically, any plans for implementing immediate/automatic index updates at
delivery time? The lack of automatically updated indexes is one downside for
its implementation...
Nothing really prevents from adding that very easily .. I guess it would need a
new setting, which is always the most annoying part of small changes.:) I
think it would have to have a setting equivalent to doveadm index -n parameter,
which allows indexing most users, except those who pretty much never read their
emails. So with doveadm index -n 1000 you could set that if the mailbox's
\Recent count is over 1000, don't index the mailbox. So .. hmm. I guess two
settings would be cleaner:
plugin {
fts_autoindex = yes
fts_autoindex_max_recent = 1000
}
And this would work in conjunction with (and require) the dovecot LDA / LMTP?
Yes. For non-Dovecot LDA/LMTP you can already run "doveadm index" after the
delivery. Or you could do that already with dovecot-lda as well.
Gotcha... just confirming that as long as you were using dovecot
LDA/LMTP, index updates would be immediate and not impact system
performance.
Thanks... looking forward to its implementation someday. ;)
--
Best regards,
Charles
Re: [Dovecot] Solr 4.0 - lucene - FTS
On 7.11.2012, at 18.21, Charles Marcus wrote:
> On 2012-11-07 10:14 AM, Timo Sirainen wrote:
>>> Specifically, any plans for implementing immediate/automatic index updates
>>> at delivery time? The lack of automatically updated indexes is one downside
>>> for its implementation...
>> Nothing really prevents from adding that very easily .. I guess it would
>> need a new setting, which is always the most annoying part of small
>> changes.:) I think it would have to have a setting equivalent to doveadm
>> index -n parameter, which allows indexing most users, except those who
>> pretty much never read their emails. So with doveadm index -n 1000 you could
>> set that if the mailbox's \Recent count is over 1000, don't index the
>> mailbox. So .. hmm. I guess two settings would be cleaner:
>>
>> plugin {
>> fts_autoindex = yes
>> fts_autoindex_max_recent = 1000
>> }
>
> And this would work in conjunction with (and require) the dovecot LDA / LMTP?
Yes. For non-Dovecot LDA/LMTP you can already run "doveadm index" after the
delivery. Or you could do that already with dovecot-lda as well.
Re: [Dovecot] Solr 4.0 - lucene - FTS
On 2012-11-07 10:14 AM, Timo Sirainen wrote:
Specifically, any plans for implementing immediate/automatic index updates at
delivery time? The lack of automatically updated indexes is one downside for
its implementation...
Nothing really prevents from adding that very easily .. I guess it would need a
new setting, which is always the most annoying part of small changes.:) I
think it would have to have a setting equivalent to doveadm index -n parameter,
which allows indexing most users, except those who pretty much never read their
emails. So with doveadm index -n 1000 you could set that if the mailbox's
\Recent count is over 1000, don't index the mailbox. So .. hmm. I guess two
settings would be cleaner:
plugin {
fts_autoindex = yes
fts_autoindex_max_recent = 1000
}
And this would work in conjunction with (and require) the dovecot LDA /
LMTP?
--
Best regards,
Charles
Re: [Dovecot] acl and subfolder
On 7.11.2012, at 10.25, Laurent Foucher wrote: > I'm using dovecot 2.0.16 and i would like to use acl for subfolder. The file > dovecot-acl is well written in both folder test and the subfolder test/Test : > > cat /home/user2/Maildir/.test.Test/dovecot-acl > user=user1 ilrws > cat /home/user2/Maildir/.test/dovecot-acl > user=user1 ilprws > > When user1 want to list, the folder test is well shown, but not the subfolder > test/Test. v2.1 has a nice and helpful "doveadm acl debug" command to tell what is wrong. > imap(user1): Debug: acl: Mailbox not in dovecot-acl-list: > Partages/user2/test/Test I guess this is the reason. See if deleting dovecot-acl-list helps.
Re: [Dovecot] Auth USER lookup failed
On 6.11.2012, at 13.08, Angel L. Mateo wrote: > Nov 6 11:58:56 myotis30 dovecot: auth: Error: userdb(user1): client doesn't > have lookup permissions for this user: userdb uid (113246) doesn't match peer > uid (14585) (change userdb socket permissions) .. > I have checked the socket permissions, but they are 0666 (if I'm > looking the right socket): > > root@myotis30:/etc/dovecot/conf.d# ls -l /var/run/dovecot/auth-userdb > srwxrwxrwx 1 dovecot root 0 nov 6 11:43 /var/run/dovecot/auth-userdb Nowadays the auth-userdb permissions are 0666, which add the extra check that you can only lookup yourself. Since you're not looking up yourself, you're getting the permission error about it. > In fact, I have tried to put all sockets with permissions 0666 and > 0777, but the error persists. If the socket is 0777 this error shouldn't happen. Note that you need to change it from dovecot.conf, chmod doesn't matter after startup anymore. This will probably be helpful in future: http://hg.dovecot.org/dovecot-2.1/rev/c811aab61355
Re: [Dovecot] LDAP congestion
On 6.11.2012, at 11.38, Bernhard Schmidt wrote: > I've been asked to have a look at a misbehaving mail server of some > colleagues today where almost all logins where failing or excessively > delayed, while the LDAP database itself was pretty fast. > > They run Dovecot 1.2.11 (yes, I know, stoneage) against an LDAP server > run by a 3rd party, auth_bind=yes (required). The problem is that this > third party LDAP server delays bindResponse 3 seconds when the password > is wrong. A user wanted to login every 2-3 seconds this morning with the > wrong password, which effectively killed the system because the LDAP > connection was mostly stalled waiting for the auth timeout. > > From a previous discussion with Timo I know that bindRequests cannot be > parallelized in LDAP, so the problem does not come completely > unexpected. Other than removing the failure delay in the LDAP server, is > there anything one can do? If there is any change in newer Dovecot > versions about that please tell me so I can encourage them to upgrade, > but I haven't seen anything in the changelog. > > Any way to get several LDAP workers/connections for passdb in parallel? Multiple LDAP connections is in TODO. The only alternative right is to use e.g. checkpassword backend that does the ldap lookup in a script.
Re: [Dovecot] %{ldap:nonExistantAttribut} (was Re: v2.2.alpha1 released)
On 5.11.2012, at 20.58, Steffen Kaiser wrote:
> http://wiki2.dovecot.org/AuthDatabase/LDAP/Userdb?highlight=(%25{ldap)
>
> is the only reference I found so far and the TODO file.
>
> If the attribute does not exist, there should be a default value, you can
> specify, e.g.: %{ldap:attrName[,]:default value} . [,] the optional delimiter
> from the TODO.
Where do you see "," as optional delimiter? But yeah, %{ldap:attrName:default}
would be simple to do. Attached patch to do it. Let me know if it works.
ldap.diff
Description: Binary data
> Or if the attribute is missing, the rule is ignored.
Hmm. What if there are two attributes and one of them exists and the other one
doesn't?..
Re: [Dovecot] "starting" dovecot
On 2.11.2012, at 9.52, Dave Abrahams wrote: > > on Thu Nov 01 2012, Dave Abrahams wrote: > >> My system never issues the "dovecot start" command. I do, however, run >> /usr/local/libexec/dovecot/imap on port 9xxx. I talk to the server >> through port 9xxx and through the preauth tunnel. Is this arrangement >> OK? Are there some things that will only work if "dovecot" is invoked? > > In particular, I'm curious because of messages like the one below that I > got from "doveadm search": > > doveadm(dave): Error: net_connect_unix(/usr/local/var/run/dovecot/indexer) > failed: No such file or directory > > Is the lack of this (or any other) socket attributable to not having > started dovecot itself? Yes, fts indexing is always done via the indexer process currently. You need dovecot master process running for that. I don't think there are other such things currently. You could patch fts code to not use indexer process, probably a one line change. Except when running that way if two processes try to update the Lucene at the same time you'll get some errors.
Re: [Dovecot] Indexing problems
On 1.11.2012, at 15.08, Dave Abrahams wrote: > It looks like something is going very wrong here. Any advice? .. > doveadm(dave): Info: [Gmail].All Mail: Caching mails seq=2..231746 > 8000/231745Assertion failed: (numDocsInStore*8 == directory->fileLength( > (docStoreSegment + "." + IndexFileNames::FIELDS_INDEX_EXTENSION).c_str() )), > function closeDocStore, file > /tmp/clucene-gmYE/src/core/CLucene/index/DocumentsWriter.cpp, line 210. > Abort trap: 6 > cone:local dave$ Looks like a bug in CLucene library. Probably nothing I can do about it.. Just delete the lucene-indexes directory and run doveadm fts rescan.
Re: [Dovecot] No manpage for "doveadm fts" command
On 1.11.2012, at 16.38, Dave Abrahams wrote: > Just wanted to make sure this issue was registered separately from the > overall confusion I'm exploring in another thread, even though I mention > this there too. Yes, and dsync also needs to be moved into doveadm sync/backup. And some other things. Feel free to write :)
Re: [Dovecot] 2.2.alpha1 (626a9df21e62): LMTP Core Dump
On 1.11.2012, at 12.27, Thomas Leuxner wrote: > Nov 1 11:16:14 spectre dovecot: lmtp(17245): Fatal: master: service(lmtp): > child 17245 killed with signal 11 (core dumped) .. > #0 0x7f6174db3d35 in mail_storage_service_lookup (ctx=0x1160640, > input=0x7fff905265d0, user_r=, error_r= out>) at mail-storage-service.c:1013 > 1013mail-storage-service.c: No such file or directory. >in mail-storage-service.c > (gdb) bt full Fixed a few days ago: http://hg.dovecot.org/dovecot-2.2/rev/1ad12af6efe4
Re: [Dovecot] Modifying mailbox GUIDs?
I guess you could do that.. In v2.2 the dsync is smarter and can change the GUID automatically when needed. On 1.11.2012, at 5.13, Faheem Patel wrote: > > > I see that the GUID is actually in readable text on the first line > in "dovecot-uidlist". Is it really as simple as modifying the string > here? > > - Faheem > > On Wed, 31 Oct 2012 22:42:59 -0400, Faheem Patel > wrote: > >> Greetings all, >> >> I can view a mailbox's GUID like so: > doveadm mailbox status -u guid >> >> However, how may I *modify* a > mailbox GUID? Can this be done using doveadm or some other tool? >> >> > If not, how may I go about modifying the dovecot.mailbox.log (where I > assume GUID data is stored)? >> >> My specific use case has to do with > me wanting to modify an existing mailbox's GUID so that its messages are > mirrored into a folder of the same name using "dsync mirror". (As we > know, dsync utilizes GUIDs to determine mailbox uniqueness) >> >> > Thanks! >> >> -- >> - Faheem
Re: [Dovecot] Error: Internal quota calculation error
On 31.10.2012, at 21.15, Micah Anderson wrote:
> I'm using 2.1.7 with seive and mysql quotas. We had an outage the other
> day where the database server where quotas are stored was not available
> for a short period of time.
>
> In dovecot land, the following types of errors occured in that scenario:
>
> Oct 26 22:19:01 grosbeak dovecot: lda(exam...@riseup.net): Error: Internal
> quota calculation error
Hmm. I wonder if I should add more error message logging in here.. Although I
think the main reason is that dict isn't connected to SQL database, and it
should have logged about it already.
> Oct 26 22:19:01 grosbeak dovecot: lda(exam...@riseup.net): Error: sieve:
> msgid=<20122132765181x.abcce...@example.com>: failed to store into mailbox
> 'Trash': Internal error occurred. Refer to server log for more information.
> [2012-10-26 22:19:01]
> Oct 26 22:19:01 grosbeak dovecot: lda(exam...@riseup.net): Error: sieve:
> script /maildir/e/example/.dovecot.sieve failed with unsuccessful implicit
> keep (user logfile /maildir/e/example/.dovecot.sieve.log may reveal
> additional details)
>
> I expect that there would be quota calculation errors as dovecot could
> not reach the database server, but what worried me was the 'failed to
> store into mailbox' message from sieve. The 'Trash' mailbox in this
> particular seive script is the correct location for the message to be
> filed into, but the worrisome message is the 'failed with unsuccessful
> implicit keep'.
Dovecot returns temporary failure and the mail should get redelivered. v2.1.9+
has also plugin { quota_ignore_save_errors=yes } setting, which is the default
also with v2.2.
Re: [Dovecot] backtrace for non-existant %{ldap:attr} on login
On 31.10.2012, at 11.08, Steffen Kaiser wrote: > If mailQuotaBytesTrash or mailQuotaBytes is not present, the LOGIN process > does not work: .. > 2012-10-31 09:56:51 auth: Panic: pool_data_stack_realloc(): stack frame > changed I'm not entirely sure why that happens when nonexistent attributes, but this fixes the crash: http://hg.dovecot.org/dovecot-2.1/rev/3a33e686fc38 Maybe there's another bug in there as well that tries to write some large garbage to the string instead?..
Re: [Dovecot] maildir and end-of-line encoding
On 31.10.2012, at 3.50, Christoph Anton Mitterer wrote: > I just wondered, the following: > > My MDA may get mails that use LF or CR/LF end of line encodings and > deliver them into maildirs. > > > I couldn't find any information about, whether one should or must > convert all into one format, cause AFAIK at least on the IMAP side, > CR/LF is always used? > > How does this work on the maildir/backend side of dovcot? Can it work > with both and simply automatically convert LF into CR/LF? Dovecot automatically adds CRs where necessary. Even within the same file there can be mixed LF/CRLF lines.
Re: [Dovecot] copymail deleted
On 30.10.2012, at 16.44, Christian Rößner wrote: >> So if you create >> /attachments/6a/50/6a506530265ef7c9feb396410eaf6946036e9a79-b034401e794009503a042cb72ff6 >> that is 949170 bytes long, and do the same for the rest of the attachments, >> you should be able to read this mail without errors. >> >> You can easily create the files without wasting space with: >> dd if=/dev/zero of=foo bs=1 seek=949169 count=1 > > Thanks. I have calculated both other files and recreated zero padded files. > Now I am going to watch the log file and see, if errors are gone. > > One last question: If the user now opens a mail, where the attachments are > broken and he/she removes the mail, are the created hand-made files be > removed automatically? Yes.
Re: [Dovecot] mbox vs. maildir storage block waste
On 30.10.2012, at 2.16, Christoph Anton Mitterer wrote: > Have you ever thought about adding a "real" DB backend? Nothing against > dbox... :) ... and I have no performance comparison of dbox with what > could be done with a DBMS... but the advantage of the later would be > that you get all fancy features from database systems for free... like > fast indexing, online replication, etc. p.. > > One might even reuse something like AOX for this. SQL indexes aren't very helpful for IMAP-like data. It would be fun to some day have SQL backend in Dovecot (there already is read-only INBOX-only SQL backend), but I don't expect it to have very good performance.
Re: [Dovecot] mbox vs. maildir storage block waste
On 30.10.2012, at 13.00, Charles Marcus wrote: > On 2012-10-29 5:42 PM, Timo Sirainen wrote: >> On 29.10.2012, at 23.15, Christoph Anton Mitterer wrote: >> >>> btw: What are the actual advantages of sdbox over maildir? >> * Not moving files from new/ to cur/ directory >> * Not renaming files when changing message flags >> * Not readdir()ing directories (although maildir_very_dirty_syncs=yes helps >> a lot with this) >> >> Basically less disk I/O and making it possible to have mailboxes with a huge >> number of messages without everything slowing down horribly. > > I had been wanting to ask about this too... > > So... what are the disadvantages? Message flags are stored only in dovecot.index files, and files get somewhat more easily corrupted than the whole filesystem. Having a separate dovecot.index.backup file helps with this though. Also there's the disadvantages if you can't easily switch away from Maildir because you're using some non-Dovecot tools to access it.
Re: [Dovecot] dovecot-lda not correct folder
On 30.10.2012, at 7.33, tony.blue.mailingl...@gmx.de wrote: > ZUSATZORDNER="$DELIVERMAIL -e -d $LOGNAME -m .optionalfolder" > ... > > dovecot-lda puts the mails for the optionalfolder always in the .cur (INBOX). > > What´s the correct dovecot-lda parameter to put the mails in the > optionalfolder? -m optionalfolder, without the dot. Also you may need to set lda_mailbox_autocreate=yes if it doesn't already exist.
Re: [Dovecot] mbox2mdir... what about UIDs/etc? (was: how to best import Evolution/Thunderbird mail into dovecot?)
On 30.10.2012, at 2.42, Christoph Anton Mitterer wrote: > Which I'll base upon mb2md[1] respectively it's Dovecot-izsed > version[2]. > I diffed the two, and it seems the only differences are that the later > handles the following in addition: > 1) keywords (via X-IMAP, X-IMAPbase and X-Keywords) > 2) UIDs, UIDVALITIDYs and UIDLASTs (via the X-IMAP, X-IMAPbase and X-UID > mail headers of the mboxes > 3) ,S= and ,W= tags > > (Guess that's it right?) > > > Now I have some questions: > to 1) I never used keywords on mails myself so far,... so if any > X-Keywords headers exist, these were sent from remote. > So I guess I _really want_ to ignore them (and not let remote people set > my local keywords), right? Yes. > to 2) I haven't had time yet to read into the IMAP4 RFC (though I'll > need to do so soon),... but AFAIU the UIDs, UIDVALITIDYs and UIDLASTs > are used for the server/clients to identify which message they talk > about and avoid unnecessary reloading and to assure statuses are set on > the right message, etc. > > All mails that I migrate were only used locally by one client. > So I guess I can fully ignore any UID/UIDVALITIDY/UIDLAST preservation, > right? Yeah, they're not that important if you don't care about clients redownloading cached messages. > So in principle I can use plain mb2md (without the dovecot mods)... and > simply convert all my mboxes to maildir, put them in the dovecot mail > (having the mails in the ../new dirs) location and start dovecot, right? > > Now will dovecot itself assign fresh consecutive UIDs to all maildir > files? Or will I get into troubles? Dovecot will generate new UIDs. > to 3) If dovecot can make use of these,.. I'm happy with having them > set, but analogous to (2): > If I use plain mb2md (without the dovecot mods)... and simply convert > all my mboxes to maildir, put them in the dovecot mail (having the mails > in the ../new dirs) location and start dovecot > > Can I make dovecot to calculate these fields by itself when it loads? Dovecot doesn't add them to the filenames, but adds them to dovecot-uidlist and/or dovecot.index.cache. If you're using Maildir++ quota then this isn't good enough, but when using Dovecot LDA there's no reason to use Maildir++ quota anyway, so it doesn't matter.
Re: [Dovecot] Solr 4.0 - lucene - FTS
On 7.11.2012, at 15.01, Charles Marcus wrote:
> As one who is interested in implementing FTS sometime in the future, I'm
> curious about what is in store as far as improvements go...
>
> Specifically, any plans for implementing immediate/automatic index updates at
> delivery time? The lack of automatically updated indexes is one downside for
> its implementation...
Nothing really prevents from adding that very easily .. I guess it would need a
new setting, which is always the most annoying part of small changes. :) I
think it would have to have a setting equivalent to doveadm index -n parameter,
which allows indexing most users, except those who pretty much never read their
emails. So with doveadm index -n 1000 you could set that if the mailbox's
\Recent count is over 1000, don't index the mailbox. So .. hmm. I guess two
settings would be cleaner:
plugin {
fts_autoindex = yes
fts_autoindex_max_recent = 1000
}
Or maybe there's a better name than "autoindex" for this feature. SEARCH always
autoindexes anyway.
> Also, does the release of Solr 4.0 mean anything for the lucene library used
> by dovecot?
No, fts-lucene and fts-solr are separate backends. But I do have some small
plans to add a few more features to fts-solr.
[Dovecot] Solr 4.0 - lucene - FTS
Hi Timo, As one who is interested in implementing FTS sometime in the future, I'm curious about what is in store as far as improvements go... Specifically, any plans for implementing immediate/automatic index updates at delivery time? The lack of automatically updated indexes is one downside for its implementation... Also, does the release of Solr 4.0 mean anything for the lucene library used by dovecot? http://www.marketwatch.com/story/lucidworks-congratulates-apache-foundation-on-general-release-of-solr-40-2012-10-15 Thanks, -- Best regards, Charles
Re: [Dovecot] Dovecot ok for port 110, but not for SSL (beginner asking)
Am 07.11.2012 10:13, schrieb ycc_Swe:
> Hello,
>
> I just installed Dovecot. It works for plaintext autorization, port 110. It
> has connected with Telnet, Thunderbird and an on-line pop3 client.
>
> Telnet:
> +OK Dovecot ready.
> user n
> -ERR Unknown command.
> user n
> +OK
> pass xx
> +OK Logged in.
> stat
> +OK 1 1553
> retr 1
> +OK 1553 octets
> Return-path:
> Envelope-to: nnn...@mydomain.com
> Delivery-date: Tue, 06 Nov 2012 12:02:28 +0100
> Received: from bay0-xcvxcv-xvxcv.bay333.hotmail.com ([123.123.123.123])
> by deb7.pc with esmtp (Exim 4.80)
>
> But when I try ssl (port 995) with an on-line pop3 client, it will not work:
> /var/log/mail.log
> Nov 7 02:46:55 deb7 dovecot: pop3-login: Disconnected (no auth attempts in
> 0 secs): user=<>, rip=12.12.12.7, lip=123.123.123.123, TLS: Disconnected,
> session=
> Nov 7 02:46:56 deb7 dovecot: pop3-login: Disconnected (no auth attempts in
> 1 secs): user=<>, rip=12.12.12.7, lip=123.123.123.123, TLS: Disconnected,
> session=
>
> root@deb7:~# doveconf -n
> # 2.1.7: /etc/dovecot/dovecot.conf
> # OS: Linux 3.2.0-3-686-pae i686
> disable_plaintext_auth = no
> mail_gid = mail
> mail_location = mbox:~/mail:INBOX=/var/mail/%u
> namespace inbox {
> inbox = yes
> location =
> prefix =
> }
> passdb {
> args = username_format=%u /etc/dovecot/users
> driver = passwd-file
> }
> plugin {
> sieve = ~/.dovecot.sieve
> sieve_dir = ~/sieve
> }
> protocols = " imap pop3"
> ssl_cert = ssl_key = userdb {
> args = username_format=%u /etc/dovecot/users
> driver = passwd-file
> }
>
> I know very little about mail and ssl. I have assumed that ssl will be set
> up "automatically" when Dovecot is installed. But maybe I have missed
> something here. Please give me pointers.
> The following two files contain ssl keys:
> ssl_cert = ssl_key =
> I have tried changing the ssl parameter ("yes", "required") in 10-ssl.conf
> but with no change except that port 110 login becomes disabled.
>
> As you can see I am a beginner with Dovecot, I hope it is still OK to ask on
> this mailing list. Thanks.
>
>
>
> --
> View this message in context:
> http://dovecot.2317879.n4.nabble.com/Dovecot-ok-for-port-110-but-not-for-SSL-beginner-asking-tp38611.html
> Sent from the Dovecot mailing list archive at Nabble.com.
>
have a look
http://wiki2.dovecot.org/SSL/DovecotConfiguration
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
Aufsichtsratsvorsitzender: Joerg Heidrich
[Dovecot] Dovecot ok for port 110, but not for SSL (beginner asking)
Hello,
I just installed Dovecot. It works for plaintext autorization, port 110. It
has connected with Telnet, Thunderbird and an on-line pop3 client.
Telnet:
+OK Dovecot ready.
user n
-ERR Unknown command.
user n
+OK
pass xx
+OK Logged in.
stat
+OK 1 1553
retr 1
+OK 1553 octets
Return-path:
Envelope-to: nnn...@mydomain.com
Delivery-date: Tue, 06 Nov 2012 12:02:28 +0100
Received: from bay0-xcvxcv-xvxcv.bay333.hotmail.com ([123.123.123.123])
by deb7.pc with esmtp (Exim 4.80)
But when I try ssl (port 995) with an on-line pop3 client, it will not work:
/var/log/mail.log
Nov 7 02:46:55 deb7 dovecot: pop3-login: Disconnected (no auth attempts in
0 secs): user=<>, rip=12.12.12.7, lip=123.123.123.123, TLS: Disconnected,
session=
Nov 7 02:46:56 deb7 dovecot: pop3-login: Disconnected (no auth attempts in
1 secs): user=<>, rip=12.12.12.7, lip=123.123.123.123, TLS: Disconnected,
session=
root@deb7:~# doveconf -n
# 2.1.7: /etc/dovecot/dovecot.conf
# OS: Linux 3.2.0-3-686-pae i686
disable_plaintext_auth = no
mail_gid = mail
mail_location = mbox:~/mail:INBOX=/var/mail/%u
namespace inbox {
inbox = yes
location =
prefix =
}
passdb {
args = username_format=%u /etc/dovecot/users
driver = passwd-file
}
plugin {
sieve = ~/.dovecot.sieve
sieve_dir = ~/sieve
}
protocols = " imap pop3"
ssl_cert = http://dovecot.2317879.n4.nabble.com/Dovecot-ok-for-port-110-but-not-for-SSL-beginner-asking-tp38611.html
Sent from the Dovecot mailing list archive at Nabble.com.
[Dovecot] acl and subfolder
hello,
I'm using dovecot 2.0.16 and i would like to use acl for subfolder.
The file dovecot-acl is well written in both folder test and the
subfolder test/Test :
cat /home/user2/Maildir/.test.Test/dovecot-acl
user=user1 ilrws
cat /home/user2/Maildir/.test/dovecot-acl
user=user1 ilprws
When user1 want to list, the folder test is well shown, but not the
subfolder test/Test. This is the logs :
Debug: acl: acl username = user1
imap(laurent.foucher): Debug: acl: owner = 0
Shuka-a dovecot: imap(user1): Debug: acl vfile: Global ACL directory: (none)
Shuka-a dovecot: imap(user1): Debug: acl vfile: reading file
/home/user2/Maildir/.test/dovecot-acl
[]
imap(user1): Debug: acl: Mailbox not in dovecot-acl-list:
Partages/user2/test/Test
I don't userstand why the file dovecot-acl is not read from the
subfolder, while user1 and user2 have the same gid and write access to
the directories.
Thanks for your answers.
dovecot -n
auth_cache_size = 512 M
default_client_limit = 8400
disable_plaintext_auth = no
mail_access_groups = dovecot
mail_debug = yes
mail_location = maildir:~/Maildir
mail_plugins = acl
mail_privileged_group = dovecot
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope
encoded-character vacation subaddress comparator-i;ascii-numeric
relational regex imap4flags copy include variables body enotify
environment mailbox date ihave imapflags notify
namespace {
inbox = yes
location =
prefix =
separator = /
type = private
}
namespace {
list = children
location = maildir:%%h/Maildir:INDEX=~/Maildir/shared/%%u
prefix = Partages/%%u/
separator = /
subscriptions = no
type = shared
}
passdb {
args = cache_key=%u%s *
driver = pam
}
passdb {
args = /etc/dovecot/dovecot-ldap.conf.ext
driver = ldap
}
plugin {
acl = vfile
acl_shared_dict = file:/var/lib/dovecot/shared-mailboxes.db
mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename
mail_log_fields = uid box msgid size
sieve = ~/.dovecot.sieve
sieve_dir = ~/sieve
sieve_extensions = +notify +imapflags
}
postmaster_address = postmas...@iut-tlse3.fr
protocols = " imap sieve"
service auth {
client_limit = 8500
unix_listener auth-userdb {
group = Personnel_IUT
mode = 0666
}
}
service imap-login {
process_limit = 4096
process_min_avail = 16
service_count = 0
vsz_limit = 256 M
}
service imap {
process_limit = 4096
vsz_limit = 3036 M
}
ssl_cert =
laurent.fouc...@iut-tlse3.fr
Enseignant/Chargé de mission Systèmes & Réseau
Re: [Dovecot] Android ICS stock client and IMAP Capability issue.
Am 07.11.2012 08:13, schrieb Massimiliano Cianelli: > Hello, > > My phone: > Android ics 4.1.2 on galaxy nexus. > And yes, stock mean the default client that come with the os in IMAP mode. > > I already know about that configuration parameter, but it will display two > time namespace in postlogin capabilities, and so I like much more to adjust > the source code to fix the issue. > > Yes there is k9 but I didn't like it too much, I prefer the stock client and > is much important to keep compatibility with stock client then user-installed > client. > > About the issue on Google code, there is thr issue on google code... but > Google is a lot slow in fixing those things. > http://code.google.com/p/android/issues/detail?id=1811 > > In a few hour I'll update the issue noticing where is hidden the problem. > > Regards > Sent from Galaxy Nexus Hi , i shortly tested this with android sdk jelly bean 4.1.1 and "my setup" dovecot 2.1.10 with included orginal android mail app in imap mode, ,leaving IMAP prefix blank, everything works as expected, no double shown inbox, namespace problems etc so you might have to fit your namespace setup. Also you might follow allready given advice from here. Anyway , i understand you using "stock client" but you have to understand that the producers of mail clients optimize their stuff fitting best in their own server structure making money with it, therefor their motivation coding better imap code is not very high, same case is for outlook and microsoft however, i would say, fixing bugs is on the google site here, looks like there is patch at http://code.google.com/p/android/issues/detail?id=1811 and the issue seems long known i dont see any hard relation to dovecot in this case meanwhile using k9mail seems the best way to workaround there are lots of other bugs around android versions over the years i dont expect google to fix them > > Robert Schetterer ha scritto: > >> Am 06.11.2012 07:08, schrieb Ben Morrow: >>> At 6AM +0100 on 6/11/12 you (Massimiliano Cianelli) wrote: Hi, My setup: Dovecot 2 latest, installed to replace courrier IMAP, and off course configured with the dot separator and all folder under INBOX.*. The problem: My phone was driving me mad during the test, due that it will only recognize Inbox. How found the solution: I've started sniffing IMAP traffic on my server and ended up with one difference: On courier it ask for namespace, on dovecot it won't. I gives a better look, and noticed that courier show namespace capability on prelogin banner, adding it too solved the problem. Reason: Android ICS stock client seems do not honor the capability gived after the login. >>> >>> See http://wiki2.dovecot.org/Upgrading/2.0?highlight=%28capability%29 ; >>> you need to set imap_capability and/or get your client fixed. >>> >>> Ben >>> >> >> Hi, first ,what is the exact meaning of >> >> "Android ICS stock client" >> >> do you mean default included email client in standard android in imap >> mode, when yes, which version of Android , i like to test my own >> however is there changelog/code etc at google for this behave? >> >> conf example >> >> # Override the IMAP CAPABILITY response. If the value begins with '+', >> # add the given capabilities on top of the defaults (e.g. +XFOO XBAR). >> #imap_capability = >> >> setting stuff here might be complex , or lead to trouble with other >> clients, if setting this might fix problems ,with clients it should be >> advised in the wiki/example-conf and/or Timo >> >> or the other way ,for massive used clients there should be >> a seperate workaround section in the conf >> >> But fixing behave clients should be prime option anyway >> >> Meanwhile use K9mail in Android as best free option in imap mode servers >> >> Best Regards >> MfG Robert Schetterer >> >> -- >> [*] sys4 AG >> >> http://sys4.de, +49 (89) 30 90 46 64 >> Franziskanerstraße 15, 81669 München >> >> Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 >> Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer >> Aufsichtsratsvorsitzender: Joerg Heidrich Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
