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.

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

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 [email protected] at signup, no errors, but will not let you login saying, Email Not Found. You have to login with [email protected] 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:

https://www.fastmail.help/hc/en-us/articles/1500000277942-Ca...

Fastmail supports both [email protected] and [email protected]. I use the latter precisely to avoid the problem of sites that don't play well with plus addresses.

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.

I (with self hosted config) went a step further and made mail+<tagname>@domain.com ones go into a tag/<tagname> subdirectory

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/

which, now that I know about, I may start using.

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.

Ideally it would be {keysigned_string}@{yourname}.{yourdomain}

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.

are you aware that comments are a thing in email addresses ?

john.smith(comment)@example.com

there are also tags

[email protected]

neither of these require any DNS or server muckery and _should_ be supported by major mail hosts.

Of course, who knows how many random half-assed email validation things people have in their forms that'll prevent you from entering them.

Yes, but many email marketers know this trick and they just strip out the comment or tag, or else make you give them an address that doesn't have it.

Even worse: Some of them happily accept such addresses, but some time later, silently drop messages to you while claiming that they were sent.

The obvious solution would be to use [email protected] and treat [email protected] as a semi-spam folder

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)

And spammers will happily remove those bits from the address.

Comments aren't semantically meaningful, anyone can strip them out without changing the meaning of the email address.

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.

Anyway, just ideas for now...

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 :-(

I think this would work, question is what’s the market and does the product fit? If there’s a (potential) user base I’ll jump in a build with ya!

I think the market is:

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

Rather than start from scratch, build cake slices to test the theory out. Look at something like OPA, it provides a generic policy language with a pluggable framework. You could extend postfix if it is not supported and then implement the policies you described. Then look for market fit and pivot as necessary

I have nothing going on right now and looking for things to fill the void. Let’s start a google doc and build an mvp. Worst case, we have a GitHub repo with our names on it :D

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.

* * *

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

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.

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|[email protected]> is a valid email address with unique code part.

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

Simple but genius! I love it :-)

Yep -- I wasn't thinking of business cards for this, but something like this would be required 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.

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.

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 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 the pass the key to spammers the emails will appear to come with Lyft.

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.

> 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?

That's why he wrote it is probably not possible. Per-recipient email is probably best you can get

Under current email protocols, 100% agreed. If we get to define our own RFC from scratch then much more of this becomes possible under a single email.

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

Sounds functionally equivalent to a whitelist of domains you accept from?

With much more specificity and control, and automatic.

There is a french company named mailinblack [1] that does this. They protect administrations in this way.

[1] https://www.mailinblack.com/

> Sounds like the big claim here is that it is faster.

IMAP worked over 2400 bps modem connections; we now have multi-megabit connections.

How much faster is JMAP over IMAP and what makes it faster?

In their demo video they show an inbox rendering much more quickly, but don't give specifics, so ¯\_(ツ)_/¯

The simplest hack I can think of is:

* Making a wildcard email address for domain, say @example.com

making a filter that only allows [email protected] (or [email protected]) 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 [email protected] and then received email from [email protected], that wouldn't receive the same sort of blackholing as an email using the same token but from *@sospammy.com

If it was new protocol the XMPP approach would most likely be saner.

Which is "if I don't put it on my contact list you ain't getting thru". The invite spam is far easier to handle than message spam.

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

Can you describe (or point me to the docs) how 1 works? Do they generate custom email address extensions, or...?