Re: JMAP: Re: http API for IMAP
proxy.jmap.io is very stale code at the moment. I'm hoping to have enough time to hack on it at the IETF hackathon this weekend :) Cheers, Bron. On Fri, Nov 15, 2019, at 00:44, Thomas Güttler via dovecot wrote: > Am 14.11.19 um 14:03 schrieb Benny Pedersen via dovecot: > > Thomas Güttler via dovecot skrev den 2019-11-14 08:55: > > > >> Is there already an open source imap2jmap server? > > > > why do you say imap here ? > > > > https://www.cyrusimap.org/imap/developer/jmap.html > > > > cyrus already have it, we just wait for dovecot :) > > > I used my favorite search engine (ecosia) and found > > https://proxy.jmap.io/ > > This way you can use JMAP even if you imap server does not > support it. > > > Regards, > Thomas Güttler > > > -- > Thomas Guettler http://www.thomas-guettler.de/ > I am looking for feedback: https://github.com/guettli/programming-guidelines > -- Bron Gondwana br...@fastmail.fm
Re: JMAP support in Dovecot
On Wed, May 22, 2019, at 23:43, Tanstaafl via dovecot wrote: > On Wed May 22 2019 05:44:59 GMT-0400 (Eastern Standard Time), Aki Tuomi > via dovecot wrote: > > Unfortunately we have not been able to work on this much, but also the > > JMAP spec was until very recently still being worked. We have open > > dialogue with the Thunderbird people, they haven't so far indicated any > > pressing need for JMAP in Dovecot. > > > > This said, JMAP is still very much in our roadmap. Perhaps just not as > > close as I initially thought. Obviously I'd love to help out in any way possible here! We're very keen to see JMAP support in Dovecot to encourage others to move towards it as well. > Thanks Aki - no pressing need because of the old chicken/egg problem I > guess... > > That said, a few tidbits... > > The Thunderbird Devs are using Topicbox for discussing Thunderbird UI > development, and Topicbox is built directly on top of JMAP for the email > integration (I'm not sure they even knew this until I told them yesterday): > > From: https://fastmail.blog/2018/12/27/jmap-is-on-the-home-straight/ > > "But enough about the software, how about the experience! When we > created our brand new Topicbox product, we built directly on top of JMAP > for the email. We also used JMAP-inspired APIs for the rest of the > product experience, so Topicbox’s early users have been on JMAP for over > a year now." > > Lastly, Fastmail is now rolling it out - 30% of their userbase is on > JMAP, and all new users are automatically on it. Cyrus also provides > experimental JMAP support in their development snapshots. Actually, 99% of our user base has been on JMAP for about 4 months now! The one remaining percent was users with the old version of our mobile apps, and they're being cut off next month. As for JMAP mail and JMAP core - they're currently with the RFC editor for the final round of edits - they should have assigned RFC numbers in the next few weeks I would imagine. There will be some minor editorial polish, but the way it works is entirely stable now, there won't be more changes. https://datatracker.ietf.org/doc/draft-ietf-jmap-core/ https://datatracker.ietf.org/doc/draft-ietf-jmap-mail/ We're planning to have full support for everything in those specs into Cyrus IMAP version 3.2 as well. Right now there's a couple of gaps that we either don't use at FastMail or are papering around with our perl middleware. You can see the remaining tasks here as we progress: https://github.com/cyrusimap/cyrus-imapd/labels/3.2 Cheers, Bron. -- Bron Gondwana br...@fastmail.fm
Re: Question about imap (expunge response)
Yeah, that smells bogus. You can't send the EXPUNGE right away, even if you did the EXPUNGE. As the server you're required to wait for a command which allows expunges to happen. I've double-checked the Cyrus IMAP server, and we check usinguid to decide if we can tellexpunge at the end of index_store - aka, only UID STORE will tell the client EXPUNGE responses. Unfortunately, this is a pretty common way in which IMAP servers are non- compliant - immediate EXPUNGE combined with incorrect telling of EXPUNGE responses. Having said that, fetchmail is also wrong here: fetchmail: IMAP> A0008 STORE 1 +FLAGS.SILENT (\Seen \Deleted) fetchmail: IMAP< * 1 EXPUNGE fetchmail: IMAP< A0008 OK Store completed fetchmail: IMAP> A0009 EXPUNGE fetchmail: IMAP< A0009 OK EXPUNGE completed fetchmail: mail expunge mismatch (0 actual != 1 expected) There is no guarantee that you would get exactly 1 from the EXPUNGE command. You could easily have had other messages marked \Deleted, or even this same message get the \Deleted flag removed by another session in the gap between A0008 and A0009. the EXPUNGE could return any response between zero and the number of messages in the mailbox. In theory, the number of messages could even have been increased and then the EXPUNGE removed more than the previous mailbox size all at once! Bron. On Sat, Dec 16, 2017, at 04:18, Kamil Jońca wrote: > > (This is not neccesarily about dovecot, but rather IMAP protocol) > > At https://drive.google.com/open?id=1j3oa5jYeSdiPbgaihq02K-u_vHbZLJZQ> is > fetchmail log from my sessinon with polish email provider > "Wirtualna> Polska" > As you can se fetchmail logged "* 1 EXPUNGE" as a response to "STORE"> > command. > According to https://tools.ietf.org/html/rfc3501#section-7.4.1 > EXPUNGE must not be sent as response to STORE command. > Am I right that their imap server is erroneous or am I missing > something? > KJ > > > -- > http://stopstopnop.pl/stop_stopnop.pl_o_nas.html > Lonely men seek companionship. Lonely women sit at home and wait. > They never meet. -- Bron Gondwana br...@fastmail.fm
Re: JMAP support in Dovecot
Hi Charles, We are actually pretty close to a complete implementation in Cyrus now, and there's the proxy of course. We'll be doing a release candidate of Cyrus 3.0 with JMAP support on January 13th. There's also the hosted copy of the JMAP proxy, which I'm afraid I haven't been giving much love recently. It's very close to feature complete though. What number is the Thunderbird bug? I appear to not be CCd, or missing the emails from it. I should probably sign up! Feel free to ask me anything directly as well. Bron. On Wed, 14 Dec 2016, at 02:33, Tanstaafl wrote: > Hi Aki, > > Someone just asked in the bug for Thunderbird for this, so... > > Is there a git branch that they could use to start playing with what is > there? If not, any idea when that might happen? > > It sounds like someone following the Thunderbird bug is interested in > working on this, but they obviously need something to test against. > > Thanks, > > Charles > > > On 11/27/2016 5:28 AM, Aki Tuomi <aki.tu...@dovecot.fi> wrote: > > Hi! > > > > We are working on including JMAP support to Dovecot. At this moment I > > cannot give any promise for exact version, but hopefully it will be part of > > v2.3 > > > > Aki Tuomi > > > > Dovecot Oy > > > >> On November 26, 2016 at 11:17 PM Andrew Jones <and...@mykolab.com> wrote: > >> > >> > >> Hi Marcus > >> > >> Thanks for your helpful reply. > >> > >> Do you know what is going on with JMAP development into Dovecot 2.5? > >> > >> It's difficult to get any sort of information from the roadmap and there > >> are no Dovecot forums. > >> > >> One of the main reasons I'm interested in JMAP is because of Roundcube > >> Next and also the other clients it will power. Sadly, there has been > >> little going on and having emailed Thomas, he is no longer involved in > >> Roundcube Next - which is a shame. The Kolab guys are really taking > >> liberties here, and trying their product, the thing is littered with bugs > >> everywhere. > >> > >> Are you able to comment on what is going on with JMAP development into > >> Dovecot? > >> > >> Thanks > >> > >> Andrew > >> > >> > >> > >> > >> Sent from my iPhone > >> > >>> On 26 Nov 2016, at 19:16, Marcus Rueckert <da...@opensu.se> wrote: > >>> > >>>> On 2016-11-26 11:07:00 -0800, WJCarpenter wrote: > >>>> I don't know the answer to that question, but I am curious about > >>>> something. > >>>> What client are you thinking about using with JMAP? I haven't found much. > >>>> (And much of the demo stuff at jmap.io seems to be busted in various > >>>> ways.) > >>> > >>> roundcube-next builds on top of it. > >>> > >>>darix > >>> > >>> -- > >>> openSUSE - SUSE Linux is my linux > >>> openSUSE is good for you > >>> www.opensuse.org -- Bron Gondwana br...@fastmail.fm
Re: JMAP support in Dovecot
On Sun, 27 Nov 2016, at 06:07, WJCarpenter wrote: > I don't know the answer to that question, but I am curious about > something. What client are you thinking about using with JMAP? I haven't > found much. (And much of the demo stuff at jmap.io seems to be busted in > various ways.) The demo proxy was a pretty quick hack and isn't very efficient, but it should be working. It does a fairly slow background import for existing accounts, so I'd recommend using small tests accounts. What particular bit is broken for you? (apart from the known not-working authentication flow) Bron. -- Bron Gondwana br...@fastmail.fm
Re: Dovecot Oy merger with Open-Xchange AG
On Tue, Mar 24, 2015, at 04:34 AM, Philipp wrote: Show me OSS for cyrus, courier, .. on that level of enterprisey. Hey, FastMail has been contributing pretty advanced stuff to Cyrus for years, and it's all open. Back on topic - contrats Timo. Hope the merger works well for you. It's good to have two strong open-source mail servers out there. Bron. -- Bron Gondwana br...@fastmail.fm
Re: [Dovecot] Strange output from LIST command
On Tue, Oct 15, 2013, at 06:23 AM, Michael M Slusarz wrote: Quoting azurIt azu...@pobox.sk: i'm using Dovecot 2.1.7 (Debian Wheezy) and output from LIST command looks strange: C: 4 LIST () (INBOX INBOX.Karantena INBOX.Spam) RETURN (STATUS (UNSEEN)) S: * LIST () . INBOX S: * LIST () . INBOX.Karantena S: * STATUS INBOX.Karantena (UNSEEN 0) S: * LIST () . INBOX.Spam S: * STATUS INBOX.Spam (UNSEEN 0) S: 4 OK List completed. The UNSEEN information for INBOX is completely missing. It is correct behavior? No. RFC 5819 [2]: For each selectable mailbox matching the list pattern and selection options, the server MUST return an untagged LIST response followed by an untagged STATUS response containing the information requested in the STATUS return option. Just wondering if the INBOX was SELECTed at the time? There's some fun interaction around STATUS and SELECT in RFC3501. Bron. -- Bron Gondwana br...@fastmail.fm
Re: [Dovecot] Strange output from LIST command
On Thu, Oct 17, 2013, at 09:21 PM, azurIt wrote: __ Od: Bron Gondwana br...@fastmail.fm Komu: Michael M Slusarz slus...@curecanti.org, dovecot@dovecot.org Dátum: 17.10.2013 12:14 Predmet: Re: [Dovecot] Strange output from LIST command On Tue, Oct 15, 2013, at 06:23 AM, Michael M Slusarz wrote: Quoting azurIt azu...@pobox.sk: i'm using Dovecot 2.1.7 (Debian Wheezy) and output from LIST command looks strange: C: 4 LIST () (INBOX INBOX.Karantena INBOX.Spam) RETURN (STATUS (UNSEEN)) S: * LIST () . INBOX S: * LIST () . INBOX.Karantena S: * STATUS INBOX.Karantena (UNSEEN 0) S: * LIST () . INBOX.Spam S: * STATUS INBOX.Spam (UNSEEN 0) S: 4 OK List completed. The UNSEEN information for INBOX is completely missing. It is correct behavior? No. RFC 5819 [2]: For each selectable mailbox matching the list pattern and selection options, the server MUST return an untagged LIST response followed by an untagged STATUS response containing the information requested in the STATUS return option. Just wondering if the INBOX was SELECTed at the time? There's some fun interaction around STATUS and SELECT in RFC3501. Bron. Here's the complete IMAP communication, see the (1) only: http://bugs.horde.org/view.php?actionID=view_filetype=logfile=imap-ok.logticket=12748 I also find out that it's working ok when i LIST the INBOX alone like this: C: 4 LIST () (INBOX) RETURN (STATUS (UNSEEN)) S: * LIST () . INBOX S: * STATUS INBOX (UNSEEN 2) S: 4 OK List completed. The information about UNSEEN messages is correct. It's only doing problems when listing multiple folders at once. Yeah, that definitely looks like a bug! I've CC'd Timo to grab his attention :) Hey Timo, it works right in Cyrus :p . list () (INBOX INBOX.Trash INBOX.Archive) RETURN (STATUS (UNSEEN)) * LIST (\HasChildren) . INBOX * STATUS INBOX (UNSEEN 0) * LIST (\Trash) . INBOX.Trash * STATUS INBOX.Trash (UNSEEN 0) * LIST (\HasChildren \Archive) . INBOX.Archive * STATUS INBOX.Archive (UNSEEN 0) . OK Completed (0.010 secs 113 calls) (I have specialusealways configured, doesn't seem to break anyone) Bron. -- Bron Gondwana br...@fastmail.fm
Re: [Dovecot] Strange output from LIST command
On Thu, Oct 17, 2013, at 11:46 PM, Michael M Slusarz wrote: Quoting Bron Gondwana br...@fastmail.fm: On Tue, Oct 15, 2013, at 06:23 AM, Michael M Slusarz wrote: No. RFC 5819 [2]: For each selectable mailbox matching the list pattern and selection options, the server MUST return an untagged LIST response followed by an untagged STATUS response containing the information requested in the STATUS return option. Just wondering if the INBOX was SELECTed at the time? There's some fun interaction around STATUS and SELECT in RFC3501. Except as I read 5819, this is completely irrelevant. LIST-STATUS != STATUS. LIST-STATUS produces STATUS-like responses, but isn't controlled by any of the rules of the original STATUS. At least that's how I interpret it. Yeah, that may be - except at least in Cyrus they share quite a lot of common code. Probably in Dovecot as well. Such things are a fertile ground for bugs, particularly in IMAP with all the ugly special case corners that exceptions create over time. I wish SELECTED was less special in a bunch of ways. Looking at the rest of this thread, I think we are all in agreement that something is fishy. As OP reported, it appears to be something specific with personal namespaces (possibly 'INBOX.' only). Yep, definitely looks fishy! Bron. -- Bron Gondwana br...@fastmail.fm
Re: [Dovecot] Non-dovecot user looking for feedback
God, that's ancient data for Cyrus. I should go update that. Cyrus 2.4.17 fails a couple of edge cases (searching for and some complex list-extended cases where we're not iterating both the mailboxes and subscriptions databases concurrently correctly). Cyrus git master only fails the list-extended. In other words, don't believe every wiki you read on the internet! Bron. On Tue, Dec 18, 2012, at 07:19 AM, Chris Ross wrote: Thank you for that. That mostly rules out Cyrus, as it seems much the lesser of Dovecot and UW-IMAP. But, it mostly just declares it's statements about accordance with the standards. While I appreciate that, I'm more interested in how it behaves with common mail clients. And, the note about dovecot Expunge Fetch says depends on storage, but gives no more information. What sorts of storage options are available, and what the pros and cons of them are, was one of my original questions. Is there some give me all the details to read through document somewhere? What it does, it's capabilities, and how it does things? Thanks again to all for any help. - Chris On Dec 17, 2012, at 07:48 , David Morsberger d...@morsberger.com wrote: Check out: http://imapwiki.org/ImapTest/ServerStatus -- David Morsberger 301-758-7387 Sent from my iPhone On Dec 17, 2012, at 2:00 AM, Chris Ross cross+dove...@distal.com wrote: I've been using UW-IMAPd for neigh on forever (at least since 2001). But, as it's basically stalled, and I'm about to update the hardware that is my mail server, I thought it was time to review existing open-source IMAP servers. Dovecot is the top three in my looking. The other of the top three candidates, because I know of people who've used it, is Cyrus IMAP. So, I should note that my thoughts are uw-imapd, because I already know how to use it, Cyrus, because someone I know/trust liked it years ago, and dovecot, because it seems stable, professional, and to meet all of my needs. I guess the biggest question I have is how files/folders are stored in the filesystem. uw-imapd has a mbx format that all of my folders are in, and also has support for mbox and maildir (i think). mbx had some advantages for speed access, which would be unimportant I assume with dovecot's indexes, but IIRC there was also some reason the mbox format coped poorly with multiple clients accessing the same folder at the same time. So, am I right that dovecot supports only the one big full file mbox format, and the maildir format? And if so, is it known to allow multiple simultaneous IMAP clients to access and monitor and/or modify the same folder simultaneously? After those questions, it's just a what do you think the pros and cons of each are? I know asking in this forum, that I will get most if not all votes for Dovecot. And that's fine, as long as you have specific reasons why it would be better for someone with only a handful of users and minimal time available to administer the systems in question. Thanks! I appreciate any and all feedback. - Chris -- Bron Gondwana br...@fastmail.fm
Re: [Dovecot] Cyrus vs Dovecot
On Wed, Aug 13, 2008 at 01:07:34PM -0400, Wesley Craig wrote: On 13 Aug 2008, at 10:31, kbajwa wrote: I think you are missing a point which is most important, i.e., what type of support Cyrus vs Dovecot offers. In my experience: Cyrus = 0 Dovecot= 100 As someone who answers many help requests for cyrus (and I'm very far from the only one), I can honestly say I've never seen a requests from you. Perhaps you've had a lot of occasion to ask for help with Dovecot. I'm happy to hear you've gotten that help. Community is a lot of what open source software is about. As for your experience with the cyrus imapd community, perhaps your sample size is too small. Yeah, there are a few of us here answering help requests, and even helping debugging in some cases. I'd be interested to see where that '0' comes from too. Still, I think Cyrus and Dovecot are the best two imap servers out there, so it's going to be a question of which integrates best with your usage pattern. For a small server, starting with no experience in either, I would probably choose Dovecot. Now that I know Cyrus inside out, back to front, warts and all - well, I'd choose Cyrus because I know how to make it play nice. It's more of a total system in itself though, that you write support stuff around. Dovecot integrates more with other tools in a unix-daemon'y way. Enjoy, Bron ( now if someone came along with a compelling competitior for SASL... )
