JMAP – a modern email open standard
jmap.io
jmap.io
Our own Madeline Hanley wrote about that experience, if you'd like to see what it's like to work with JMAP: https://blog.1password.com/making-masked-email-with-jmap/
Last time we did something like that new email address was just "add entry to a Dovecot database", fully protocol agnostic
It would be really nice if adding a masked email automatically created a "sending identity." Further, it would be nice if the masked email account had a nickname that included the domain I was on when I created the account. That way if I need to send an email to support@nike.com, I can use the filter and type "nike.com" and get the correct masked email address.
It does.
Just click "... Show all" when choosing a sender, and that will expand the list/search to include masked emails. It should also show you the domain/service it was set up for. And as you noted, the masked email will automatically be used as the sender when replying to an email that was sent to it as well.
Using 1Password makes it super easy to see which masked email was used for each service, so I can't really relate to your frustrations there either.
I think it's a pretty polished experience, and definitely beats everything else I've used in the past.
Only sort of. First, this is a new feature, there used to be a whole section on adding "sending identities" and describing how to do it in order to send from a masked email address. I have support emails from 1Password pointing me to those docs as well. That whole section has been removed and now there's a note in the docs saying why (no date, though, so I don't know how recent).
Second, your description glosses over the fact that if I click the "from" address dropdown, and then in the filter/search field, type the domain associated with the masked email address, nothing shows up except "Show All." Why wouldn't a filter/search find the address? I have to click "Show All" and then repeat the search.
However, if I search/filter for any of the dozens of "sending identities" I created previously, the search/filter works correctly. So the UI is completely broken. When I search/filter something, and nothing shows up except a "Show All" button, that's the UI telling me that there were no matches. Oh, but now I learn that there are matches, they're just hidden under "Show All" (which should be renamed to "show matching masked email addresses" or something!?).
What's missing? The old experience definitely sounds pretty frustrating.
Personally, I really like that masked emails are hidden by default. I've got 20 "real" sending identities, so when I'm searching I want a quick selection that doesn't include dozens of masked results. The amount of times I start a new email thread with a masked email would probably be a small handful of times per year.
Edit:
> I have to click "Show All" and then repeat the search.
Maybe that's a bug you can report for your browser? I don't need to retype anything and just hit enter when I get no results, then it expands the results to include masked items.
This still exists, by the way. They moved it to Settings => Migration => Import => Add alumni email forwarding address or non-SMTP sending identity, which makes absolutely no sense to me.
This has been one of my biggest peeves about the WWW since 1993. Please include publication and/or change dates and/or include a changelog on your pages. Do not force your users to resort to reading metadata, the URL path, the Wayback Machine, or dark magic to figure out when and what changed. Diff is a solved problem; why can't I diff a generic web page?
Email me at my well known identity "whoever@whatever.com" -> my provider gives you a key that you must store and continue to use for the duration of our relationship. I can terminate it if I want. If you lose the key, you must ask for a new one. If you ask too many times, I can silence you forever. You'll have to provide your own identity when asking.
For noisy environments, I can choose to give you the key upfront and only allow for that style of relationship.
I could imagine encoding the concept of entity or organization type into the keys as well so that we can distinguish individuals from companies. Professionals, academics, official employees, etc.
If you delegate your key to another party, I can choose to pre-authorize it, manually approve it, or outright deny it. Extend it haphazardly or without my consent and you may be blocked.
I'd like that type of system.
Emails shouldn't have to change. The protocol should. Getting parties onboard might be hard unless a key stakeholder (eg. Google) decides to implement this, but they're in a position to unilaterally dictate.
So I don’t really see it as better. I see it as pie-in-the-sky fan-fiction to address part of what masked emails aims to address. A significant portion of the time that I used masked email, it’s in service of increasing anonymity (to the organisation i am giving the email address to), not an anti-spam measure.
The only part I'm not quite sure how to do seamlessly is the initial exchange. You sign up with your email at a new website, and need to also give them the unique key that allows them to correspond with you. This would require browser support, and a standardized protocol for letting the browser request a new key from your email provider. Also means your browser would need your email credentials (well, an OAuth grant, more likely). And the problem here is that, until all browsers (or whatever) support it, you'd have to run the system in a default-allow state.
Another option for the initial per-contact setup is a sort of trust-on-first-use kind of thing. First email from a new recipient is allowed through, but at that point your email client will ask if you want further emails to be allowed (and if you do, it'll send the key to the sender behind the scenes). Problem there is that spammers could just burn through new email addresses to keep contacting you.
Anyway, I'm sure there are solutions to these problems, even if I can't think of them in the 12 seconds I've allowed myself to do so. I expect this would be something that would remain disabled for a while, until all the infrastructure and client support is in place.
Besides, this already exists anyway, it's basically:
brong+secretkey@fastmail.com
Or if you have fastmail style subaddressing:
secretkey@brong.fastmail.com
I don't think changes are hard to push forward. Soon every website will require SSL. Tech giants can move the needle on adoption of new standards.
Wanting to stay in contact with your customer is a pretty big forcing function for adoption.
This has been a very gradual change. The earliest announcement I can find is from 2018[1] but I'm pretty sure it was in the works long before. That's more than five years to implement a technology that browsers and servers at the time already had known how to do for a decade or more.
Massively coordinated change is _hard_.
[1]: https://blog.chromium.org/2018/02/a-secure-web-is-here-to-st...
If you did want to surface it, the controls could be as simple as "block sender", "opt out of 3rd party contacts", "sender X wants you to connect with sender Y - allow?", etc. Very coarse grained, very easy and intuitive.
Not anymore, they've made it much simpler for you now by combining "aliases" and "sending identities" into "my email addresses". If you thought it was confusing before when you had to click "create new" under "sender identities" in settings, now all you need to do is:
1. Head to Settings → Migration → Import page.
2. Click on Add external sending address (SMTP) without importing emails.
3. Enter the email address and click Next.
4. On the following screen, skip the password prompt and click on Manually configure.
5. Disable the option - User authenticated SMTP when sending.
6. Save the changes.
And just like that you can start sending emails with your new address, easy peasy.
A "Sender identity" should just be a different From: mail header; it shouldn't involve disabling SMTP authentication. The SMTP envelope address and authentication are unaffected.
Later: "first-party and third-party cookies are used on: 1password.com (...)
Stating that you need consent and not asking for it is extremely weird.
> First-party cookies are set by 1Password. They help calculate things like page views and visitors to the website. Third-party cookies are set by 1Password affiliates for commission and advertising purposes.
https://1password.com/legal/cookies/
They make it clear that they know consent is required, that they absolutely fall into that category, and then don't ask.
Is any company compliant?!
(I'm being facetious... my company is compliant or at least I think it is - not a lawyer... but it's very rare)
https://www.kylheku.com/cgit/tamarind/
This is a CGI-scripted web application without any kind of web framework, in an original programming language.
It authenticates you using IMAP or SASL: with direct socket work in a few lines of code. (That's the only integration with IMAP.)
It manages aliases in a standard aliases file. If configured, it can work with the master /etc/aliases file, in which cases it will carve out a section of the file for itself and respect the surrounding file when it adds or removes aliases. I run a separate aliases file, though.
In connection with the throw-away mail aliases, the issue that comes up is that when you use them for sending, rather than just receiving mails, you want that to be available in the list of sender identities in the mail client.
While it isn't automatic, I put in a hack which at least makes it easier to identify the mail identities. In RoundCube, a mail identity has an "Organization" field: what org you belong to. There is a mail header for that, IIRC.
I changed the UI so that when you look at the identities list box, the Organization field is listed in parentheses (if it is non-blank). Then I use Organization to describe the purpose of the mail alias, e.g "Foo Mailing List" or "ABC Company".
Only a small subset of my throw-away mail aliases become sender identities; I do that manually.
Plus there are some other benefits.
Each one is associated with note field. URLs in the note field are rendered navigable. I use the note fields not only as a reminder about what the alias is for but also for PW management. Throwaway mail aliases often have throwaway passwords associated with them too.
The explicitly created aliases track their creation date, which can be informative from time to time.
UI has a regex search over the aliases (any field).
They are the company largely behind this, check them out.
(I'm not affiliated in any way to them)
[0]: https://www.fastmail.com/blog/fastmail-snooze/
Edit: If you want your work emails to arrive only during work hours and otherwise delay them, you can use a Sieve condition in your email rule similar to this:
anyof (date :value "lt" "date" "hour" "09", date :value "ge" "date" "hour" "17")You're still using gmail's spam checking; it just uses the API (or IMAP? I forgot) to sync the emails to FastMail.
LOL
It’s like stepping back in time 20 years when soamassassin with default config is as good as it gets.
At the same time I really never have to check my spam folder for false positive, everything in there is literal spam so I forget checking it for weeks on end. Whereas on n Gmail I always need to check the spam folder, Google completely overdoes the filtering it and a lot of wanted emails end up in spam.
Before that, I used Gmail (on the same address, for about six years), and my memory is that its false positive rates were around one every month or two, and some of them actually mattered; and its false negative rates varied: sometimes it’d go for a few months with none, then it might let through one or two per day for a few weeks. Certainly less consistent. In the last year I’ve also had to use Gmail via a couple of organisations on addresses with very low volume (less than one per day) which have never received any spam, and both have had at least two false positives.
1. The bayesian filter updates only when you actually delete emails from the Spam folder.
2. There is a global and a personal spam filter. The personal one kicks in after 200 spam emails have been ingested/deleted. You need to break it in, like a pair of leather shoes.
3. Before this 200 email threshold, make use of automated rules to just mark stuff as Spam automatically, if like me, they have all a similar pattern. When your personal filter kicks in, you're golden and works as expected.
I don't have any spam issue anymore and I don't think I've ever seen a false positive either. So now it's smooth sailing.
I wish Fastmail documented this process, which was explained to me by their support after a dozen exchanges.
Funny aside: all the spam overwhelmingly comes from gmail.com accounts. Seems like Google needs to work on their terrible outgoing spam issue. They're the biggest spam sender now that no one runs open mail servers on the Internet anymore.
Report it to google, and make the world a better place.
But, first check the first received header that was added by your mail provider's servers to make sure the spam really is coming from gmail's servers-- oldest received headers are at the bottom, newer as you go up (e.g., view message source, view headers, or some such option in your client; look for received: from...).
Add a short blurb at the top of your message about spam received from their domain, include the message with full headers as text at the end of the email message body (some clients like MS outlook break mail, so this may be the only way the recipient will be able to view the headers if the sender is using one of these broken clients. Also attach the original spam message as an attachment (this will provide something useful to the recipient when sent by most ?all? non-Microsoft mail clients).
Send it to abuse@gmail.com
Report the stuff your spam filter catches too.
At past jobs, we took these reports very seriously. They were usually an indication that a user's account was compromised.
> Report it to google, and make the world a better place.
That's line is not gonna work on me. Google is a trillion dollar company that only cares about its bottom line, not a public good. They can sort it out themselves.
I have better things to do with my time than do Google spam team's job for free by reporting each spam email I receive manually.
I've had good responses from most places. An Eastern European domain registrar has revoked several scammer domains after my notifications. Some ISPs are a waste of time to send reports to, e.g., a few in E. Europe, and Colo Crossing. But, it is usually worth it to report abuse. I have an emeritus email address from a former employer where I made it my project since the pandemic to report all spam/scam mail received to that address. I cannot state that this is the reason nor even the main reason, but the volume of spam to that address has gone from a firehose to a single spam/scam message every 1-3 weeks.
Are you kidding? The Goo has never paid any attention to the victims of spam emanating from gmail accounts.
> Note: We recommend that you do not mark your Spam/Junk Mail folder to automatically learn as spam. This can create a false positive feedback loop. Imagine an email is incorrectly classified as spam, put in your Spam/Junk Mail folder, and then learned as spam. That means future emails that aren't spam are now more likely to be incorrectly marked as spam, sent to your Spam/Junk Mail folder, and learned as spam. Only mark folders to learn as spam if they're folders you manually move email to.
On the other end of things, GMail and Fastmail both miss about the same amount of spam that ends up in my inbox. Not a lot, maybe once or twice a week.
I wonder what it is about the emails you receive (vs. the emails I receive) that makes us see such different outcomes.
I contacted support and the just said "yup, those emails were suspicious and were correctly rejected." Err, no. If I'm the customer and day I want to receive an email you shouldn't be rejecting it.
I likely wouldn't have noticed if I didn't run a service that was emailing me. But after that I noticed other senders also being blocked. Adding to my address book also didn't work, I guess that whitelist runs after the accept/reflect decision.
It's a huge PITA when you're offline (say in a venue with no cover) and need to pull a ticket out of your inbox.
I'm a customer and can't believe they've been in business for so long. I guess this feature will never come.
I've been using Google Apps for email for 10+ years and I don't want my e-mail provider to die at the whim of some Sand Hill investor's emotions at a bay area house party.
that history does not assign to me confidence in them as custodian of my emails
I'd recommend trying them out for a bit and just keeping Gmail in your back pocket. May as well decide for yourself than listening to randoms on HN.
I'd rather entrust my mail service to someone who wants to keep running it strongly enough that they'll put their own money down to keep doing it.
The alternatives are mostly investor-owned companies - if this years CEO decides to fuck you over, they can replace any staff who object.
We're entirely funded by our customers, and fully self-bootstrapped. We have no debts to outside parties.
We have 8 owners, 7 of which work in the business and the 8th is the brother of one of the founders (and only owns a couple of percent).
Source: I'm CEO. Have worked here since 2004, through the Opera acquisition (I moved to Norway for nearly 2 years) and back. We've controlled our growth such that we keep our spending under our income - I know, what a shocking idea in current day!
I need a custom domain (or three). And I have a family of 6 people.
So that's $5 / user / month = $30 / month = $360 / year.
Unfortunately, that's not justifiable for me. And thus why I'm stuck using Gmail with a custom domain.
I've been using this for a year or so and my family's been happy with it.
I don't think you'd need any Apple gear at all to use it, but make no promises.
So I guess this is tied up then.
The custom email domain is a side feature... but it does work well, and it's essentially free (assuming you want your photos properly backed up... and who doesn't).
I'm not sure if that help article is accurate though - I would think you can subscribe to iCloud+ from their website. You have to go to the website to manage your email domains for example.
You pay for mailbox size and number of emails in/out. Can add as many domains/users as you like.
I use the micro tier ($20 a year), it's more than enough for me.
Recently compared Google, Office 365, Proton, Tutanota, Skiff, and Zoho. Surprisingly ended up with Zoho. Actually a decent experience so far, they've definitely upgraded their stack for the better from what I remember it was a decade ago.
Google Workspaces is $6 / user / month.
I presume you were grandfathered for free from personal G Suite, but for the rest of us fastmail is actually less expensive than google's offering (though google also gives you Drive space and whatnot).
Then I realized the alternatives (including letting everyone in the family decide their own email solution) were worse.
But honestly, I think even if I didn't expense - I'd still pay for it. It's a great product; everything is top-notch.
It's not suitable for bulk sending, but for transactional and personal email, I've found it meets my needs.
Be warned, however, that it appears to be a one-man band, and if he goes under a bus...
I'm also a happy user of Migadu. More polished GUI and more features. I've never hit their limits, so not sure how suitable it would be for a medium-sized enterprise. As with Purelymail, it's not intended to be used as a bulk sending service.
Only one of your accounts needs to be Standard tier ($50/y) to allow up to 100 custom domains. The other 5 accounts can be Basic tier ($30/y) and still use as many custom domains as you give them access to. Total undiscounted cost for your family would be $200/y.
Use the 25% 1Password discount to reduce your total to $150/y. You have the option to extend that 25% discount up to 3yrs and receive an additional discount for paying in advance. Your total for your first 3 years would be $420, then $560 for each 3 years thereafter.
Alternatively, you could consider allowing all your family members use the same Standard account ($105 for the first 3yrs) but with multiple email addresses. Use labels to surface each address for the relevant family member.
In my case, I created a family@surname address for any family business, and a name@surname address for each family member. Each family member has set their Fastmail app to focus on their own address. Yes, technically, they can see each other's email, but it hasn't been a problem. I presume they use throwaway gmail accounts for stuff they want to keep totally private.
We share a specific custom domain for our masked emails and love that feature, especially the 1Password integration although that has some rough edges.
1. Every time I give out my email address, behind the scenes a single-source permission/token is created. 2. Thus, that one source is able to send me email, from the email address they specified at the time. 3. But if they hand over the permission/token to anyone else, email from that new source will automatically bounce/be marked as suspect/flagged (my choice in configuration). 4. Even if the original authorized party tries to email me from a different address at the same domain, that email will be handled as in (3). 5. Even from the same email address, the configuration can specify limits, e.g. only 5 emails total, only 3 per week, expire after 10 days, etc. Again, configurable.
Oh, and 6. Of course this means unsubscription becomes a local configuration thing that doesn't require the sender's participation.
I know current email protocols allow none of that, but if we're proposing new protocols, that's what I want out of it. Faster is better too.
Do you mean hand out in a digital sense or on a business card? I'm not sure you can support the business card use case if you implement that.
Simple but genius! I love it :-)
E.g. „Max Mustermann“ <ABCD-1234-XYZW|max@musterfirma.de> is a valid email address with unique code part.
I would actually love this flow and you get OpenID style SSO for free. Could be the actual password killer.
The format I use is {yourname}@{myname}.{mydomain}, so there's a unique address for every pair--some of which I've disabled delivery for.
Indian Retirement Fund website, NPS, government operated, will take your abc+nps@gmail.com at signup, no errors, but will not let you login saying, Email Not Found. You have to login with abc@gmail.com to get in your account.
https://www.fastmail.help/hc/en-us/articles/1500000277942-Ca...
This is still not implicit block like you're after, but when I looked through the settings to see how I had it configured I discovered this integration with 1password: https://1password.com/fastmail/
which, now that I know about, I may start using.
The upside is that it is easy to generate new addresses, I don't need to talk to my mailserver. The small number of addresses that need to be revoked are manually added to a backlist.
john.smith(comment)@example.com
there are also tags
john.smith+sometag@example.com
neither of these require any DNS or server muckery and _should_ be supported by major mail hosts.
Of course, who knows how many random half-assed email validation things people have in their forms that'll prevent you from entering them.
So basically there are three tiers:
- Single relationship emails. Guaranteed delivery until revoked.
- General inbox.
- Unknown to addresses, unlikely to hit the inbox.
(The address are actually signed and blacklisted rather than generated+revoked but that is just an implementation detail)
* Every cert is put into a trust classification that can dictate a default policy
* Policy items could include things such as rate limits, message sizes, spam filter weights, etc.
* Identities can be tied to multiple certs to allow for different modes of communication when desired
* Allow for a trust classification labeled as "public" that is the default classification (with strict limits by default)
* Make common mail items first class objects and allow URLs (e.g. attachments are no longer inline but must be a URL with metadata that can be verified before my system is willing to pull it on my schedule).
Anyway, just ideas for now...
1. anyone who wants a clean inbox -- maybe less profitable
2. any company that wants better protection against phishing attacks -- maybe more profitable
3. Edit to add: someone pointed to https://www.mailinblack.com/ I don't speak French, but that's apparently a company that (somehow) provides a service similar to the description here to high-profile targets.
On the surface it seems like:
1. it would have to rely on email addresses alone -- I don't know another way to transmit information from sender to receiver that fits within current "what's your email?" standards.
2. it would have to have a sparse enough address space that accidental collisions are unlikely -- so maybe 8 alphanumerics for ~41 bits?
The '+' symbol combined with a 10 char UUID can be used to filter
How would this work exactly? You send the token to the recipient's email address? Doesn't that become a chicken/egg problem because the recipient could very well have the same requirement?
IMAP worked over 2400 bps modem connections; we now have multi-megabit connections.
How much faster is JMAP over IMAP and what makes it faster?
* Making a wildcard email address for domain, say @example.com
making a filter that only allows sourcedomain@example.com (or user_sourcedomain@example.com) to accept mails from @sourcedomain
Could replace it with hash in second part hashing whole sender's address with some secret but that might be annoying if you have to tell the email via phone and now it needs to be generated manually
But
> 4. Even if the original authorized party tries to email me from a different address at the same domain, that email will be handled as in (3). 5
Would likely bite you HARD as it isn't too uncommon practice to respond from other email if say you are contacting some generic alias (contact@) but get answer from (john.doe@) that handles your case.
Which is "if I don't put it on my contact list you ain't getting thru". The invite spam is far easier to handle than message spam.
In place of automation for features 2-5 - anytime I feel an address is misused, I add a rule that forwards messages to trash (or spam, for egregious offenders).
Are there any third-party implementations of servers or clients with significant adoption?
Are we allowed to use JMAP for sending transactional emails via Fastmail now? If not, then JMAP seems to be just a method for creating new Fastmail email clients, because no-one else supports it and Fastmail doesn't allow anything but conventional end-user activity.
Or is this wrong?
If I wanted to use JMAP for my next startup, is there a transactional email provider who supports it?
Doing something like this is essentially a bet that your provider will eventually implement jmap.
As you say, though, this is a bet that JMAP will eventually become popular, and there seems no sign of that yet.
> Users expect to be able to search their whole archive, so either you need all the data in the client, or the server needs to have access to the data... ...JMAP is therefore not introducing any new measures to address end-to-end encryption
You don't need to transfer gigs of emails to a client and manually search character-by-character through a massive trove of data. That isn't how search functions.
You can use probabilistic filters (like bloomfilters) so a client can actually run a search on thousands of emails using only a few hundred kilobytes (or maybe megabytes) of actual encrypted data. Basically, less than a modern webpage.
Each time a new email is downloaded, parse it, add it to an index segment, encrypt it, and store it back on the email server. Different clients can reuse the same indexes.
I can see multiple challenges in implementing something like this and I would like to educate myself
Or this could be computed on client side but that's not much different than fetching all emails locally
You put mail into buckets (using some hashes), and hands out the bloom filter for each bucket.
It is better than downloading all mail, but it is nowhere near the speed I want my email search to be.
https://www.ietf.org/id/draft-ietf-jmap-smime-sender-extensi...
Is there a draft for strict JMAP transport security?
> To ensure the confidentiality and integrity of data sent and received via JMAP, all requests MUST use TLS 1.2 or later, following the recommendations in RFC 7525. Servers SHOULD support TLS 1.3 or later.
> Clients MUST validate TLS certificate chains to protect against man-in-the-middle attacks.
Which is maybe fine if you're starting an e-mail account from scratch, but it is going to take a long time to set up email search on a new phone.
Also e-mails are a pretty bad use case for Bloom filters because you need to construct an entire filter per-email for search. Since many emails are short (a sentence or two) you'll find each Bloom filter may actually be larger than the e-mail itself.
I don't know if there are other types of probabilistic filters more suited to e-mail search however.
That's generally not an issue. When people first create an email there is only 1 welcome email in the account. The client web/mobile/desktop downloads that one email and creates the search index.
If you get a new client/phone/desktop you can still reuse the encrypted index files. It's not like you have to download your last 5 years emails on each new device.
Ok, the more I think this out, the more I like the idea of email servers providing ORAM for email clients. The oblivious aspect could actually be optional as well since the server only needs to provide random access and/or a K/V store.
Maybe this could be implemented currently using a fake email draft? Blobs are apparently cleaned up transparently when they are no longer referenced so you could just make sure blobs are small and treat them as immutable blocks. The remaining problem would be encryption of the actual emails, but there is already PGP/GPG for that.
Search will also become difficult but it can be done. At least most mail clients could display all your mail if you have the key.
By contrast HTTP JSON-based APIs are incredibly well-trodden and practically every language has a high quality JSON (de)serializer, many as part of their standard libraries. JMAP would lower the bar for writing email clients dramatically.
IMAP remains supported for backwards-compatibility, but I'm sure its shortcomings are seen as a feature to push users towards the official clients so there is no incentive to implement another open protocol to address them.
In other words, even if someone wanted to make JMAP available to their users, they'd have to tear the whole thing down and rebuild it in JMAP's image, and the tools available to do so are not fully-featured or integratable enough to do so.
This point you mention is being improved. The next release of Stalwart JMAP (expected in one or two months) will delegate user management to either a SQL database or an LDAP directory. Messages will be stored in either Maildir or MinIO/S3. And all other information will be in either SQLite or FoundationDB. All these features were already implemented except MinIO/S3. Development progress can be tracked at https://github.com/stalwartlabs/mail-server/tree/main/crates...
I don’t know where it says jmap support is experimental, but I think it’s pretty stable and well supported in practice. The main maintainers of the project depend on it utterly.
So if it takes a custom schema in a (No)SQL database, so be it, it's simply so much more performant, scalable, reliable and usable. It's simply idiotic how much maildir-based software starts "dying" at around 100000 emails in a folder, in 2023!
(I did a spike development for OAuth and a separate investigation into Labels when I had some free time).
So they are definitely not nice IMAP citizens.
Oh and then there's the issues with Labels that their own documentation apparently gets wrong...
If it's still not standardized then the pitchforks are aimed in the wrong direction.
Because, IIRC, IMAP access must be explicitly enabled by going to Settings -> Forwarding and POP/IMAP -> IMAP access: (o) Enable IMAP. And I think it is not enabled by default.
Hell, now you need to create oauth2 app just to login from non-approved client, as they recently forced OAUTH2 auth on IMAP clients. Sure thunderbird works but most lesser known clients require a lot of fuckery to make work (and possibly admin permissions for domain, not sure).
"Just works" I run it with mbsync at the command line.
You do need a client id and some interaction with your O365 admin.
I did the song and dance for claws-mail and one day it just... stopped working ;/
We had our own e-mail, but we had some problems that were generally caused by management wanting @example1.com and @example2.com to be entirely equivalent, not just an alias, but still land on the same account.
which was fine for the email, as it can just have custom rules, but any related services like calendars bugged, as it saw different domains as different users. We tried to hack around it but it was still buggy in places.
Boss finally got pissed off and decided to migrate to O365, all while IT was screaming nooo. "Because our clients use it too, it will be easier to collaborate"
...and it turned out that what he wanted isn't possible in O365 *fucking anyway* so all e-mails are under @example1.com. And we replaced some weird quirks with many more quirks we can't even hope to fix. We waste more time dealing with this shit than we did on running our own mail servers. Which we didn't like, coz running mail servers sucks, but O365 sucks harder.
That's basically the raison d'etre. You, presumably a student, are getting caught in the crossfire of regulatory compliance and they don't want to maintain two email systems.
Source: Used to be the one implementing those controls. We didn't like them either, I promise.
Just look at how far the deployment of something as essential as DMARC is, it's sad. That's not some big vendor's fault, it's all the small legacy cruft nobody wants to clean out as it might break things.
- Add support for new JMAP protocol: https://bugzilla.mozilla.org/show_bug.cgi?id=1322991
There's also Ltt.rs, a free and open source JMAP email client for Android:
- Ltt.rs source code: https://codeberg.org/iNPUTmice/lttrs-android
- Ltt.rs on F-Droid: https://f-droid.org/en/packages/rs.ltt.android/
> Who can I email directly with questions about giving?
> If you have a question about giving to Thunderbird, please contact us via this form. We will do our best to follow-up with you as soon as we can. If you need technical support, please head over to Thunderbird Support for assistance.
https://www.thunderbird.net/en-US/donate/
You can also try contacting the developer who offered to work on JMAP integration for pay:
> I can't commit to a project of this size however since I work freelancing and my availability is fluid. I am open to being sponsored/contracted in order to do this as part of my job.
JMAP main benefit is that it allows a mail client to to things efficiently in JMAP that are extremely difficult to do in IMAP or take a long time to do. Merely adding JMAP support in Thunderbird will not add any benefit.
The benefit will come if Thunderbird is refactored internally to make use of the nice properties of JMAP, but then there will be a problem with IMAP compatibility which must be kept.
JMAP is nice for new mail clients that can move away from a folder-centric paradigm, but if you already managed to use IMAP then it's less useful.
The solution, of course, is monopoly regulation. AOL Instant Messenger was forced to interoperate and embrace standards. If our legislators had the actual courage to do their jobs in this day and age, Google would be legally required to shift Gmail features to using open standards like JMAP.
https://portal.productboard.com/mimestream/1-mimestream-road...
If anyone else would like to see it supported consider upvoting on their roadmap.
> A lot of the optimisations for efficient client-server sync require the server to be able to read the message. If everything were encrypted, the server would basically be a dumb blob store. This is particularly bad for mobile, where you only want to sync partial information. Users expect to be able to search their whole archive, so either you need all the data in the client, or the server needs to have access to the data.
> JMAP is therefore not introducing any new measures to address end-to-end encryption. The best advice is probably to run your own "JMAP server" on trusted hardware; otherwise you need to sync the entire multi-gigabyte mail spool to all your devices. JMAP is also simple enough that you could run the server on multiple machines with an underlying replication protocol over encrypted links and have that do your smarts.
I enjoy self-hosting stuff, but it's just not what normal people will be doing, and they deserve privacy too. Also, self-hosting email is possibly the most complicated self-hosting task you can think of due to deliverability issues.
My biggest pain point with mail providers that support encryption, such as Proton or Tutanota, is that I have to run a "bridge" application that hosts the IMAP server on my machine, since otherwise there's no way to get the encrypted payloads into my mail client. Otherwise, I will have to use their proprietary client (proprietary in the sense it implements their own protocols). This sucks, and it could be solved at the protocol level with JMAP. I expected this to be a top priority of the Fastmail team when developing this, but unfortunately it's not.
To implement E2EE for email would involve replacing literally every part of the tech stack at literally every provider.
You can't lose an opportunity you never had.
First, at-rest encryption is perfectly doable with most typical software setups (Postfix/Exim/Dovecot/Cyrus/etc), and I think should be not so hard to achieve with proprietary systems as long as they a) capable of dealing with MIME messages (don't reprocess emails for storage) and b) have milter-like capabilities in their local delivery pipeline. You just throw in a milter that encrypts messages to a user-provided key (such as S/MIME or - hey, don't throw anything at me - PGP public key, or whatever MUA may support), and rely on the mail user agent (aka mail client) to be able to decrypt this mail.
Second, I'm not sure how E2EE is even in the picture. It - by definition - should be all happening on the endpoints, so I'm not sure how providers (let alone protocols they use) even fit in the picture. And if anything, it's not on IMAP but on SMTP. But even then, SMTP/LMTP are delivering MIME-encapsulated data (that typically happens to be HTML or text pieces), and they don't really care about what sort of data is in there. This significantly hinders anti-spam capabilities, though.
Right - but Fastmail never had the opportunity to do that, which is what I read GP as asking for.
It couldn’t. You’ve failed to understand the reasoning summarised in the first paragraph. E2EE comes at a significant and fundamental cost, and not one most people want to pay.
There’s a reason why your Proton Mail and the likes are crippled in ways like this: because that’s the best we know how to do with that kind of approach.
There’s also the matter that first-party end-to-end encryption is snake oil: <https://hn.algolia.com/?query=chrismorgan+snake+oil&type=com...>. See also Fastmail’s reasoning for not offering any of this kind of thing: <https://www.fastmail.com/blog/why-we-dont-offer-pgp/>.
Nothing got enough adoption
PGP is just quite sucky, that's indeed supported by only a select few.
I definitely don't want a "hosted" offering where my stuff lives on someone else's hardware and vanishes when they go out of business.
What I would love is a "sysadmin contractor" who runs my stuff for me, on my hardware, on my bandwidth. I pay them not for the hosting, but for the admin skill. Probably a step up from fiverr, but not a full-time employee.
This wouldn't scale very well if the contractor wanted to work for a hundred-plus people like me and learn all our individual tech stacks. But if I could pick from the contractor's menu of supported stuff, and configure it with a menu of supported connections, they should be able to automate a great deal of the administration across all their clients.
Does anything like this exist? I'm aware of various host-it-yourself platforms and distros, but they all expect me to be my own admin, which is a dealbreaker.
What would your ideal budget range for this role be? Maybe we can find a 5-star person, share out their time among 4-5 people here on HN…
I don't know if it's realistic, but I'd love something on the order of $20/mo for something simple like my own photo gallery (whatever package they recommend), maybe a peertube instance, a personal pastebin or etherpad. I'll provide the hardware and connectivity, I just want someone to help me set it up, log in periodically and apply patches, and manage backups and stuff.
I'd expect to pay more if I had weird requests or high-maintenance stuff like email.
Some time ago, I heard an interesting idea for "investing" in indie musicians -- buying their music actually buys stock, and if they become popular, your shares become more valuable. Similarly, if I'm picky about wanting my CTO-on-demand to support _this particular_ photo gallery software, and I pay extra for that special service initially, but later it becomes popular and many of their customers request it and they're able to service those requests because I paid them to develop the skill, maybe I get something in return? I dunno, that gets complicated, but it's worth thinking about how the incentives work.
Also, the great idea behind JMAP is to chain requests so a series of tasks is performed on the server and the client then get the end result. This works great for the majority of cases but the replacement syntax (to replace results from a previous request in a following request) is not powerful enough in some cases (when trying to reuse complex responses in follow-up requests)
The other issue is that there is no way to easily groups e-mails from a given contact. There are JMAP extensions for CardDAV and CalDAV that can be of some use but it's difficult to bridge them with the Email spec and get all e-mails from a given contact for instance.
Last, it lacks editing features like appending a custom header to existing e-mails. The fact that JMAP abstract away all of the MIME format is great, but makes it difficult to just add a single header to an email.
I'm looking forward to more JMAP adoption, especially on FOSS Android platforms.
I’d love to see JMAP take off, but I don’t see a way forward in the current market.
(Source/bias: I worked on Fastmail’s webmail from 2017–2020.)
The problem is Gmail compatibility has been used as a club to beat down competing OS platforms before, and Google has a strong vested interest in requiring clients use their proprietary APIs and features. Building walled gardens is the core way Google extracts value.
It's amazing how the people who have the hardest time believing in JMAP all work or have worked for the company that is most strongly vested in it's failure.
It's worth remembering that the Gmail API does more than IMAP can, and predates JMAP. I understand how Google would get to this point.
https://docs.sendgrid.com/for-developers/parsing-email/setti...
Also, the fact that JMAP makes it convenient to only download part of a message, and let the server do all of the message parsing does not encourage the client developer to do much processing client-side and keep e-mails blob in cache to be processed offline.
The advantage of going straight to notmuch is that the data model is so similar to JMAP that synchronizing is just that much easier. Both ends can give you a state and all emails which have changed from that state. Then it’s just a matter of updating the tags on those to each end or uploading/downloading the email if it’s new.
I get something like 1.7kB round trip data usage when there are no updates (really it’s 0kB save for the keepalive when used in daemon mode) and ~100ms for that round trip. This is in comparison to several megabytes for a single mbsync poll (even when there are 0 changes) and ~5 seconds
I'm not quite up to date wrt. JMAP but the last time I checked (quite a while ago) their approach to "fixing" that problem was security wise fundamentally broken.
Through then most mails are not signed anyway. So for many use-cases this isn't an issue.
EDIT: Note to be confused with Media-Types which are a (very) small part of the MIME specification and are sometimes called MIME Types. Due to their use in http they got their own spec later on (and are also redefined in the HTTP spec instead of referring to the mime spec, funnily their re-definition in the HTTP spec doesn't 100% match the specification in the MIME spec, luckily only in "don't do this every" parts).
> Clients can efficiently fetch updates from their current state a-la QRESYNC. This can be implemented effectively using the MODSEQ data already in modern IMAP servers, or by using a transaction log data structure. The server can always indicate to the client if it cannot calculate updates from a particular client state (for example, because it is too old).
Does not compute.
—⁂—
¹ Well, HTTP is stateless, but in the HTTP/2 and HTTP/3 wire formats, the HPACK and QPACK header compression schemes use connection-level state. But developers talk in terms of HTTP requests, not HTTP/2 or HTTP/3 frames, so it’s OK and HTTP is still stateless.
> if Gmail adopted jmap and added proprietary APIs to it, wouldn't we end up where we are now?
The promise is that vendors would be able to use JMAP out of the box.
If you don’t mind enumerating what you have in mind, what specifically?
As a result, properly functioning IMAP clients/libraries are really few and far-between.
At that point, seems simpler to just treat email data as a bunch of sql tables (i.e. lists, messages, threads, mailboxes, etc) and have the clients issue SQL statements to the server. Would be so much easier to create and read the requests and server implementers could lean on all the SQL tooling available.
I started looking at implementing that
Until Apple and Microsoft support it in their default clients, who will deploy it on the server?
This isn’t what I’d call modern, and isn’t much fun. I’d really like to see a email access API standard that gives way on lock-oriented and session-oriented concepts.
Back to the server considerations: note that this isn’t the only way it can be implemented, but it’s the simplest and most efficient approach.
For the design as a whole, there are very good reasons for it all being done the way it is done. The thing to realise to begin with is that JMAP isn’t actually about email: it’s an object synchronisation protocol (JMAP core, RFC 8620), that just so happens to have email as its first motivating use case (JMAP for Mail, RFC 8621).
It’s definitely different in shape from what web developers are used to; but if you want actual object synchronisation (synchronising stuff for offline use, efficiently fetching new and updated records, whether for the entire collection or for queries (which includes searches and things like single-folder views), that kind of thing), it’s almost the simplest principled design possible. When people implement any form of synchronisation or offline support atop their REST or GraphQL or whatever APIs, they’ll either do something very similar to what JMAP does, or build on some other suitable primitive like Merkle trees, or (and this is what normally happens) be unreliable in ways that make inconsistency likely to occur, and data loss distinctly possible.
> I’d really like to see a email access API standard that gives way on lock-oriented and session-oriented concepts.
I’m not sure what you mean. Could you expand?
Google is not going to support this, and isn't that >50% of the market?
The website lists jmap-proxy (https://github.com/jmapio/jmap-perl) Its age, technology choice and lack of documentation aren't exactly confidence inspiring, however.
Stalwart (https://github.com/stalwartlabs/imap-server/) seems to include a proxy feature (for both, though it's non-obvious to discover) and be better maintained.
A functioning proxy is make or break for me. If it works I can jump right into making a client, if it doesn't there's no point.
What you want is a JMAP-to-IMAP4/SMTP proxy, which is what the jmap-perl proxy is/was (or at least the IMAP4 part). On the matter of technology choice, note that most of Fastmail’s backend is Perl, so it was an obvious choice for such a tech demo being made by Fastmail devs. It wasn’t designed for production use.
Is there anything else on the horizon? Switching away from my current E-Mail provider isn't a realistic option for me and won't be for almost anyone else.
Man, that sucks.
The problem with IMAP is that some requests are not possible efficiently, and the real breakthrough of JMAP is that those requests are now possible and clients are now allowed to be fast. For that though, the server-side JMAP needs to access the indexed mail store directly.
Well, I don't use GMail (and neither should you! All your email is mined for advertising and shared occasionally with the US government.) - so it's not clear to me why I need an alternative to that stuff.
It seems like you don't need it. However, a lot of people access their email across multiple devices and want everything to be kept in sync/efficient to fetch. Currently IMAP is the standard for this, but JMAP is attempting to provide a less complicated replacement.
1. How hard would it be to get 19 years worth of Gmail to Fastmail?
2. I have 4 different domains worth of mail all coming in to one mailbox? Would this be an insane cost on Fastmail?
3. For those of you who have already switched from Gmail -> Fastmail, is there anything you miss after the move?
I would really like to see an open email client standard that is more reliable and performant than IMAP/SMTP, and JMAP could potentially be it. It doesn't seem unreasonable to have 2 competing standards instead of 1 when IMAP hasn't seen any improvements in 20 years.
Of course I'm missing the ability to read my past mail from my phone but life has proven that it's not important neither for my work nor for private matters. Furthermore communications are moving more and more to WhatsApp and Telegram and those are always available on multiple devices.
Is that Bcc to gmail?
However I have a POP3 mailbox bundled with a domain I own since last century. That's my personal email. I never moved it to Gmail because I always downloaded my mail: some emacs package, then Netscape, then Outlook express, then Thunderbird. As a software developer I'm always close to my laptop and before smartphones it was normal not to access email when we were on vacation or on weekends, holidays, etc. When I'm on vacation now I read my mail on my phone, reply and bcc me, leave all messages on the server and download them when I'm back home.
My work email is managed in the same way. Another POP3 account bundled with my own work domain name. No friend or customer ever complained about anything in almost 20 years, hence constant access to the archive of past email is a nice to have feature but not an important one.
It's definitely an uphill battle to introduce any new standard, but it does happen. USB-C, HTML5, ECMA6, I would say are some success stories.
JMAP: It’s Like IMAP but Not Really (2019) - https://news.ycombinator.com/item?id=32978005 - Sept 2022 (131 comments)
How and why we built Masked Email with JMAP, an open API standard - https://news.ycombinator.com/item?id=29188639 - Nov 2021 (4 comments)
Implementing 'focus and reply' for Fastmail with JMAP - https://news.ycombinator.com/item?id=24207506 - Aug 2020 (47 comments)
JMAP: Modern Mail Standard - https://news.ycombinator.com/item?id=21599666 - Nov 2019 (17 comments)
Making email more modern with JMAP - https://news.ycombinator.com/item?id=20720630 - Aug 2019 (166 comments)
The JSON Meta Application Protocol (JMAP) - https://news.ycombinator.com/item?id=20477212 - July 2019 (96 comments)
JMAP: A modern, open email protocol - https://news.ycombinator.com/item?id=19839104 - May 2019 (115 comments)
JMAP: Like IMAP but Not Really - https://news.ycombinator.com/item?id=18996200 - Jan 2019 (228 comments)
JMAP is on the home straight - https://news.ycombinator.com/item?id=18766709 - Dec 2018 (50 comments)
JMAP – an IMAP replacement - https://news.ycombinator.com/item?id=14734091 - July 2017 (20 comments)
JMAP: A better way to email (2014) - https://news.ycombinator.com/item?id=14283659 - May 2017 (51 comments)
Progress on JMAP, better standard for synchronising mail, calendars and contacts - https://news.ycombinator.com/item?id=10781894 - Dec 2015 (35 comments)
An open source JMAP proxy, JavaScript library and webmail demo - https://news.ycombinator.com/item?id=10038547 - Aug 2015 (18 comments)
JMAP – a better way to email - https://news.ycombinator.com/item?id=8785894 - Dec 2014 (115 comments)
JSON Mail Access Protocol Specification (JMAP) - https://news.ycombinator.com/item?id=7141152 - Jan 2014 (61 comments)
JSON Mail Access Protocol Specification (JMAP) - https://news.ycombinator.com/item?id=7141028 - Jan 2014 (1 comment)
If you want something that works for everyone, it has to be port 443 and webby.
And any mobile push notifications better be via Google/Apple notification services, because modern OS's don't let applications leave a hanging TCP connection open anymore.
Destination e-mail domains to which you want to send mail have SMTP servers. To send them mail, you have to contact their SMTP server somehow. If not directly, then through an intermediary.
> If you want something that works for everyone, it has to be port 443 and webby.
That doesn't follow. SMTP is already authenticated and SSL-protected (or can be). The port number isn't the problem, it's the spam.
Suppose that I run an alternative mail server, so that you can send me mail over HTTPS on 443.
If you're a residential subscriber, I'm still blocking you the same way.
Only, it's harder now. I have only one static IP address, and have to serve web requests on it on port 443. So I can't block you at the IP level; I have to let you access my web site (open to all) but block your use of the specific API. That's more costly in terms of system resources; I have to let you connect, and do the SSL handshake and submit requests, instead of turfing your packets at the IP layer.
> modern OS's don't let applications leave a hanging TCP connection open anymore
That has been the case since BSD Unix introduced sockets. When the application quits, the connections close. (At best, there is a graceful shutdown in the background, where the protocol stack exchanges the final FIN segments.)
Eleven nines is very excessive. Frankly even six nines would still feel excessive, though I’m sorry to say that five might not be any more. Fifteen years ago, I think even three nines would have been excessive. Legitimate outgoing SMTP was fairly common in those days, and botnet SMTP probably proportionally rarer. You know what, even one nine might have been excessive less than twenty years ago.
Sending mail directly from a residential network by connecting to the given mail domain is a nonstarter. Hasn't worked in twenty years or more. That doesn't require a MTA; only a MUA.
Your mail program (MUA) like Thunderbird or Outlook, or the mail utility in a Unix-like OS, can perfectly well work without a configured SMTP server. You send to bob@example.com. The mail program will do a MX type DNS query for example.com and find out that the mail.example.com is the mail host for that domain. It will resolve that again with an A query to get an IP address, and connect to port 25 of that host to send the mail.
In a world without spammers, that's how things would work.
In a world with spammers, mail servers block connections from random addresses like residential IP addresses.
Users (who want to send mail from home) have to resort to using forwarding hosts: their mail client is configured to make an SMTP connection not directly to a target mail domain, but to a configured host, like something run by their ISP or some commercial SMTP provider.
Other MX might reject you on port 25 due to a residential IP, but that is not an ISP block.
The words "they", "are", "very" and "dated" are even older, so don't use them if you want to be hip.
Well, no shit, they were designed before HTML and HTTP, not just JavaScript, and there’s zero need to actually shove them into that mold because they already exist and are fine as they are in terms of protocol-level features. If you can’t deal with that maybe you shouldn’t be trying to do development at that level.
Meanwhile, all that energy spent reinventing the protocol layer to be maximally aesthetic to people for whom all the world is JavaScript running in a browser could have been used to actually improve the applications running over the protocol.
> Its JSON-centred roots and HTTP are conventional,
> so special parsers are not needed: this is quite intentional.
SMTP and IMAP are a pain and problematic to deal with for various reasons. Building on popular web tech primitives makes everyone’s lives much easier, even if you’re not making a webmail client.
They are problematic for only one kind of entity: someone who has delusions of becoming the next gmail.
Everyone else can just set up an open source SMTP and IMAP setup using existing programs that work, without writing a single line of parsing code.
I don't trust this "open standard" bullshit. When the only thing running JMAP is Fastmail, it's a Fastmail-specific protocol.
If you want developers to interface with it, you can't hide it: you have to document what the requests and responses look like. The "open standard" rhetoric has good optics; even more so with the IETF rubber stamp.
The underlying idea behind JMAP is that the future consists of only large mail operators who somehow forward mail among themselves. Routing to SMTP servers is gone, and so is self-hosting, mostly.
If you want your own mail domain, you can do that, but to operate it, your instance must connect over some web protocol to an e-mail monopolist.
The IETF may have signed off on this, but I look forward to what the EFF have to say.
Suppose you want to write a client that can do email sending (SMTP), email reading (IMAP), contact book (CardDAV) and calendar (CalDAV) interactions.
SMTP/IMAP autodiscovery is limited at best, and CardDAV/CalDAV autodiscovery nonexistent, I think, so new users will have to find the details for several things, which is a big hurdle—or else you’ll have to recognise and special-case individual providers, which basically means Google and Microsoft get a massive unfair advantage. By contrast, JMAP handles autodiscovery of all this: type in an email address, and it finds the JMAP endpoint, which handles all of the stuff. (I will admit that this is currently more aspirational than real: to begin with it requires a DNS SRV record and/or a /.well-known/jmap HTTP response; and the means of authentication is deliberately unspecified at this stage, so we kinda need to wait around to see what providers settle on for authentication, with some kind of OAuth arrangement probably most likely.)
And then perhaps your client is webmail; if so, you simply can’t use IMAP or SMTP. I guess you could try talking them over WebSocket or something like that (still requiring a proxy of some kind, even if a pass-through one), but that’d be painful; instead, everyone rolls their own thing, and so there’s never any webmail cross-compatibility. In JMAP, by contrast, the only thing you can’t do from a browser is looking up DNS SRV records. Everything else works, so that you can run your own webmail client that talks directly to the origin server. This allows you to disentangle the provision of service and software, which is very desirable for decentralisation.
Well, now you want your client to produce notifications when new messages come in. If you’re writing for a desktop platform, fine: you can keep your IMAP connection open. But if you’re on a mobile platform, you probably can’t do that, and certainly can’t reliably, so… you’re stuck needing some kind of proxy and server component again. No good. But with JMAP, you set up a push subscription and it works just like any other app, without needing to keep a connection open.
So there are three simple and concrete advantages of JMAP over the legacy protocols. JMAP actively bolsters decentralisation, in email providers, in domain names, in contact book and calendar support, in webmail, and in mobile notifications. There are other functional advantages too. JMAP enables some moderately complex batching that makes some sorts of realistic operations vastly faster than IMAP due to being able to skip many round trips. And JMAP’s pleasantness to work with directly should not be understated: no one wants to work with SMTP or IMAP directly because they’re painful protocols, and so of course all of that stuff tends to get extracted into a single library that protects you from them; by contrast, working in raw JMAP is pleasant and easy, which can genuinely open you up to doing things that would have been too painful to do through your IMAP library. And if you use JMAP, your mail client can skip worrying about MIME parsing (which is landmine-filled territory) if you choose. You can write a useful and complex standalone email workflow with nothing more than HTTP and JSON libraries.
> The underlying idea behind JMAP is that the future consists of only large mail operators who somehow forward mail among themselves. Routing to SMTP servers is gone, and so is self-hosting, mostly.
This is all completely wrong: JMAP is for client–server communications and doesn’t replace server–server communications, which still use SMTP. JMAP does not prop up email monopolists.
> If you want developers to interface with it, you can't hide it: you have to document what the requests and responses look like.
I have no idea what this is about. The spec shows examples.
> The "open standard" rhetoric has good optics; even more so with the IETF rubber stamp.
There was no IETF rubber stamp (which I take you to be using as a pejorative). There was collaborative process with people from a variety of companies who took what Fastmail had designed for their own use and wanted to share, and made it considerably better.
I don't find your arguments rationally convincing. You're comparing developing mail software using libraries for JSON, HTTPS and other pieces, versus doing the same thing while developing IMAP from scratch.
It boils down to "web developers don't have nice libraries for IMAP access and are too busy making another clone of React or Typescript to make one".
It's not realistic to develop a new mail client without IMAP (complete non-starter) even if it suports JMAP.
This shit only benefits people who are trying to be the next Gmail. On the surface, it's somewhat good for users who rely on monolithic mail service in that if there are more such services, they have more choice.
It's bad for everyone is not using a monolithic mail service, who doesn't want a new mail client speaking a new protocol or to install services for that or anything else.
> And then perhaps your client is webmail; if so, you simply can’t use IMAP or SMTP.
That claim is amazing; in another browser tab right here I'm logged into my self-hosted RoundCube webmail which is accessing my inbox with IMAP, and sends with SMTP. Of course, it does those things at the PHP back end.
I think you may be conflating "webmail" with a "browser-based, purely local mail client application not accessed over the network".
If such a thing is not able to speak SMTP or IMAP, maybe the Javscript world should tool up?
This is nonsense. Most of my comment was describing protocol-level advantages of JMAP over IMAP: things that you can’t get with IMAP (+ SMTP + CalDAV + CardDAV + …), and things that affect the user experience. I did mention at one point that JMAP is such that you don’t even need any library to achieve useful things with it, whereas you wouldn’t tend to get far without such libraries on SMTP/IMAP, but I wasn’t making that comparison in any other way.
> It's not realistic to develop a new mail client without IMAP (complete non-starter) even if it suports JMAP.
Not true. It depends on who you’re targeting and what you’re trying to achieve. Sure, most will still want to support IMAP/SMTP due to JMAP’s current lack of widespread adoption, but honestly going native JMAP only carries some pretty compelling technical and functional advantages.
> This only benefits people who are trying to be the next Gmail.
I rebutted this fairly clearly in my previous comment. You seem to be fixing on first-party software, where service and software are provided by the same entity, but this is something that JMAP is better about compared to IMAP/SMTP, removing some of the unfair advantage first-party software had and levelling the field for all service providers and domain names, due to autodiscovery that works, and exposing the server in a way that even a web frontend can directly access.
Just because Fastmail is currently the only notable provider shipping JMAP doesn’t mean that JMAP is about Fastmail. There’s a fair bit of interest from other providers, it just takes time. Also I would point out that Fastmail has not the slightest ambition of being “the next Gmail”; their business model, history and market positioning should make that very clear.
> I'm logged into my self-hosted RoundCube webmail which is accessing my inbox with IMAP, and sends with SMTP. Of course, it does those things at the PHP back end.
That RoundCube requires a backend, and its frontend has to talk something other than IMAP and SMTP, is a problem. Until JMAP, every single webmail client has done its own thing for a client–server protocol, and they’ve almost all been terrible, and so you’ve kinda had to learn two things to develop it, and you’ll have functional limitations all over the place that make developing the frontend hard. By contrast, with JMAP, a webmail frontend and a desktop app are talking the same protocol. That’s very valuable.
I did go a little too hard on this in that a backend can allow you to connect to arbitrary mail sources (though in practice webmail is almost always first-party, service and software coming from the same provider), but that fact that you need that extra backend is still a problem, for performance and for privacy: your software vendor shouldn’t need to be able to access all your mail; it’s much better if the software can talk directly to the service provider.
> If such a thing is not able to speak SMTP or IMAP, maybe the Javscript world should tool up?
It’s not possible due to the web’s security model; it’d be a fiasco if browsers let JS initiate arbitrary TCP connections—far too much software assumes that only trusted software can talk on the local network. From time to time there are ideas about relaxing this limitation by server opt-in (along the lines of CORS preflight requests), but they’ve never gone anywhere yet and I don’t think they will any time soon, and certainly it will never be fully relaxed.
> You seem to be fixing on first-party software, where service and software are provided by the same entity
No I'm not. It's a given that those are unbundled.
For instance, today, you don't have to use a Google mail client with Gmail, right?
Maintaining their dominance doesn't depend on locking people to the Gmail webmail interface.
I take it for granted that the purveyors of JMAP want people to go nuts developing clients.
I said you seemed to be fixing on first-party software because a lot of your arguments about centralisation of power and such and assumed motives of companies pushing JMAP only make sense in that light. I’ll say it once more: by its design, JMAP distributes the power, supporting usable decentralisation better than IMAP/SMTP/CalDAV/CardDAV/&c. Adoption is limited yet, but that doesn’t change this fact.
As for Gmail: you’ll get a second-rate experience if you don’t use a Google client or Google-specific APIs. Dodgy IMAP (partly understandable—when they started, IMAP didn’t support the concept of labels and so they had to make some kind of workaround—but IMAP has very obviously been a second-class citizen through all Gmail’s history). No notifications unless you hold an IMAP connection open (which you can’t on mobile platforms). The necessity of Gmail-specific authentication (or else some users won’t be able to use it at all, and the rest must jump through increasingly-scarified hoops). That’s what Google is pushing. Gmail’s dominance has absolutely involved locking people to first-party clients, and IMAP/SMTP support is a concession. JMAP is nothing like all of that.
Sure, for now!
That is obvious; but the scum who want to disrupt and destroy e-mail won't stop there.
Of course, big, monolithic mail companies would love to get people off the old protocols. Once that is in place, they will make deals to move mail among themselves in some new ways, and e-mail as you know it is finished.
> Your scoffing suggests that you haven’t understood what JMAP is.
I'm not assuming you or anyone else in this thread is an idiot; please return the favor.
(I am assuming that you're naive ... sorry about that.)
Seriously, a lot of what you’re saying just doesn’t make sense and is internally inconsistent.
* curly braces are not modern.
* quotes around strings are not modern, and neither are backslash escapes like \n
* commas and colons to separate items are not modern; square brackets for arrays are not modern
* JSON's printed floating-point format which looks like 123.56E+78 can be seen in computing-related documents from the late 1950's.
* HTTPS isn't new, and sending formatted data over web transport as an API is soon going to be approaching thirty; remember SOAP from the 1990's?
The SOAP was handled by so many hands it shrank down to JSON.
At least Microsoft had an excuse with the wacky variations of the Exchange protocol: They built a Big Thing before Internet email “won” and thus have a bunch of legacy to carry forward. This is just a “solution” looking for a problem.