"No better program to access email from anywhere than a browser. Have you heard about MUA-s?"

You understand the difference between accessing email and reading email? I'm talking about JavaScript accessing email, and acting on it. You're talking about a human being reading a message.

"Special mails should be used for authentication which would specially handled by the browser accessing your mailbox. This is abusing the mail protocols in my opinion."

We're already sending registration emails and password reset links. We currently have a system where the end user has to read an email and click a link in it. My suggestion would just allow us to skip the human part and let the JavaScript read it directly, with a perfect fallback built in for people who don't have their browsers configured to have access to their mail.

"Certificate based auth does have something to with this: an existing, partially supported solution for auth with no magic needed and no need to reinvent the wheel, with hacks and extra complications."

Even with certificate based auth, you'd still end up having email involved with registration or password resets in some fashion.

You know, there is one thing I don't ever want to happen: to have JS running in my browser access to my emails and act upon that automatically.

This has way too many security implications which don't make it a reasonable idea:

1. If sites can set up such action, then for that (I don't trust anybody's site to have any form of Access to my emails, except my mail providers per se),

2. if the browsers supply these actions, then for that cause (it would be exploited, or if it would be perfectly secure then it would also be perfectly useless).

What security implications are there for a tab with the example.com origin to be able to read emails that you receive from an example.com email address? If it's behind a user access prompt, and the API requires that you specify the sender and recipient to monitor for? E.g:

  navigator.notifyOnEmail({
    from: 'sender',
    to:   'recipientaddress',
  }, (email) => {
    /**
     * This callback is run whenever a new email
     * arrives from sender to recipientaddress.
     * Assuming the browser has access to the
     * recipientaddress account via IMAP, and
     * assuming the sender address matches the
     * browser origin and the user has given the
     * origin permission to do this.
     */
  });

This leaks some information about the user's email address. If you suspect one of your users is (say) "[email protected]", you can email [email protected].

Then, call notifyOnEmail({from: "[email protected]", to: "[email protected]"}) in every session on your site.

If Jean happened to be logged in, you've just identified her.

Spam filters would probably stop you brute-forcing the address of every visitor, but they might not help if you already have a good guess.

Requiring user approval will stop most of this, although it won't block queries like "are [email protected] and [email protected] the same person?".

> that you receive from an example.com email address?

How do you know that it really was from that email address?

Why do you think that matters? The sending site knows if it sent an email. The only thing it doesn't know is if you received it.

For an account registration or password reset email, the sending site will typically send you an email with a link inside it containing a secret token. If the JavaScript reads that it received an email with one of those links in it, it will post that information back to the server so the server can complete the function it started (account registration or password reset). Obviously, at that point, it will know if the token it was passed was the one it sent.

[edit] Also, as this system is being implemented from scratch, it could easily be decided that emails which don't pass DMARC for example will simply be ignored. Although I argue that is not necessary.