6 ms·
Show HN: IMAP API – Self-hosted access to IMAP over REST
- dochtman 7y agoAny IMAP over REST API should just implement JMAP (RFC 8620 and 8621).
- rakoo 7y agoIndeed. Which is the perfect occasion to ask: who besides Fastmail implements it ?
- brongondwana 7y agoRight now - not heaps. https://jmap.io/software.html https://jmap.io/software.html has a list of some known implementations.
- detaro 7y agohttps://github.com/jmapio/jmap-perl https://github.com/jmapio/jmap-perl seems the most similar to the project discussed here. Anyone have experience with it?
- brongondwana 7y agoIt was largely written in about a week, a few years ago. It's quite stale now unfortunately. It was updated to the current RFCs for mail, but it's still on a very old Calendars version. The downside of the JMAP model for a proxy to IMAP is that you do need to have a bit of state in your proxy server. jmap-perl uses a sqlite3 database per user for storing that state. Structurally, it's a non-blocking server in front of a forking server - the non-blocking handles connections and event streaming, and opens multiple backend forking servers per user, one for reads, one for writes, and one for background syncing/import.
- andris9 7y agoThere is only a handful of IMAP server implementations and there are going to be even fever JMAP servers. It is super bloated, the RFCs 8620 and 8621 are already 200 pages in total. Not an easy thing to integrate with.
- brongondwana 7y agoTo be fair, RFC3501 is 108 pages, and the bis (draft-ietf-extra-imap4rev2-12) is 157 pages. It's a complex problem space. I'm looking forward to getting JMAP Calendars and JMAP Contacts done, at which point is becomes a much more compelling replacement for multiple protocols.
- toomuchtodo 7y agoAnything we can do to help in getting those other extensions done?
- brongondwana 7y agoThe next IETF meeting is in Vancouver in late March - we'll be discussing them there. Other than that, get involved on the mailing list, and help review the documents! https://datatracker.ietf.org/group/jmap/meetings/ https://datatracker.ietf.org/group/jmap/meetings/ https://www.ietf.org/mailman/listinfo/jmap https://www.ietf.org/mailman/listinfo/jmap https://datatracker.ietf.org/doc/draft-ietf-jmap-calendars/ https://datatracker.ietf.org/doc/draft-ietf-jmap-calendars/ https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact/ https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact/
- deleted 7y ago[deleted]
- inputmice 7y agoThe problem JMAP is addressing is quite complex that’s why the JMAP spec is long. I do not however find it to be bloated. On the contrary I actually found it quite easy to read. (I've implemented jmap-mail on the client side.) One could potentially write JMAP as a proxy to an existing IMAP server (just like your 'imap-api') therefore the current lack of JMAP servers doesn’t really matter.
- nolok 7y agoCan anyone tell me if the license as given > Licensed for evaluation use only Is clear enough in legal terms for what can or cannot be done ? I assume it means it's free to use to test it and see how it works, but not for anything else ? Does that cover the code too ?
- andris9 7y agoupdate. The project has now a OS license assigned, so it is perfectly legal to use
- andris9 7y agoIt mostly means I haven’t yet figured out which kind of license/terms to use for this project. TBD.
- grizzles 7y agoThanks for your work in this area. A couple questions. How is this different to the wilduck webmail api? Would it be hard to abstract away the wildduck storage code to use a datastore other than mongodb?
- andris9 7y agoWildDuck API exposes database structures from MongoDB, IMAP API is more like a proxy in front of any IMAP server. WildDuck is pretty much coupled with MongoDB. IMAP is not very easily abstractable and keeping the result scalable at the same time. Largest WildDuck cluster in production manages 20TB (~20k accounts) of email by now with no special config or modifications - making it scalable was the main goal from the start and supporting arbitrary storage would not have helped.
- sneak 7y agoIt remains to be seen if API shapes are copyrightable. :D
- godzillabrennus 7y agoBasically, as a lay person, to me this means it’s not licensed for use in anything you care about. Fine for playing around with on your computer but not integrating with anything productive. This is not legal advice though. Always consult a lawyer if you have legal questions.
- pouta 7y agoAll I can see is I'm a papi .com
- tdhz77 7y agoI’ve heard imap is insecure. I’ve disabled it by default but this is intriguing. Anybody have any more information on imap security?
- herpderperator 7y agoIf you are concerned about someone reading your emails in transit, make sure you use TLS. IMAP is standard; as far as I know, almost everything uses it.
- dspillett 7y agoAny references for where you've heard this? Then we can check the claims and perhaps reassure you or suggest workarounds. What are you using instead? IMAP is on its own insecure because it is a plain protocol, but it can be used in conjunction with TLS to add secure transport. Exactly the same can be said for many other mail protocols such as POP3.
- revicon 7y agoGoogle spreads a lot of FUD (right or wrong) about anything that doesn’t use their oAuth. https://www.zdnet.com/article/google-were-banning-these-insecure-apps-from-connecting-to-g-suite-accounts/ https://www.zdnet.com/article/google-were-banning-these-inse...
- andris9 7y agoThe "insecurity" in IMAP mostly comes from password based authentication. The client application needs to know cleartext account password to use it and the same password, if leaked, can usually be used to manage the account. While browser based applications are pretty good already for blocking unintended usage, showing captchas to block bots etc, then it is way harder to do the same on the IMAP server side. So in general it comes down to configuration. IMAP per se is not insecure. How you use it though, might be.