I love JMAP. It's what allowed me and my team (at 1Password) to easily add support for Masked Emails, where we randomly generate your email address in addition to your password.
I use Fastmail and 1Password, and I do used the masked email functionality. There is a massive gap, though, that makes it very difficult to rely on masked email. When I sign up for a new account somewhere, I can choose to create a masked email. If I later need to email that company (not reply via an existing email message), I must first somehow look up what email I used for that company, go into fastmail settings and create a "sender identity", remember the email address again, and then when I compose, remember to choose the sender identity that is associated with the masked email address I created for that specific company. If I forget or mess up any of those steps, I end up sending from my primary account or some other masked email address associated with some other company. Multiply that by dozens or even a hundred companies!
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 would be really nice if adding a masked email automatically created a "sending identity."
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 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?
> there used to be a whole section on adding "sending identities"
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.
> go into fastmail settings and create a "sender identity"
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.
Instead of generating a unique email per relationship, it'd be better if the email provider generated a unique key when the relationship is established that the customer or end user can revoke.
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.
OK. Sure. It’d be better, for you, a technologically savvy receiver of email. I can’t see anyone else in the equation that stands to benefit from this. I can’t see non-tech-savvy email receivers caring much about this at all, or any of its effects, until it has near-universal adoption. Part of solution engineering is coming up with something that people actually want to use.
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.
While the protocol details would undoubtedly be somewhat complicated, the user-facing UX wouldn't necessarily have to be.
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.
Also, every website would have to have a way to do this. That's a massive bootstrapping effort that, you can't change every website in the world very easily, there'd have to be a very massive advantage for them. I don't see the evolutionary pathway to get your suggestion implemented.
Besides, this already exists anyway, it's basically:
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.
The users don't have to interact with any piece of this. It can be 100% a backend implementation detail.
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.
This was also an issue I had, but there is actually very good support for this hidden by an invisible feature. Simply add an `*@domain` as your email address identity. When you select that as your from address the fastmail UI gives you an input box to use whatever email you want, you don't need to make a new identity each time. For lookup, I just use my password manager.
Off the current topic but since you're promoting 1Password, I notice their cookie policy references EU legislation but chooses not to comply with it. Do you know if that's intentional?
Indeed that is very awkward: "European Union (“EU”) legislation requires all website operators to inform website visitors about their usage of cookies"
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.
The legislation requires you to ask consent for non-essential (ie. tracking) cookies. So unless they put a tracking cookie on their site the behaviour is correct, and that text is simply incorrect.
That's my bad for not quoting further, the very next paragraph is:
> 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.
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.
I do most of my mailing using the RoundCube webmail interface. I made some patches to it.
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.
Yes; this is for the control freak that wants to shut down the offenders at the SMTP level.
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).
because the masked email API matches the rest of the JMAP API, so it's easy to extend and support. Also, 1Password isn't running Dovecot, Fastmail is. So they're asking a 3rd party is a fairly standards conformant way to go and create a new email alias
I had a major issue with spam on FM and after some back and forth with support, I got some understanding of their system:
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.
> all the spam overwhelmingly comes from gmail.com accounts.
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.
Thanks for the advice. That said, there's hundreds of email addresses I get spammed from.
> 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 still report spam to all ISPs/mail providers, if they have a proper abuse@dom contact and I can spare the few moments it takes. And, also report the spam/scam mail contact reply-to: addresses to their respective email providers when they differ from the sender provider. When scam mails contain URLs, I'll report those to their domain registrar / webhost.
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.
For a long time I thought the spam filtering was not very good, but what eventually led to that was my own mistake of setting "learn as spam" on the spam folder itself. In Fastmail's own words:
> 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.
I have the exact opposite experience and find Fastnail's spam detection quite superior.
There is the occasional spam.email getting through - maybe 1 per day - despite the fact that I have quite a number of custom domains with catch-all email addresses.
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.
I always find it curious how people often have such a different experience with the same system. For my part, I've found Fastmail's spam filtering to be much better than GMail's, especially when it comes to those false positives: I would see ham in my GMail spam folder at least a couple times a week. I've mostly stopped perusing my Fastmail spam folder, as I still have yet to find any false positives there.
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 think I’m up to two false positives after six years, neither of which was in any way important (in fact, I kinda agreed with its judgement), and I’m up to 175 false negatives in the last 5⅓ years (of which 32 are from the last twelve months, which suggests a fairly steady rate across the whole time; it comes to about one every eleven days).
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.
I had the same experience and ended up leaving after my trial.
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.
I heard a rumour that a huge portion of messages that hit Google servers are outright dropped. Not the spam folder, gone forever. Apparently the dropped number was much closer to 50% than 0%.
You can connect FastMail to gmail and never look at gmail. Your employer may not approve if you hillary your emails like that though, but that's what I did at a previous employer where this wasn't an issue.
I like your usage of Hillary as a verb. I don't understand the affinity against Gmail though. With the fastmail forwarding service are you still not using Gmail spam service and have Gmail access to your email anyways (not that I'd believe they do unless wearing a tinfoil hat)
I just don't care much for gmail's UI; that's all there's to it. And having all email in one place is more convenient for me regardless – saves having to open/check another service.
You're still using gmail's spam checking; it just uses the API (or IMAP? I forgot) to sync the emails to FastMail.
Have you considered setting up a rule using the Snooze feature[0]? Using this it should be possible to delay all incoming work email until a time that is suitable for you.
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:
Zoho actually has a free plan for up to 5 users, including a single custom domain. However, they force you to use their web/mobile mail app unless you upgrade to their paid plans which include IMAP/POP and many custom domains. Their paid plans are very reasonable and start out at $1 and $1.20 (5/10GB respectively) a month.
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.
Seems 99% reasonable, but the per-message limits make it a non-starter for me. I get why they’re doing it and totally understand where they’re coming from, but the off-chance that an incoming email gets bounced due to no fault of my own (other than subscribing to a higher tier) just doesn’t work for me.
I can also vouch for Migadu. I've been using it for 6-7 years with 4 different domain names because they only charge for usage; not per domain or user. The few times when I contacted support they were also very helpful.
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).
You could also stick with free Gmail accounts and add on top all addresses and domains you need via gmailify.com[1] for flat $6 per year. It's custom domains extensions for Gmail with own dedicated relays.
I think Fastmail are missing out by not having a "Family" plan for this kind of use case, but just because you're not handing over money doesn't mean Gmail is cheap.
Only one account needs to be a regular account to support custom domains. The others can be basic - 2.50 per month (when paid annually) or $200/year total for 6 users (1 standard + 5 basic)
I did look into that for my family domain but the storage space for the basic plan was so low I ended up sticking with regular accounts. Only two accounts though so bearable. If I was in OP's situation with six family members I probably wouldn't have gone down the FastMail route.
"You can build an account where you mix and match the plan level to each user. For example, you can build a Fastmail Family by adding additional Standard and Basic plans for adults and children."
- https://www.fastmail.com/pricing/
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.
Another happy user of Purelymail here. The GUI is unpolished, but deliverability and reliability have been excellent for me in the few years that I've used it. Unlimited custom domains and inexpensive.
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.
Did I read somewhere that Scott is training his brother as a failsafe. Joking aside, I love the service as it is just what I need for not mission-critical stuff, as I tend to board domains and love to experiment with stuff. Would love somewhere else instead of Roundcube, but not sure is there anything modern enough. The only killer feature I need is super fast power search.
Apple has an incredibly cheap option here. If you subscribe to iCloud+ (https://www.apple.com/icloud/), starting at $1/month, you can share one or more custom email domains with up to 6 people total.
I've been using this for a year or so and my family's been happy with it.
An Apple device (iPhone, iPad, or Mac) is required to manage your iCloud+ subscription. It's not intended to work as a web service independent of their products, even if you could use parts of it from other devices.
iCloud+ is primarily cloud backup and storage solution for iPhones. Those two are both very tightly integrated.
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 set it up as standard SMTP/IMAP in your email client. There's also a web interface at icloud.com if you want to check your mail there, or set up filters, etc.
I don't think you'd need any Apple gear at all to use it, but make no promises.
I believe they changed this, you can now have an account with multiple levels of users. I believe as long as you have one $5 tier user, you can have additional $3 tier users at your domain.
I have a similar situation and I think that you might be able to have 1 standard account and 5 basic accounts in this situation. Depending on what capabilities the other 5 people need.
Only one account needs to be the $5 one to get the custom domain, the rest of the family can have a $3 / month account and they can use the custom domain too.
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.
Perfectly legitimate question - and I don't think you should have been downvoted for asking.
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 think the risk of them going out of business overnight/no warning, is lower than google arbitrarily locking you out of your account with no recourse (at least with the free versions)
Is that enough for their company to be alive? Many startups offer paid services but it isn't enough to cover their own costs and salaries in the first several years; everything depends on investors willing to fund them through that period.
FWIW, they are not a startup, they are 24 years old and (after being bought by opera and then buying themselves out again) fully independent [0]. They are also probably HN’s most beloved company, but that just as a side ;)
They're a business, that the users of their services pay money to. The only differences between them and Google is who their users are, and who is significantly more likely to shoot useful products in the head.
Sounds like the big claim here is that it is faster. That's definitely a good thing, but what I want is a protocol where:
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.
Your vision is further than fastmail can currently take you, but a partial solution which I use is to just give out a unique email address to each company. that way when you get spam you can disable that address for future use and also use it as a conversation starter with whoever leaked your data to a spammer.
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.
Yup, since I'm using my own domain domain I use kevincox@ for public sharing and generated emails for sharing with companies. Therefore there is no obvious path from the email I give them (which bypasses the spam filter and can be revoked) to my general email address. Although it is easy to find my general address online it is fairly heavily spam-filtered. And unknown address is subject to an very harsh filter if it wants to end up in my inbox.
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)
Do you have the system automated? Meaning: if I send email right now to {somerandomstring}@{yourname}.{yourdomain} does it get automatically rejected, or flagged? And if yes, how do you add {myname} to your whitelist?
I'm not GP but use a similar system. I just set up a global forwarding rule for the domain using forwardemail.net. The default is to let it through. If I get a spam message I'll check the "to" field in gmail and can quickly see who it was that sold it or leaked it. Can also create a rule in gmail to send to trash or can even add a forwarding rule for that inbox if needed in forwardemail
I have fastmail configured to accept *@{my name}.{my domain} and then I have a rule for each blocked sender. So it's it opposite of the logic that you want: I'll receive they mail until I explicitly block you.
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/
At least from the promo video that seems very much like Apple's "supply a unique email" feature. Which is better than nothing, but waaaaay less feature-ful and much more manual than my ideal setup.
For my hosted E-Mail I've configured one inbox as "catch all unknown". This allows me to "generate" e-mail addresses on the fly without any configuration (at least receiving). Once one of the addresses / aliases was burnt for some reason I could make a separate postbox of it with all blocking rules and dead end for spam. This is a quite comfortable way for me, although the emails are not flagged in any way. They will come through in any case and I postponed the the work to any malicious event.
This is basically what I do. {tag}-{signature}@{domain}.
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.
Both Gmail and Fastmail supports "+something" in the local part of your email address, so you can just add a foo+*@domain filter to block everything or move it to a folder, and then add a foo+someapprovedsender@domain filter before it for anyone you want to reach your inbox.
Almost every provider (social media, banks, websites and spammers) also know this, and routinely remove anything after + in @gmail addresses.
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.
All the places I've given addresses like that dutifully e-mails to the right place, so I guess I must've gotten lucky. But if you use your own domain with Fastmail (which I'd recommend anyway, so you have an easy way of moving elsewhere if you need to - how I was able to migrate to Fastmail from Google relatively painlessly in the first place) you can also set up catchall addresses so you can use the whole local-part instead:
Fastmail supports both yourname+foo@example.com and foo@yourname.example.com. I use the latter precisely to avoid the problem of sites that don't play well with plus addresses.
I had a similar idea to this and wanted to add a couple of more features. It essentially is policy-based email so I thought:
* 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).
I have other ideas as well; This is something I've been thinking about a lot lately. One other feature that would be nice is if you could somehow link it up to SMTP gateways. I realize that sort of defeats the purpose, but that would accelerate adoption of any new technology since it has so much gravity.
Nice! If there were a reasonable path to get from here to there, I'd say we should share a google doc to firm up the definition/requirements. But since (as far as I know) there is zero chance of something like this working, we'd both be wasting (more of) our time :-(
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.
If the skateboard version of this seems technically do-able without having to convince the entire world to switch to a new protocol I'd be happy to jump into a google doc to noodle it further.
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?
But if you have other ideas I'd love to hear them -- griping about email has been a thing of mine for 20 years...
> Every time I give out my email address, behind the scenes a single-source permission/token is created.
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?
Exactly what the other replier said -- with current protocols almost certainly not possible, and even with complete access to *@mydomain.com it would likely be a serious hack, brittle in many ways, and not robust in others. But with a new protocol underlying, I could see this all being handled automatically. (maybe -- I haven't walked through this with a technical person).
> 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).
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.
I assume that business cards would have a unique email/end point to allow for this case, kind of like how gmail and others allow you to add +<stuff> to the end of your email address. So you'd have a set of "business card" emails + rules that would allow only the first sender to send emails to that address (for example).
So each business card would have to be unique with a unique address? I feel like it is generally considered unprofessional to have an email address with random letters in it, not to mention, you'd need a special business card printer to handle that.
The email address can be user-friendly, but card can also include an unique code similar to product serial numbers, that is redeemed with the first message.
E.g. „Max Mustermann“ <ABCD-1234-XYZW|max@musterfirma.de> is a valid email address with unique code part.
I think yes, this would be required. An email address with random characters in it for no reason would certainly be questionable, but if the use case I'm proposing becomes at all known it would be much more understandable I think.
More digital -- I haven't had business cards in ages. But even in a card case it should be possible to: 1. print cards with a unique token/whatever on each card (I get that this isn't the same as old school cards that have to be identical) 2. limit any given token to 3 uses (or similar)
I think the more practical issue is that if each business card has its own single use token then your printer is doing one copy of each card. Doable, but not how any business card company is setup today. I do get the desire for this sort of thing, but I also think most users of email treat an address as a static entity.
* 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.
Yeah, I abbreviated the spec. If I were putting together a full requirements doc for this feature, it would have to include different levels/types of filtering. So e.g. if I registered my email with signup@walmart.com and then received email from noreply@walmart.com, that wouldn't receive the same sort of blackholing as an email using the same token but from *@sospammy.com
Sounds like you want email to work basically 1-1 with OAuth where you authorize the sender the way you would grant access to your Google/Spotify account.
I would actually love this flow and you get OpenID style SSO for free. Could be the actual password killer.
This is a little confusing since it’s not just an access token (or refresh token) since the OP wants to verify that the sender is the correct sender, not just that they have access to the token. Otherwise a token holder could simply pass the token to spammers, still. This is harder since the sender could share his or her sender key, so you’d have to disincentive that, but doing so it going to make the system even more complex.
I think the idea is that OAuth token would allow sending emails as a specific sender, like if I allow say Lyft to send me emails in this flow and they pass the key to spammers the emails will appear to come with Lyft.
You don't have to go very far with extra checks and disincentives, as the recipient can also invalidate the token at the first sign of spam. SPF/DKIM or an equivalent can also help with sender authentication.
I actually loved XMPP/Jabber flow where sender first need your permission to get added to the contact list and get their messages thru. Still can be spammed but without any meaningful content at least.
I'm on fastmail. 1 and 6 are a feature they offer (I use it).
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).
Your best bet for something like is simply to set up catchall rule to move everything not already shunted elsewhere to a "staging" folder, and then use a script to apply whatever advanced filtering you want that your provider cant and move anything that should be allowed past to your inbox.
I see this popping up every year (sometimes multiple times a year) and, as someone who used to be a postmaster and did _a lot_ of IMAP tweaking, I have to say that even though IMAP is old and gnarly and increasingly out of favor (I just can't use it on Google anymore, only on outlook.com and my own archive), JMAP seems to pretty much have failed adoption-wise -- I don't see any relevant e-mail clients supporting it, no webmail front-ends claim to use it, no other providers besides FastMail seem to support it, and even old-style ISPs (of which there are still a few) don't seem to have any interest in it (source: I used to work in telco-run ISPs until some years ago, and still have friends doing that).
Are there any third-party implementations of servers or clients with significant adoption?
I'm a Fastmail customer, and speaking to them for my last startup, they were adamant that we couldn't use them for sending transactional emails to our customers. So I'm a bit confused why they're letting 1Password do this.
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?
There's software like https://github.com/jmapio/jmap-perl you can use in front of your chosen provider but that seems like more headache than it's worth unless your imap implementation/lib is incredibly complicated.
Doing something like this is essentially a bet that your provider will eventually implement jmap.
Only servers I'm aware of that support JMAP are Cyrus and James. Clients do seem to be thin on the ground right now, with https://github.com/jmapio/jmap-demo-webmail still being the one to use (as far as I know).
> 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.
That still requires the client to have downloaded all emails in the past in order to generate the Bloom filters. Those filters can't be provided by the server.
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 still requires the client to have downloaded all emails in the past in order to generate the Bloom filters.
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.
In that scenario would each device to publish their index files and the others using the same account download and use them? Are there good merging methods for this or would it just be latest wins?
They would reuse a few large fragments. Maybe one each month or year. There would need to be some sort of locking mech to keep clients from clobbering each other, or maybe not since the final state of the filter would probably be the same anyway.
You can possibly generate these filters on the server-side and serialize them for the client. I like the idea of only needing to store some pointers and metadata locally; that said I do prefer all my mail is available offline.
> 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.
The only way I could see this working would be if there was some way for an email client to store its own encrypted data on the server that is not an email/attachment and is tied to a particular email client. With such an API, clients could just do the indexing themselves and then store the index on the server. You'd probably want something like oblivious-RAM so that clients could avoid reading and writing the entire index all at once.
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.
The receiving mail server could encrypt everything for the mailbox owner's S/MIME keypair, that would be really rather seamless with already existing protocols and clients. This "only" leaves the problem of key management to the user, which in my opinion is far out of scope for JMAP as well.
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.
The thing I wanted to cover with my idea is how to avoid rebuilding the index on each client as well as not having to store the entire index on the client. In my opinion, large indexes are probably a requirement for broad adoption by users since accurate search is very important for email (besides user desires, this could even be a legal requirement for discovery requests during a lawsuit).
Clients already fetch all emails locally over the years you use the email. You don't have to build the index in one pass. As you read/download each new email, you add it to the index segments. The same way you don't have to download the internet to create your searchable browser history.
You could also have the bigger desktop client fetch everything for the purposes of building an index (and also having a backup of your email), then your smaller phone doesn't have to fetch everything
I really hope that JMAP starts getting some traction, because I've toyed with writing an email client of my own while it's certainly possible to do so, my hope of writing one that people other than myself might actually want to use is quite low. There's so many little nuances and gotchas with IMAP that make it a real bear to work with, plus you have the whole mess of multipart encoding which you might have to roll your own for since not all languages have a suitable library.
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.
I'm in the same boat! I dislike the current state of E-Mail clients and while there's an uncountable amount of servers, I can't really find any clients.
The problem is that email has been taken over by a handful of providers, all of which have "growth & engagement" as their business model and would rather not implement any open protocol at all.
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.
This is a problem, but the other problem is the tools to implement the service. You can use Cyrus, Apache James, or Stalwart, and that's it. These tools do not integrate with anything; in the case of Stalwart (the only JMAP server not in "experimental" status) you can't just install a JMAP server attached to an existing email service; you have to hand it complete control of everything, even unto the on-disk storage of mail. This is a complete non-starter for any email service outside of hobby/personal hosting.
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.
> These tools do not integrate with anything; in the case of Stalwart (the only JMAP server not in "experimental" status) you can't just install a JMAP server attached to an existing email service; you have to hand it complete control of everything, even unto the on-disk storage of mail.
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...
Cyrus is what fastmail use for their own mail servers. And even the fastmail web ui uses jmap.
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.
The file storage approach is unfortunately super common and makes a bunch of really basic things difficult and slow. Need to phase it out more heavily, especially from new implementations.
Telling people who have decades of perfectly serviceable email solutions that they need to 'phase out' what works is a great example of an unconvincing argument. What you say might be true from a developer's perspective but maildir is a battle-tested, accessible, well-understood and interoperable storage format. Bundling everything up behind some bespoke SQL schema might ease performance hurdles but it sucks for everything else.
Does it work though? Nobody runs such systems at scale, for very good reasons, because maildir just sucks in so many ways. Horses have also been battle-tested, they're well-understood, but they don't transport tonnes of cargo and getting kicked in your face because they don't like you isn't pleasant.
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!
Case in point: MS making it more and more annoying to use IMAP.
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).
My university uses MS for their services, and they stubbornly refuse to let me use IMAP (not even with OAuth). I have to either use GNOME Evolution for Micro$oft exchange protocol or a proprietary app on my phone, which enforces bullshit control on a device I paid for.
> which enforces bullshit control on a device I paid for
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.
Effectively, MS has bulldozed companies that use Microsoft365 into using its own proprietary protocols and applications (Outlook). It scares companies into not enabling IMAP (even with OAuth2).
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.
It really really hasn't been. Email is just an enormously massive ecosystem with tremendous amount of variance that anything new will take a long time to adopt and a lot of convincing and proving.
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.
FYI, the above is true for "child accounts", as my son painfully discovered the other day, after his school shoved Gmail down his throat. No IMAP in the settings, or anywhere else, for the next generation of users, not until they are 16+ in my country.
Why would you need to enable IMAP ? It works out of the box. Every non-android platform uses IMAP to access your account (k9 mail, outlook, thunderbird, the iOS/mac email client, etc).
As a former K9 Mail developer I will say that the Google extensions to IMAP for Labels and OAUTH (neither of which are standards) are a pain in the backside that no email platform would have dealt with were it not for the fact they are huge.
(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...
To be fair here, labels are a great feature and the default limitation of a letter existing in only a single folder is a dumb remnant of ancient times.
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.
I don't think so, but you can ask Thunderbird if they are willing to earmark your donation for JMAP specifically:
> 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.
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.
What would be the benefit to using JMAP in thunderbird?
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.
I tried to implement this for quite a while but the ecosystem situation both server and client seemed to be a status of "Weekend Project" rather than a robust implementation. Is there commitment to create a reference implementation etc.
The issue is that there's a single monopoly provider who very much likes forcing all of the client apps to support their proprietary API. When 70% of users are Gmail, and Gmail has a vested interest in not supporting JMAP even though it's better, it's a hard sell for other client apps to invest effort.
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.
> 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.
They lost a huge opportunity. Encryption at rest of emails and E2EE should've been how we built these protocols from the start, here we get a chance to try it and... no, just "self-host" instead.
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.
I don't think so. I mean, I can't imagine what exactly needs to be replaced, and I'm not really getting what that GP quote is talking about, unless it's email metadata (encryption of which is impossible in practice) or full-text search (I always forget about it, as I don't really use it myself)
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.
> This sucks, and it could be solved at the protocol level with JMAP.
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.
In spirit, I would love to self-host, but I have neither the sysadmin skills to do it, nor the time to keep up on security patches, etc.
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.
Self-hosting email is just hugely problematic because of the extensive anti-spam measures by major providers, causing deliverability issues if you don't use a lot of effort to keep your domains and IPs clean. As the saying goes, friends don't let friends host their own email.
I would imagine such a person would heavily script a lot of things and be able to spread their time among hundreds of customers, and I'd get the cheap rates if I'm willing to pick off their menu of preferred software packages for each need, rather than picking my own specific one, for instance.
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.
JMAP is great but is not nearly enough. it would still need some improvements... on the protocols and on the available servers. I experienced slowdowns with Cyrus (which is the most advanced implementation I believe) on complex requests.
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 was hopeful that https://www.nylas.com/ would be the de-facto "adapter" placing a common API surface on top of the major providers and dragging them into a modern-API world. They even had an email client of their own as a proof of concept (forked by one of the original authors as https://github.com/Foundry376/Mailspring - and its reusable core https://github.com/Foundry376/Mailspring-Sync may be interesting to many here). But they've pivoted towards making their API only available behind B2B contracts and opaque pricing, and primarily used for corporate email monitoring and CRM use cases - perhaps because security and privacy considerations are nontrivial. I'm still rooting for them but it's a shadow of what it could have been.
Having WebPush style push notifications is a huge advantage of JMAP. Right now, 3rd party mobile email clients are stuck to polling every few minutes or keeping a connection open.
I'm looking forward to more JMAP adoption, especially on FOSS Android platforms.
The _Fastmail app_, which one might assume is the flagship client, doesn’t work at all offline. So I’m unimpressed. Every other non-Webmail client I’ve ever used, whether POP3, IMAP, Exchange, or proprietary, worked at least to a reasonable extent offline.
The standard looks great, and the IETF publication is a big step, but it’s still caught in the middle of a chicken-and-egg problem between email service providers and OEMs. Even worse, only Apple would have any incentive at all to natively support JMAP on mobile, as Google would prefer you just use Gmail. It would be the exact same problem as trying to get Apple to adopt RCS.
I’d love to see JMAP take off, but I don’t see a way forward in the current market.
More than a year ago, I had posted an "Ask HN: Where is JMAP (jmap.io) implemented or being implemented?" [1] but it didn't get any engagement. The situation doesn't seem to have changed much in the meantime. Fastmail (the main developer) seems to be the only one deploying it on a large scale.
I have a hard time believing that JMAP is good specifically because it's yet to grow much further than Fastmail. I love that it's open, and I'm a long term happy paying customer of Fastmail, but as an engineer I'd be skeptical of JMAP. I don't have the expertise to know if JMAP solves the necessary problems, and there are probably not that many engineers who do as deep IMAP/POP knowledge is somewhat rare at this point.
JMAP was initially developed at Fastmail, but it changed shape quite a bit during the standardisation process at IETF, with significant input from multiple other providers. The end result was definitely the better for it. (In the end, RFC 8620 has two authors listed—one from Fastmail, one from Oracle.) JMAP’s good stuff.
(Source/bias: I worked on Fastmail’s webmail from 2017–2020.)
The problem is Gmail. Google is a bad actor who significantly prefers clients have to support a proprietary API, even though JMAP takes all of the proprietary hacks Gmail built and standardizes them. (Things like snoozed emails, labels, etc. cannot be implemented with IMAP, but can with JMAP.) Supporting JMAP would mean clients that have hacky issues syncing things around labels and snoozed emails could just work, without having to use a proprietary Google API to do it. That alone would be a huge benefit to JMAP being not just widely used, but specifically used by Gmail.
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.
I understand how they got to this point, but I hope you understand that fifteen years ago, Google would've lead the charge to make these things a standard, and today they will sit inside their moat behind their castle walls and ensure even the standard someone else built for them doesn't succeed because openness is harmful to their bottom line.
I do get your point, but I also wonder if this could be the exception rather than the rule. Google still appears very active in setting web standards and contributing a lot of open technology and standards.
I would say that Google is active in setting web standards that help Google, less so setting web standards that help anyone else. Which, for what it's worth, is capitalism, but unregulated monopoly remains a fundamental flaw in the design of capitalism.
Sendgrid has an inbound email webhook which I've used quite effectively. What's great is that you can dynamically map your inboxes and provide any address for your domain.
I’m mystified by one thing about JMAP: JMAP is supposed to support offline clients, but the Fastmail iOS app has no offline support whatsoever. What gives?
Offline is just a matter stable identifiers on the server. It's the client that is responsible for caching the e-mail content on the device.
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.
There aren’t any that go direct to maildir. There is mujmap that syncs to notmuch. I wasn’t able to get it to work the way I wanted, and wrote my own that I’d be happy to share. I’ve been using it for around a month with no issues but that’s certainly not much confidence yet!
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 love what Fastmail does for open source and the email ecosystem writ large — there's even a dedicated macOS client for JMAP https://swiftmail.io (curious when we might see Apple adopt it).
The problem is that it still needs a conversion to classical mail (just now on the server instead of client side) which comes with the problem of braking signing.
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.
The normal MIME based mail format with all it's pain in header encoding, multi part bodies, language and encoding annotations etc.
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).
The protocol is stateless, just as HTTP is stateless¹. This means that every request is handled independently. Pagination is like “please give me page one for the query ‘foo’” followed by “please give me page two for the query ‘foo’”—so if you lost your connection in the middle, you’re fine. By contrast, IMAP is stateful, and pagination can be more like “I’m starting a query ‘foo’, please give me the results” followed by “please give me the next page”, with the result that a dropped connection can leave you stranded high and dry, having to do everything over again if it’s even possible to. (In practice, now-widely-adopted extensions have been developed to avoid this happening. And really this whole paragraph is a simplification of reality.)
—⁂—
¹ 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.
I'm not sure if I understand the claimed benefit of jmap being an open standard. Isn't imap already an open standard? If so, if Gmail adopted jmap and added proprietary APIs to it, wouldn't we end up where we are now?
IMAP is a really difficult and antiquated protocol to work with also. It's responses are in a non-regular grammar (as opposed to JSON), and IMAP server implementations vary wildly.
As a result, properly functioning IMAP clients/libraries are really few and far-between.
The benefits are that (a) JMAP is superior to IMAP in ways that really affect end-users of email clients, and (b) as opposed to other high-performance email protocols, JMAP is an open standard.
> 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.
Would love to see both Microsoft (for exchange especially, but also their free accounts) and Apple implement JMAP. That said, I know they don't have many incentives to do so and that makes me sad.
The query syntax is interesting. A json schema defining an order of operations to perform server side. Looks kind of gnarly tbh.
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.
SQLite have a bunch of features that would allow limiting what you can do in a request, and if you limit the access to a database by the user that puts e-mails in that database this is easily doable.
> Every time a change occurs to data within the user, the modseq is incremented by one and the new value is associated with the changes.
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.
You’re quoting https://jmap.io/server.html#modification-sequences, about a server implementation detail. Clients don’t get exposed to it directly, but deal with opaque state strings given by the server (which might leak this implementation detail to some extent, e.g. if you just stringify the numbers directly, but a client would be wrong to use it that way, and no harm can come if it does anyway).
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.
First they need to get massive email providers to offer JMAP support, and then get clients to support it. Surely this is simply too big a ship to steer.
Google is not going to support this, and isn't that >50% of the market?
They just need an IMAP/SMTP <-> JMAP bridge. This allows (small) providers to add support without much effort and there's suddenly a demand for clients (and vice versa good clients will increase demand for JMAP support).
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 is the other way around: Stalwart JMAP Server is an actual JMAP-native server, then Stalwart IMAP Server is an IMAP4-to-JMAP proxy, allowing you to connect with IMAP clients, and converting that into JMAP.
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.
Oh, that's unfortunate. I had hope for Stalwart, not so much for the Perl proxy.
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.
jmap-perl was only ever a tech demo and somewhat incomplete (e.g. it lacks push subscriptions, and a few bits that could theoretically be supported are stubs), but it’s not actually all that much code—even in fairly verbose Perl and including contacts and calendar support, the entire repository is around 11,000 lines of code (naturally depending on libraries for things like HTTP, OAuth, IMAP, SMTP, CalDAV and CardDAV), and could be shorter.
The problem with the proxy is that to be efficient, I believe the proxy will need to store all IMAP messages in an indexed form on the proxy-side.
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.
It has all the benefit. I don't want to have to worry about IMAP and that's what it allows me to do - with not only theoretical browser compatibility, but a complete complete client library fully ready.
Looking forward to see all kinds of chat, messaging and discussions systems being implemented on top of JMAP. Next generation messaging will hopefully be more open.
email is a simple textual protocol. FastMail is not offering an alternative to that, but an "alternative to proprietary email APIs that only work with Gmail".
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.
> 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.
I see that the specs are defined in 2019 excluding the Websockets spec in 2020. So over 3 years, these specs are implemented almost only by Fastmail. It feels like it is yet another standard [0], which could not be adopted by neither commercial nor open source email servers and clients.
While the xkcd comic mentions 14-15 competing standards, there are only 3 email client standards in wide use: POP/SMTP, IMAP/SMTP, and Microsoft Exchange ActiveSync. POP is wholly surpassed by IMAP in functionality and ActiveSync is proprietary, so we're left with IMAP/SMTP as the only viable universal option.
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.
POP3 is perfect for people like me that download their mail and organize it in local folders on their computer. I'm using Thunderbird and mail filters to move messages to their folder. I backup remotely with duplicity.
I check my mail with k9 on Android, delete uninteresting messages and download on my laptop, maybe only once every two or three days. To reply and send from Android and not to lose my message I configure k9 to Bcc me. I get my message in my mailbox and my filters on Thunderbird will put it into the right folder when I eventually download mail.
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.
I do have a Gmail account because of Android and maybe I self squatted a Gmail account before I had an Android phone. I can't remember.
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.
well the other nice benefit is that since JMAP operates by talking JSON via HTTP over TLS you get to skip a lot of the absolutely bonkers annoying cert stuff, SMTP port issues, etc.
I agree, it really grinds my gears when people use it as an objection to any attempt at improving a standard. People stopped taking it as what it is (a joke) and using it as an actual argument.
I think that the idea is that when there are so many competing standards it's difficult for them to get any meaningful adoption, except for the one or two that for some reason (age?) are already widely adopted. A new standard must be backed by most of the industry to succeed. JMAP doesn't seem to have many chances because the industry is Google and Microsoft with their own products.
I know the idea, but it's usually not 14-15 standards, it's usually like one really entrenched old crusty standard (if you are lucky) or (more likely) emergent glued-together patchwork of hacks.
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.
That's a bit harsh given all the problems SMTP and IMAP have. They are very dated and have some exotic "features". There is not a single mail client that gets everything right!
In other words, “they don’t sit atop the currently-fashionable implementation techniques that are the only thing webshits happen to know.”
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.
JMAP really solves many problems and allows you to do many things that are just not possible with IMAP. Also, IMAP has many ways to (badly) perform the same task, not all supported by all servers or all clients. MIME parsing is not easy to do and there is not always quality libraries available for your language... JMAP solves all of this.
Have you tried to send SMTP email lately? Most residential ISP's block SMTP ports and all the encrypted variants of it.
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.)
Why are you trying to run an MTA on a residential network? I suspect you are confused about how things work. The standard SMTP port (25) is for communication among MTAs and yes, residential networks block it (as they should) as any home PC sending on it is 99.999999999% likely to be part of a botnet. Sending mail from a home PC to the outside world is done by submitting it to an MTA on the SMTP Submission port (587) which your email provider should have given you credentials to. Home ISPs don't block port 587 AFAIK.
You misunderstand the state of the e-mail world. Running an MTA on a residential network for receiving is completely fine.
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.
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.
Two lines from a song I and rjbs wrote but never quite published (set to the tune of Major-General’s song):
> 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.
Speaking as one who has drunk the JMAP kool-aid (I worked for Fastmail for a few years): you sound like you’ve never tried to write an email client, or done much with email in general. Because the conclusions you’re coming to are completely back-to-front.
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've worked in the mail area, though not recently. Twenty years ago I worked on an IMAP4 transport, optimized for wireless, for Windows CE ("Microsoft Mobile OS" or whatever it was called).
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?
> You're comparing developing mail software using libraries for JSON, HTTPS and other pieces, versus doing the same thing while developing IMAP from scratch.
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.
Your definition of email is transparently unreasonable, if you insist it can only refer to what IMAP and SMTP provide. When do you freeze IMAP? Version 1, 2, 4, 4rev1, other? Are SPF, DKIM, DMARC part of “email”?
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.
JMAP is completely unsuitable for server–server message delivery. JMAP is an object synchronisation protocol for working with persistent, per-user resources. None of that is in the slightest bit useful for server–server message delivery: there is no user account, and there are no persistent objects—what you need is purely fire-and-forget. Your scoffing suggests that you haven’t understood what JMAP is.
> JMAP is completely unsuitable for server–server message delivery
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.)
I’m perplexed that you seem to think JMAP is connected with any efforts to disrupt or destroy email. It’s completely the opposite. It’s been developed by people deeply involved in the email space and heavily invested in email being good and useful, mostly people who make their living from providing email services.
Seriously, a lot of what you’re saying just doesn’t make sense and is internally inconsistent.
Amen, all of the actually-interesting features could have been done within the framework that MRC (RIP) laid down for IMAP, without going wholly into “screw line oriented text protocols, gotta be Web
2.0!” bullshit.
I sincerely thought it was when I first heard of it.
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.
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/