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.
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/