15 ms·

JMAP: Like IMAP but Not Really

325 points by jasonmunro 8y ago

andridk 8y ago
I was really hoping for a GraphQL API standard for mail before reading this. But this sounds good too.
- thomasfoster96 8y ago
  Reading through the JMAP website [0], I'm actually wondering whether whoever's behind JMAP has looked at GraphQL. There seem to be a lot of similarities (especially the "why not REST" section). [0] https://jmap.io/index.html https://jmap.io/index.html
  - ForHackernews 8y ago
    I think Fastmail are the primary ones behind JMAP: https://fastmail.blog/2014/12/23/jmap-a-better-way-to-email/ https://fastmail.blog/2014/12/23/jmap-a-better-way-to-email/
    - jasonmunro 8y ago
      Yep. Also I think they are using it for a subset of customers. While JMAP support in Cypht is still new, so far it's working just like IMAP, but my testing is limited since I just wrote the integration :)
  - detaro 8y ago
    Work on JMAP likely started before GraphQL was publicly released.
- Mailtemi 8y ago
  Actually, Outlook GraphQL reusing the idea of batch JMAP calls. https://docs.microsoft.com/en-us/previous-versions/office/office-365-api/api/beta/batch-outlook-rest-requests-beta https://docs.microsoft.com/en-us/previous-versions/office/of...
- chrismorgan 8y ago
  Understand that JMAP is an object synchronisation protocol. It’s most interested in the problems that are out of scope for GraphQL. You could have a variant of JMAP with GraphQL syntax and semantics, but there would be a fair bit of mismatch, for their purposes and focuses are quite different: JMAP is concerned with object identity and synchronisation, for what you might call thick clients (and JMAP Mail needs to be broadly IMAP compatible), while GraphQL is UI-focused, for what might reasonably be considered to be thin clients (not that they are logicless, but that they are very much focused on offloading burden to the server). I see no compelling case for a JMAP-like GraphQL thing. It could still be an interesting task to develop a object synchronisation protocol like the JMAP core on top of GraphQL.
hardwaresofton 8y ago
I really want to see some innovation in the email space. The landscape is like a sea of false promises and dashed dreams. SMTP is one of the bread-and-butters of the internet, yet it just doesn't seem to be moving forward (maybe that's for the best), and no one's building extensions on top of it. Maybe I'm naive in thinking it was possible but we could have avoided this whole "make an account on X messenger so we can talk", if someone had just jammed XMPP and SMTP together. Every few years I'm tempted to try and write a SMTP server (MX) myself but then realize that postfix has been around so long and is the go to choice for a reason. I don't have 20 years of figuring out how X mail server interprets SMTP to be as reliable as postfix. I settled for trying to wrap it[0]. [0]: https://gitlab.com/postmgr/postmgr https://gitlab.com/postmgr/postmgr
- amanzi 8y ago
  "if someone had just jammed XMPP and SMTP together" - wasn't that kind of what Google Wave was aiming for?
  - lucideer 8y ago
    Yes. And the vision for Google Wave was great. The execution was just abominably bad (primarily on the frontend/UI side), and Google's failures in execution carried over reputationally to the—now dead—Apache incubator.
    - vidarh 8y ago
      Not just the UI side. The underlying protocol was also pointlessly over-engineered. SMTP is still around because it is simple. You can get a basic SMTP client running in an hour or two. You can get a basic server running in a similar amount of time, at least in a higher level language. That matters, not because anyone will have anything usable in that time, but because it lets you start to experiment very, very easily. Wave suffered from a UI that was a mess layered on top of a protocol that made it really hard for people to get started on experimenting with alternative frontends, and without a user-base giving people a reason to persist figuring out how to interoperate with it. Had the protocol been simpler, the UI mess might not have mattered so much - people might have come up with their own ideas.
akie 8y ago
The article mentions that JMAP does calendars as well. Anyone have a quick status update on how it compares to CalDav and if it's supported by any of the major calendar clients or servers? I did a quick google and looked at the JMAP site but couldn't find any info. Background for this is that I implemented a calendar client and a calendar server (with SabreDAV) last year and I'm wondering if I should be adding support for JMAP anytime soon.
- sigsergv 8y ago
  Current state of calendaring is horrible, it's basically not possible right now to create compatible and reliable library/application.
  - tinus_hn 8y ago
    Calendaring truly is surprisingly difficult. Dates and times just are not defined with computers in mind.
    - sigsergv 8y ago
      Yep, they are extremely difficult. Timezones, group events, repeatable events. RFCs describing calendaring are very vague and miss a lot of important details. And exchange/outlook implementation adds a huge pile of incompatibility. When I was working on calendaring project I've found lots of ways to create broken events in google calendar for example. They are completely valid according to RFC but absolutely not usable in apps. Also there are working groups that STILL developing calendaring RFCs, they create tons of esoteric and cryptic documents every year. P.S. When I write “RFC” I mean any well established standard.
- nmjenkins 8y ago
  Editor of the JMAP specs here. The JMAP calendar spec is currently just a draft, but now JMAP core and mail are (more or less) finalised and JSCalendar (https://tools.ietf.org/html/draft-ietf-calext-jscalendar-11 https://tools.ietf.org/html/draft-ietf-calext-jscalendar-11) is in last call too, we will be looking to take the JMAP Calendar spec through the IETF process in the very near future. Since it is essentially just combing core with the JSCalendar data format, this should be reasonably straight forward.
busfahrer 8y ago
I recently thought about email being based on such an old standard and then I wondered if maybe it didn't matter anymore, because most of the web is moving to gmail, and my guess is (and somebody please correct me) that when I send an email from gmail to gmail, that no actual SMTP is involved? I'm assuming that they have some internal protocol that is just adapter'd to "Email" at the very end?
- beagle3 8y ago
  It fakes it, at the very least - you can do a “show original message” and see all the RFC.822 and mine headers. Microsoft Exchange used to not bother with actually SMTPing when talking to another exchange server (or itself), I don’t know what it does these days.
- pjc50 8y ago
  > most of the web is moving to gmail This isn't true; there's a LOT of industry on Exchange of some sort, and plenty of older institutions running their own email. Especially in IETF land. And it's a huge risk increase if everyone moves everything to gmail.
- mattnewport 8y ago
  I hear of a lot more people moving away from Gmail than moving to Gmail.
nothrabannosir 8y ago
Very interesting: > JMAP is not designed around a persistent network socket, so it’s perfect for webmail clients that connect, do stuff, then disconnect This would allow implementing JMAP in serverless architecture, e.g. self hosting on AWS lambda. That should be very cheap and significantly lower the barrier to self hosting (not needing to manage a box, just providing aws credentials). Think of what it takes to truly decentralise email. There are technical hurdles, but also some fundamental ones: - other providers mark you as spam because you’re unknown - you need an always on server to actually get your incoming mail This would at least solve the second problem. If we can develop a product like mailinabox (Which has its flaws but it’s the right idea), but instead of asking for a fresh vm, it just asks for aws credentials, that could be pretty solid. Hopefully one day we can give the people back their control over their means of communication. This seems like a step in the right direction!
- elcomet 8y ago
  I'm not sure I understand: JMAP is designed for communication between the client and the mail server. But you still would need a mail server, always on, to receive the incoming mail from other servers, right ? Did I miss something about JMAP?
  - jasonmunro 8y ago
    Nope, you are exactly correct. JMAP is just a much more modern and efficient way to connect clients and servers to access E-mail.
- tjoff 8y ago
  Why? Mail is decentralized already. Part from relying on DNS. And you seem very eager to put everything in the amazon basket.
- jannes 8y ago
  If everyone hosts their email with Amazon it's gonna be quite centralised.
- pjc50 8y ago
ggm 8y ago
The main failure in mail standards is a lack of explicit utf8 clean support lhs@rhs -if this got fixed (it's often called universal acceptance) a lot of things about mail as an ecology would improve. I have view on the spam thing. The whole "your idea will not work because" meme is hugely destructive of innovation in email. It sucks energy and mindshare. It's classic old timer put down. What would (imnsho opinion) have fixed spam is sender pays. I've debated this with a lot of people. We're 50/50 on it. Fifty agree with me, fifty million don't. Jmap is utf8 clean btw. (I used to do email for a living in the eighties when life was simple and bang!chains!worked)
- m_mueller 8y ago
  How about a combination of sender-pays and a whitelist for everyone else? Essentially, have a web-standard for what linkedin is doing.
- efdee 8y ago
  If paying to send email is your suggested solution, I can see why you don't like the meme in question. But the suggestion is rife with problems. How exactly are you going to get everyone to start paying for email, which is free today? If it's a parallel system, how are you going to get people to switch? Who are they going to pay?
  - tonyedgecombe 8y ago
    If people received credit for incoming mail then the majority wouldn't get a bill as most people receive more than they send.
  - mathnmusic 8y ago
    > Who are they going to pay? The sender pays the reader. If the reader is the one deriving the value from this communication, they would pay the sender out of band as compensation.
    - detaro 8y ago
      So what does a reliable, not centralized payment system that is viable for this volume of tiny transactions that everyone can use look like? That's IMHO the big problem with all these suggestions.
billpg 8y ago
Last time I looked at IMAP, I was a little peeved that servers didn't accept messages added to the "Outbox" folder and send them, instead requiring that clients talk SMTP and then (or not) save a copy of the same message to the "Sent" folder. Could JMAP replace SMTP as well as IMAP?
- jasonmunro 8y ago
  JMAP actually does support replacing both. My next TODO item for Cypht is integrating SMTP support with JMAP.
  - Mailtemi 8y ago
    Just curious, did you build Cyrus yourself or there is beta server already?
    - jasonmunro 8y ago
      I checked out the git source and built it from there. It was non-trivial to get it built and configured properly for JMAP, but I wanted the latest as the spec is still in flux.
- akvadrako 8y ago
  Why do you think you need a new protocol for this? Instead what you want is a different IMAP server.
  - billpg 8y ago
    It has been a long time since I looked at IMAP. Are servers that do this now commonplace? (None I could find used to.) Can I know from a capability exchange if the remote server will send emails after adding to the "Outbox" folder?
    - amaccuish 8y ago
      No, not as far as I'm aware. But it's an idea I've also had. Upload the message to drafts, and then when you're ready to send, just move it to Outbox right?
deleted 8y ago
[deleted]
aorth 8y ago
Post is about JMAP (Fastmail's IMAP/SMTP replacement), by the author of a newish webmail client called Cypht that has just recently implemented support for JMAP. Cool! Keep going! https://cypht.org/ https://cypht.org/
bad_user 8y ago
FastMail is behind this protocol and from what I've read JMAP has evolved out of their web interface. I've been a happy customer, even though lately I flirted with going back to GSuite for my personal email, but after a trial realized that Gmail does many things well, except for being a good email service. So I went back to FastMail and renewed for another 2 years. Seeing this new protocol is exciting, because JMAP is being standardized at IETF. A breath of fresh air to see a new standard being developed. Also from what I understand JMAP should be friendly for mobile usage. They kept notifications out of it, you're supposed to implement notifications using whatever the mobile platform provides. Interacting via JMAP is via plain HTTP requests, which is super cool. I can totally see myself implementing a simple email client for automating online services. For example if you implement a commenting system for a website, you might want to do replies by email. That would be a cool project for me to try out. I wonder if FastMail exposes JMAP publicly yet. Haven't seen any mentions in their admin or docs thus far.
- Semaphor 8y ago
  > Also from what I understand JMAP should be friendly for mobile usage. I read the FM blogs and I remember them mentioning that low battery consumption was one of the design goals. The JMAP site [0] has: > JMAP is designed to make efficient use of limited network resources. Multiple API calls may be batched in a single request to the server, reducing round trips and improving battery life on mobile devices. [0]: https://jmap.io/spec-core.html https://jmap.io/spec-core.html
- eggsampler 8y ago
  I've been a happy Fastmail customer too, until I was made aware that you can impersonate other Fastmail customers by just spoofing the email address. Their servers just happily accept it. SPF and DKIM all pass with flying colours, and the only way you'd know it's happened is if you have DMARC on and happen to notice a pass in the report you don't remember sending. Well, that is if the recipient doesn't reply to the spoofed message - hope the damage wasn't already done though. It's effectively impossible for the recipient to know it's been spoofed. The worst part is I think Fastmail is aware of it and just don't care (believe that's why they mark their emails with a green tick and text). I understand that email has never been really authenticated, but this just throws any trust I had in Fastmail out the window. I will be evaluating other mail hosts at the end of my subscription.
mschuster91 8y ago
From experience, Exchange's Outlook API ("EWS") is pretty decent. It's XML-SOAP, sure, but there are libraries for it that can be readily used. The only thing they did fuck up is the three different kinds of IDs for an object (esp. confusing when accessing delegated team mailboxes/calendar events) but once you get it how it works, it's straightforward and allows you access to anything from email over calendar to address-book. I just do not know if EWS is an "open standard" that could be replicated by a third party server or if it is only "open documentation" and licensed for Exchange only :(
- amaccuish 8y ago
  I've sadly been looking for, and never found, an open source EWS <-> IMAP/(Cal/Card Dav) gateway. I'd love it if my users could get a full experience using Outlook for Mac for example. Right now I recommend them to just use Apple Mail/Calendar/Contacts or Thunderbird with the tb-sync extensions.
  - Karunamon 8y ago
    It sounds like you’re describing DAVMail
    - amaccuish 8y ago
      Wrong way. I want to offer EWS from my linux (not exchange) mail setup. Davmail consumes EWS and offers Cal/Card dav etc.
  - mschuster91 8y ago
    So you'd like for users to keep their familiar Outlook setup, but with a FOSS server backend? Not sure if this is possible, I don't know if Outlook uses the EWS protocol, OWA or something entirely different :/
    - amaccuish 8y ago
      Yupp. It works well with Windows Outlook, since they can use ActiveSync. But Mac Outlook doesn't have ActiveSync (or Card/Cal dav).
arendtio 8y ago
To give some context on why JMAP is relevant today, you might want to read this answer in the conversations FAQ [1]. It basically states that XMPP powered Apps are having trouble fighting against the battery saving software because XMPP is stateful. JMAP, on the other hand, is stateless. As protocols are meant to connect different implementations and bringing more protocols for the same task quickly hurts the interoperability (before bringing some improvements in the long-term), I am skeptical to the effects those new protocols bring to the ecosystem. I am aware that JMAP was born more out of the RESTful requirements of an HTTP based App, but in general, I am wondering where this road will lead us. [1]: https://github.com/siacs/Conversations#but-why-do-i-need-a-permanent-notification-if-i-use-google-push https://github.com/siacs/Conversations#but-why-do-i-need-a-p...
- Leace 8y ago
  Note that "RESTful" in JMAP's case means "everything over JSON HTTP POST", methods to be invoked are embedded in the JSON request. As for XMPP battery consumption I didn't see major problems, Conversations.im is always <1% (I just checked and it shows 0%). On the other hand Conversations can use push to optimize battery usage.
  - arendtio 8y ago
    Yes, in fact, there is absolutely no reason to restrict well-built apps like conversations from consuming battery automatically. Even without Google Push Notifications the battery consumption is quite good. So it is pretty obvious that the vendor built battery optimization software does more bad than good.
pedrocr 8y ago
>JMAP is a REST API so it uses HTTP requests and responses to issue commands and get the results. Almost all requests in JMAP are to the same URL using an HTTP POST to submit a JSON body of “methods”. Describing this as REST is really strange. Defining your own operations over an HTTP POST is what SOAP and other RPC style web services do and specifically what REST isn't. But I guess that a lack of a standard behind REST ended up with the term being used for everything.
- bradleyjg 8y ago
  At this point I guess any API that runs on top of HTTP is REST? Strange world.
  - mbel 8y ago
    I guess REST became catch phrase for all JSON over HTTP protocols.
  - u801e 8y ago
    I believe that one could make a REST API over other protocols like IMAP or NNTP.
- cruegge 8y ago
  They have an FAQ item concerning that: https://jmap.io/#why-is-it-not-rest-based https://jmap.io/#why-is-it-not-rest-based?
- mariusmg 8y ago
  Maybe unpopular opinion, but i'd take this any day over a "proper" REST api requiring DELETE and PUT. Also i'd classify a REST api as anything that does http requests and consumes proper JSON. As long as this is true , the rest is squabbling :)
  - naasking 8y ago
    > i'd take this any day over a "proper" REST api requiring DELETE and PUT. REST doesn't need to use any HTTP verbs other than GET and POST.
zAy0LfpBZLC8mAC 8y ago
> JMAP is not designed around a persistent network socket, so it’s perfect for webmail clients that connect, do stuff, then disconnect (which is exactly NOT how IMAP is supposed to be used) WTF? So, webmail was limited by the fact that it was running in a browser and thus had to use HTTP, which has semantics that don't really fit the needs of an email access protocol. Now, we do have stuff like websockets that would make it possible to run a protocol from the webmail client that actually fits the needs, and instead people invent a new protocol that inherently doesn't match the needs of the application?
- majewsky 8y ago
  Most mail clients are running on mobile (judging by number of devices). Long-running connections on mobile are a bad idea because of network reliability and battery concerns.
  - zAy0LfpBZLC8mAC 8y ago
    Hu? Constantly establishing new connections saves power vs. maintaining one estalished connection? Could you explain how that works? And could you also explain how constantly making new connections makes things work more reliably over unreliable links? Like, does that allow you to transfer data when the network link is down? Does the fact that inside the TLS/TCP connection data is transferred via HTTP instead of IMAP somehow make the TCP connection work better over lossy links? It would seem to me like the exact opposite should be the case, if it has any effect at all?
    - amaranth 8y ago
      > Constantly establishing new connections saves power vs. maintaining one estalished connection? Could you explain how that works? If you maintain a connection you have a leave the modem powered. If you connect every so often (1 minute, 10 minutes, whatever) the modem can be powered down in between. The modem and the screen are the top two users of power in a phone so this is a big win.
bobm_kite9 8y ago
Loved this bit: > Internet: Do you think JMAP will really take off? > Me: JMAP is an open, smart, modern, and powerful E-mail protocol, so probably not.
shittyadmin 8y ago
So, you say that it doesn't maintain a persistent connection, but that poses a problem - it needs a way to do push notifications still I assume? Those need an open socket somewhere - does JMAP allow for it or does it make you rely on a 3rd party?
- Mailtemi 8y ago
  If you are mention Ios/Android, yes you need the proxy to redirect push calls from JMAP server to the push services of apple/google.
  - shittyadmin 8y ago
    That sucks, I'd like to involve as few parties as possible in my emails. Right now I just have a direct IMAP connection that it can push over even on mobile. What about for desktop purposes? What would a proper client like Thunderbird or Outlook do?
  - inputmice 8y ago
    FWIW this is completely reasonable. Push in XMPP works the same way. They way FCM (Google) and APNS (Apple) work is that only the app vendor with proper credentials can trigger push notification for an app. Therefor it has to be proxied through the app developers server anyway. And of course it cleanly separates the MDA from the various, proprietary push solutions.
mverwijs 8y ago
I've started to migrate 18 years of email history to Fastmail, after running my own mail infra for almost 2 decades. I am not impressed. Folders moved in the webinterface show up unmoved in Thunderbird. And vice versa. Sometimes it works, sometimes it doesn't. They're investigating the problem at the moment, but the updates they've given me don't give me much hope. I'm looking at migrating away to another provider that just does plain old imap.
youdontknowtho 8y ago
IMAP is just a way for attackers to perform credential spray's against large providers these days.

325 points by jasonmunro 8y ago

andridk 8y ago

I was really hoping for a GraphQL API standard for mail before reading this. But this sounds good too.

thomasfoster96 8y ago
Reading through the JMAP website [0], I'm actually wondering whether whoever's behind JMAP has looked at GraphQL. There seem to be a lot of similarities (especially the "why not REST" section). [0] https://jmap.io/index.html https://jmap.io/index.html
- ForHackernews 8y ago
  I think Fastmail are the primary ones behind JMAP: https://fastmail.blog/2014/12/23/jmap-a-better-way-to-email/ https://fastmail.blog/2014/12/23/jmap-a-better-way-to-email/
  - jasonmunro 8y ago
    Yep. Also I think they are using it for a subset of customers. While JMAP support in Cypht is still new, so far it's working just like IMAP, but my testing is limited since I just wrote the integration :)
- detaro 8y ago
  Work on JMAP likely started before GraphQL was publicly released.
Mailtemi 8y ago
Actually, Outlook GraphQL reusing the idea of batch JMAP calls. https://docs.microsoft.com/en-us/previous-versions/office/office-365-api/api/beta/batch-outlook-rest-requests-beta https://docs.microsoft.com/en-us/previous-versions/office/of...
chrismorgan 8y ago
Understand that JMAP is an object synchronisation protocol. It’s most interested in the problems that are out of scope for GraphQL. You could have a variant of JMAP with GraphQL syntax and semantics, but there would be a fair bit of mismatch, for their purposes and focuses are quite different: JMAP is concerned with object identity and synchronisation, for what you might call thick clients (and JMAP Mail needs to be broadly IMAP compatible), while GraphQL is UI-focused, for what might reasonably be considered to be thin clients (not that they are logicless, but that they are very much focused on offloading burden to the server). I see no compelling case for a JMAP-like GraphQL thing. It could still be an interesting task to develop a object synchronisation protocol like the JMAP core on top of GraphQL.

hardwaresofton 8y ago

I really want to see some innovation in the email space. The landscape is like a sea of false promises and dashed dreams. SMTP is one of the bread-and-butters of the internet, yet it just doesn't seem to be moving forward (maybe that's for the best), and no one's building extensions on top of it. Maybe I'm naive in thinking it was possible but we could have avoided this whole "make an account on X messenger so we can talk", if someone had just jammed XMPP and SMTP together. Every few years I'm tempted to try and write a SMTP server (MX) myself but then realize that postfix has been around so long and is the go to choice for a reason. I don't have 20 years of figuring out how X mail server interprets SMTP to be as reliable as postfix. I settled for trying to wrap it[0]. [0]: https://gitlab.com/postmgr/postmgr https://gitlab.com/postmgr/postmgr

amanzi 8y ago
"if someone had just jammed XMPP and SMTP together" - wasn't that kind of what Google Wave was aiming for?
- lucideer 8y ago
  Yes. And the vision for Google Wave was great. The execution was just abominably bad (primarily on the frontend/UI side), and Google's failures in execution carried over reputationally to the—now dead—Apache incubator.
  - vidarh 8y ago
    Not just the UI side. The underlying protocol was also pointlessly over-engineered. SMTP is still around because it is simple. You can get a basic SMTP client running in an hour or two. You can get a basic server running in a similar amount of time, at least in a higher level language. That matters, not because anyone will have anything usable in that time, but because it lets you start to experiment very, very easily. Wave suffered from a UI that was a mess layered on top of a protocol that made it really hard for people to get started on experimenting with alternative frontends, and without a user-base giving people a reason to persist figuring out how to interoperate with it. Had the protocol been simpler, the UI mess might not have mattered so much - people might have come up with their own ideas.

akie 8y ago

The article mentions that JMAP does calendars as well. Anyone have a quick status update on how it compares to CalDav and if it's supported by any of the major calendar clients or servers? I did a quick google and looked at the JMAP site but couldn't find any info. Background for this is that I implemented a calendar client and a calendar server (with SabreDAV) last year and I'm wondering if I should be adding support for JMAP anytime soon.

sigsergv 8y ago
Current state of calendaring is horrible, it's basically not possible right now to create compatible and reliable library/application.
- tinus_hn 8y ago
  Calendaring truly is surprisingly difficult. Dates and times just are not defined with computers in mind.
  - sigsergv 8y ago
    Yep, they are extremely difficult. Timezones, group events, repeatable events. RFCs describing calendaring are very vague and miss a lot of important details. And exchange/outlook implementation adds a huge pile of incompatibility. When I was working on calendaring project I've found lots of ways to create broken events in google calendar for example. They are completely valid according to RFC but absolutely not usable in apps. Also there are working groups that STILL developing calendaring RFCs, they create tons of esoteric and cryptic documents every year. P.S. When I write “RFC” I mean any well established standard.
nmjenkins 8y ago
Editor of the JMAP specs here. The JMAP calendar spec is currently just a draft, but now JMAP core and mail are (more or less) finalised and JSCalendar (https://tools.ietf.org/html/draft-ietf-calext-jscalendar-11 https://tools.ietf.org/html/draft-ietf-calext-jscalendar-11) is in last call too, we will be looking to take the JMAP Calendar spec through the IETF process in the very near future. Since it is essentially just combing core with the JSCalendar data format, this should be reasonably straight forward.

busfahrer 8y ago

I recently thought about email being based on such an old standard and then I wondered if maybe it didn't matter anymore, because most of the web is moving to gmail, and my guess is (and somebody please correct me) that when I send an email from gmail to gmail, that no actual SMTP is involved? I'm assuming that they have some internal protocol that is just adapter'd to "Email" at the very end?

beagle3 8y ago
It fakes it, at the very least - you can do a “show original message” and see all the RFC.822 and mine headers. Microsoft Exchange used to not bother with actually SMTPing when talking to another exchange server (or itself), I don’t know what it does these days.
pjc50 8y ago
> most of the web is moving to gmail This isn't true; there's a LOT of industry on Exchange of some sort, and plenty of older institutions running their own email. Especially in IETF land. And it's a huge risk increase if everyone moves everything to gmail.
mattnewport 8y ago
I hear of a lot more people moving away from Gmail than moving to Gmail.

nothrabannosir 8y ago

Very interesting: > JMAP is not designed around a persistent network socket, so it’s perfect for webmail clients that connect, do stuff, then disconnect This would allow implementing JMAP in serverless architecture, e.g. self hosting on AWS lambda. That should be very cheap and significantly lower the barrier to self hosting (not needing to manage a box, just providing aws credentials). Think of what it takes to truly decentralise email. There are technical hurdles, but also some fundamental ones: - other providers mark you as spam because you’re unknown - you need an always on server to actually get your incoming mail This would at least solve the second problem. If we can develop a product like mailinabox (Which has its flaws but it’s the right idea), but instead of asking for a fresh vm, it just asks for aws credentials, that could be pretty solid. Hopefully one day we can give the people back their control over their means of communication. This seems like a step in the right direction!

elcomet 8y ago
I'm not sure I understand: JMAP is designed for communication between the client and the mail server. But you still would need a mail server, always on, to receive the incoming mail from other servers, right ? Did I miss something about JMAP?
- jasonmunro 8y ago
  Nope, you are exactly correct. JMAP is just a much more modern and efficient way to connect clients and servers to access E-mail.
tjoff 8y ago
Why? Mail is decentralized already. Part from relying on DNS. And you seem very eager to put everything in the amazon basket.
jannes 8y ago
If everyone hosts their email with Amazon it's gonna be quite centralised.
pjc50 8y ago

ggm 8y ago

The main failure in mail standards is a lack of explicit utf8 clean support lhs@rhs -if this got fixed (it's often called universal acceptance) a lot of things about mail as an ecology would improve. I have view on the spam thing. The whole "your idea will not work because" meme is hugely destructive of innovation in email. It sucks energy and mindshare. It's classic old timer put down. What would (imnsho opinion) have fixed spam is sender pays. I've debated this with a lot of people. We're 50/50 on it. Fifty agree with me, fifty million don't. Jmap is utf8 clean btw. (I used to do email for a living in the eighties when life was simple and bang!chains!worked)

m_mueller 8y ago
How about a combination of sender-pays and a whitelist for everyone else? Essentially, have a web-standard for what linkedin is doing.
efdee 8y ago
If paying to send email is your suggested solution, I can see why you don't like the meme in question. But the suggestion is rife with problems. How exactly are you going to get everyone to start paying for email, which is free today? If it's a parallel system, how are you going to get people to switch? Who are they going to pay?
- tonyedgecombe 8y ago
  If people received credit for incoming mail then the majority wouldn't get a bill as most people receive more than they send.
- mathnmusic 8y ago
  > Who are they going to pay? The sender pays the reader. If the reader is the one deriving the value from this communication, they would pay the sender out of band as compensation.
  - detaro 8y ago
    So what does a reliable, not centralized payment system that is viable for this volume of tiny transactions that everyone can use look like? That's IMHO the big problem with all these suggestions.

billpg 8y ago

Last time I looked at IMAP, I was a little peeved that servers didn't accept messages added to the "Outbox" folder and send them, instead requiring that clients talk SMTP and then (or not) save a copy of the same message to the "Sent" folder. Could JMAP replace SMTP as well as IMAP?

jasonmunro 8y ago
JMAP actually does support replacing both. My next TODO item for Cypht is integrating SMTP support with JMAP.
- Mailtemi 8y ago
  Just curious, did you build Cyrus yourself or there is beta server already?
  - jasonmunro 8y ago
    I checked out the git source and built it from there. It was non-trivial to get it built and configured properly for JMAP, but I wanted the latest as the spec is still in flux.
akvadrako 8y ago
Why do you think you need a new protocol for this? Instead what you want is a different IMAP server.
- billpg 8y ago
  It has been a long time since I looked at IMAP. Are servers that do this now commonplace? (None I could find used to.) Can I know from a capability exchange if the remote server will send emails after adding to the "Outbox" folder?
  - amaccuish 8y ago
    No, not as far as I'm aware. But it's an idea I've also had. Upload the message to drafts, and then when you're ready to send, just move it to Outbox right?

deleted 8y ago

[deleted]

aorth 8y ago

Post is about JMAP (Fastmail's IMAP/SMTP replacement), by the author of a newish webmail client called Cypht that has just recently implemented support for JMAP. Cool! Keep going! https://cypht.org/ https://cypht.org/

bad_user 8y ago

FastMail is behind this protocol and from what I've read JMAP has evolved out of their web interface. I've been a happy customer, even though lately I flirted with going back to GSuite for my personal email, but after a trial realized that Gmail does many things well, except for being a good email service. So I went back to FastMail and renewed for another 2 years. Seeing this new protocol is exciting, because JMAP is being standardized at IETF. A breath of fresh air to see a new standard being developed. Also from what I understand JMAP should be friendly for mobile usage. They kept notifications out of it, you're supposed to implement notifications using whatever the mobile platform provides. Interacting via JMAP is via plain HTTP requests, which is super cool. I can totally see myself implementing a simple email client for automating online services. For example if you implement a commenting system for a website, you might want to do replies by email. That would be a cool project for me to try out. I wonder if FastMail exposes JMAP publicly yet. Haven't seen any mentions in their admin or docs thus far.

Semaphor 8y ago
> Also from what I understand JMAP should be friendly for mobile usage. I read the FM blogs and I remember them mentioning that low battery consumption was one of the design goals. The JMAP site [0] has: > JMAP is designed to make efficient use of limited network resources. Multiple API calls may be batched in a single request to the server, reducing round trips and improving battery life on mobile devices. [0]: https://jmap.io/spec-core.html https://jmap.io/spec-core.html
eggsampler 8y ago
I've been a happy Fastmail customer too, until I was made aware that you can impersonate other Fastmail customers by just spoofing the email address. Their servers just happily accept it. SPF and DKIM all pass with flying colours, and the only way you'd know it's happened is if you have DMARC on and happen to notice a pass in the report you don't remember sending. Well, that is if the recipient doesn't reply to the spoofed message - hope the damage wasn't already done though. It's effectively impossible for the recipient to know it's been spoofed. The worst part is I think Fastmail is aware of it and just don't care (believe that's why they mark their emails with a green tick and text). I understand that email has never been really authenticated, but this just throws any trust I had in Fastmail out the window. I will be evaluating other mail hosts at the end of my subscription.

mschuster91 8y ago

From experience, Exchange's Outlook API ("EWS") is pretty decent. It's XML-SOAP, sure, but there are libraries for it that can be readily used. The only thing they did fuck up is the three different kinds of IDs for an object (esp. confusing when accessing delegated team mailboxes/calendar events) but once you get it how it works, it's straightforward and allows you access to anything from email over calendar to address-book. I just do not know if EWS is an "open standard" that could be replicated by a third party server or if it is only "open documentation" and licensed for Exchange only :(

amaccuish 8y ago
I've sadly been looking for, and never found, an open source EWS <-> IMAP/(Cal/Card Dav) gateway. I'd love it if my users could get a full experience using Outlook for Mac for example. Right now I recommend them to just use Apple Mail/Calendar/Contacts or Thunderbird with the tb-sync extensions.
- Karunamon 8y ago
  It sounds like you’re describing DAVMail
  - amaccuish 8y ago
    Wrong way. I want to offer EWS from my linux (not exchange) mail setup. Davmail consumes EWS and offers Cal/Card dav etc.
- mschuster91 8y ago
  So you'd like for users to keep their familiar Outlook setup, but with a FOSS server backend? Not sure if this is possible, I don't know if Outlook uses the EWS protocol, OWA or something entirely different :/
  - amaccuish 8y ago
    Yupp. It works well with Windows Outlook, since they can use ActiveSync. But Mac Outlook doesn't have ActiveSync (or Card/Cal dav).

arendtio 8y ago

To give some context on why JMAP is relevant today, you might want to read this answer in the conversations FAQ [1]. It basically states that XMPP powered Apps are having trouble fighting against the battery saving software because XMPP is stateful. JMAP, on the other hand, is stateless. As protocols are meant to connect different implementations and bringing more protocols for the same task quickly hurts the interoperability (before bringing some improvements in the long-term), I am skeptical to the effects those new protocols bring to the ecosystem. I am aware that JMAP was born more out of the RESTful requirements of an HTTP based App, but in general, I am wondering where this road will lead us. [1]: https://github.com/siacs/Conversations#but-why-do-i-need-a-permanent-notification-if-i-use-google-push https://github.com/siacs/Conversations#but-why-do-i-need-a-p...

Leace 8y ago
Note that "RESTful" in JMAP's case means "everything over JSON HTTP POST", methods to be invoked are embedded in the JSON request. As for XMPP battery consumption I didn't see major problems, Conversations.im is always <1% (I just checked and it shows 0%). On the other hand Conversations can use push to optimize battery usage.
- arendtio 8y ago
  Yes, in fact, there is absolutely no reason to restrict well-built apps like conversations from consuming battery automatically. Even without Google Push Notifications the battery consumption is quite good. So it is pretty obvious that the vendor built battery optimization software does more bad than good.

pedrocr 8y ago

>JMAP is a REST API so it uses HTTP requests and responses to issue commands and get the results. Almost all requests in JMAP are to the same URL using an HTTP POST to submit a JSON body of “methods”. Describing this as REST is really strange. Defining your own operations over an HTTP POST is what SOAP and other RPC style web services do and specifically what REST isn't. But I guess that a lack of a standard behind REST ended up with the term being used for everything.

bradleyjg 8y ago
At this point I guess any API that runs on top of HTTP is REST? Strange world.
- mbel 8y ago
  I guess REST became catch phrase for all JSON over HTTP protocols.
- u801e 8y ago
  I believe that one could make a REST API over other protocols like IMAP or NNTP.
cruegge 8y ago
They have an FAQ item concerning that: https://jmap.io/#why-is-it-not-rest-based https://jmap.io/#why-is-it-not-rest-based?
mariusmg 8y ago
Maybe unpopular opinion, but i'd take this any day over a "proper" REST api requiring DELETE and PUT. Also i'd classify a REST api as anything that does http requests and consumes proper JSON. As long as this is true , the rest is squabbling :)
- naasking 8y ago
  > i'd take this any day over a "proper" REST api requiring DELETE and PUT. REST doesn't need to use any HTTP verbs other than GET and POST.

zAy0LfpBZLC8mAC 8y ago

> JMAP is not designed around a persistent network socket, so it’s perfect for webmail clients that connect, do stuff, then disconnect (which is exactly NOT how IMAP is supposed to be used) WTF? So, webmail was limited by the fact that it was running in a browser and thus had to use HTTP, which has semantics that don't really fit the needs of an email access protocol. Now, we do have stuff like websockets that would make it possible to run a protocol from the webmail client that actually fits the needs, and instead people invent a new protocol that inherently doesn't match the needs of the application?

majewsky 8y ago
Most mail clients are running on mobile (judging by number of devices). Long-running connections on mobile are a bad idea because of network reliability and battery concerns.
- zAy0LfpBZLC8mAC 8y ago
  Hu? Constantly establishing new connections saves power vs. maintaining one estalished connection? Could you explain how that works? And could you also explain how constantly making new connections makes things work more reliably over unreliable links? Like, does that allow you to transfer data when the network link is down? Does the fact that inside the TLS/TCP connection data is transferred via HTTP instead of IMAP somehow make the TCP connection work better over lossy links? It would seem to me like the exact opposite should be the case, if it has any effect at all?
  - amaranth 8y ago
    > Constantly establishing new connections saves power vs. maintaining one estalished connection? Could you explain how that works? If you maintain a connection you have a leave the modem powered. If you connect every so often (1 minute, 10 minutes, whatever) the modem can be powered down in between. The modem and the screen are the top two users of power in a phone so this is a big win.

bobm_kite9 8y ago

Loved this bit: > Internet: Do you think JMAP will really take off? > Me: JMAP is an open, smart, modern, and powerful E-mail protocol, so probably not.

shittyadmin 8y ago

So, you say that it doesn't maintain a persistent connection, but that poses a problem - it needs a way to do push notifications still I assume? Those need an open socket somewhere - does JMAP allow for it or does it make you rely on a 3rd party?

Mailtemi 8y ago
If you are mention Ios/Android, yes you need the proxy to redirect push calls from JMAP server to the push services of apple/google.
- shittyadmin 8y ago
  That sucks, I'd like to involve as few parties as possible in my emails. Right now I just have a direct IMAP connection that it can push over even on mobile. What about for desktop purposes? What would a proper client like Thunderbird or Outlook do?
- inputmice 8y ago
  FWIW this is completely reasonable. Push in XMPP works the same way. They way FCM (Google) and APNS (Apple) work is that only the app vendor with proper credentials can trigger push notification for an app. Therefor it has to be proxied through the app developers server anyway. And of course it cleanly separates the MDA from the various, proprietary push solutions.

mverwijs 8y ago

I've started to migrate 18 years of email history to Fastmail, after running my own mail infra for almost 2 decades. I am not impressed. Folders moved in the webinterface show up unmoved in Thunderbird. And vice versa. Sometimes it works, sometimes it doesn't. They're investigating the problem at the moment, but the updates they've given me don't give me much hope. I'm looking at migrating away to another provider that just does plain old imap.

youdontknowtho 8y ago

IMAP is just a way for attackers to perform credential spray's against large providers these days.