[amelius]

> First-contact consent: an unknown sender doesn't get into the mailbox; they land in a "requests" box with their first message visible (like Signal's message requests). You accept, and the thread opens forever. A stranger can knock on your door, which is the essential property of mail, but they can't fill up your living room.

I like this.

Question: can this e-mail specification/implementation also replace direct-messaging protocols (like WhatsApp)?

[TheOtherHobbes]

The unknown request will be buried in spam - a problem we have already, but worse.

And I do not want an infinite thread conversation. I want to be able to split off - and perhaps archive and export - different conversations by topic.

I recently had to some legal things, which included forwarding copies of a certain conversation to a lawyer. This turns out to be unreasonably difficult because email clients quote previous conversations. You want a clean thread of comment and reply about a specific topic. You don't get that.

You do get it on chat services, but there's no option there to create sub-conversations.

If I was redesigning email I would think long and hard about different use cases and workflows and start with an RFC. Protocols are far downstream of that.

[jancsika]

> The unknown request will be buried in spam - a problem we have already, but worse.

I feel like every one of these suggested changes to email comes with a functionally equivalent parody magic trick.

For this one, a magician has two stacks of cards: a tall stack of "spam" cards, and a small stack of "inbox" cards.

The magician moves the stacks apart to make a spot for a new "request" stack.

To start the stack, they pick up five "request" cards from the inbox stack with one hand while subtly pushing the entire stack of "spam" cards with the other hand to spot they made for the "request" stack.

They then pass the five cards they were holding behind their back, revealing them with the opposite hand and finally shuffling them into the now tall stack of "request" cards.

Ta da!

> If I was redesigning email I would think long and hard about different use cases and workflows and start with an RFC.

A magician sweeps 17 sloppy stacks of cards off the table. They then show how the first 15 cards they pick up can more easily be arranged in only three stacks. Voila! Everybody claps.

While the audience members put money in the hat, the pedants stick around and watch the magician pick up the rest of the cards and end up with 18 sloppy stacks by the time the audience for the next show arrives.

Edit: clarification

Edit 2: I forgot this part: "Protocols are far downstream of that." So imagine 8 tiny tables below the main one which somehow end up with more than 52 cards in each of their 17 sloppy stacks.

[BeetleB]

> The unknown request will be buried in spam - a problem we have already, but worse.

Keep in mind that many people around the world already use this solution.

In my case, I give senders a mechanism to go into my inbox without my explicit approval. The server sends them an email with a URL. They follow the instructions, and their email gets whitelisted.

https://blog.nawaz.org/posts/2018/Sep/solving-my-email-probl...

[Ferret7446]

Where are these people? Do you mean "many people" as in a few hundred, representing 0.000% of the billions that use email world-wide?

[tcfhgj]

> You do get it on chat services, but there's no option there to create sub-conversations.

It's called threads - even Matrix has these

[ninalanyon]

> email clients quote previous conversations.

Surely only if you configure them that way. At least I can turn that off in my email client, Thunderbird.

Nina xx

[aboardRat4]

>Question: can this e-mail specification/implementation also replace direct-messaging protocols (like WhatsApp)?

Deltachat

[BeetleB]

I (and many others) do this:

https://blog.nawaz.org/posts/2018/Sep/solving-my-email-probl...

(Not answering your question, but referring to the approach).

[inigyou]

The original Delta Chat literally implemented WhatsApp-over-email.

They've since changed the design so it uses its own protocol and servers instead of email.

[MrGilbert]

> I like this.

Honestly, I'd want this as a default. I wonder if a mailserver can be configure like this. Doesn't sound too hard, does it?

[thesuitonym]

Believe it or don't, most mailservers actually are set up this way, but it's completely invisible to the user: https://en.wikipedia.org/wiki/Greylisting_(email)

Greylisting is not perfect, not even close, but it allows servers to reject huge amounts of garbage mail while allowing new mail from unexpected parties without user intervention.

[dizhn]

It is similar but not the same thing. It does not have anything to do with the email being legit (non spam) or not. It only catches emails that do not do what they supposed to do when they are deferred for a little bit. They are supposed to try again later. (A super nice feature of email which protects you from losing all incoming emails when your server is down for a short time). The reasoning here is hopefully a spam script or software will not implement the standard properly or will skip apparently broken destinations.

What parent wants is also possible and I remember people doing it as far back as the early 2000s. You would basically manually whitelist an email or have them bypass the list (once or always) with something like a key word or token sort of like a captcha which can be shared off band.

[thesuitonym]

It's definitely possible, a few companies do it, and let me tell you: People hate it.

[BeetleB]

I've been doing it for almost a decade. Only one person has complained. I'm surprised by the hoops people are willing to go through to contact me.

https://blog.nawaz.org/posts/2018/Sep/solving-my-email-probl...

[thesuitonym]

I'm glad it works for you, but the overwhelming majority of people are not you, and they hate it.

[ponyous]

Spark email client supports this. It’s great

[PaulRobinson]

"We" tried this in the late 1990s. I remember writing an exim config to do this a couple of ways back in my ISP times:

1. "The recipient will not get this message until you authenticate yourself as a legitimate sender at this URL [...]" - resulted in people never getting mail from no-reply addresses they cared about (banks, e-com, etc.)

2. "This sender has sent you an email, with this subject and this first paragraph. Click here to whitelist, here to blacklist" - created a lot of churn on first setup that users didn't like as a UX

Baking it into the protocol - even now in SMTP and IMAP land - is doable, but would be resisted by email providers who, for example, make their money selling data to marketing agencies. Like, you know, Google, Microsoft, Yahoo...

I've seen other approaches proposed - even at IETF level - over the years, including digital postage stamps (sender pays to send email, your server gets paid, and may reject non-stamped/paying email), but it's the usual network effect: until it becomes widely supported it won't "stick". The stuff that has been adopted has basically been stuff that Google likes, period.

[inigyou]

Baking any of these into the protocol will invalidate it. If there was a standard way to specify a URL to open to whitelist an address, spammers would just whitelist their addresses.

[baudehlo]

It also misses one of the biggest fundamental problems with SMTP: Lack of per-recipient replies. Though you could potentially mandate a single recipient per request. We wrote a plugin to emulate that in Haraka, where you just 400 (temp fail) each subsequent recipient. The downside is some sources just plain don't retry.

[inigyou]

LMTP is a small modification of SMTP with a per-recipient response code - but I'm not sure what it's intended for. It isn't used on the internet. It's sometimes used as IPC within a mail server.

[baudehlo]

LMTP is for delivering to an IMAP (or JMAP) mailbox, generally. We also have a plugin for that. But it has certain flaws for exposing it to the internet (I just forget what they are right now).

[stackghost]

Pretty sure 37signals' email/calendar offering ("Hey") works this way.

[fny]

Is there any reason they shouldn't be the same?

[dzonga]

other email clients/services like Hey etc do this.

at one point Gmail had a service for this - if I remember well - but google being google - I guess it was just a promotion project for someone.

[xd1936]

This is the way hey.com operates. It's nice.