This is not a great idea if you have a public profile connecting your username to your email because someone can hack your email.

But you not knowing your password doesn’t hurt your security as far as I can tell.

Your login information can be gained via keyloggers, network sniffing, phishing scams, malware, malicious employees, and all sorts of other methods..

This is why two-factor authentication is so important, to help prevent your account from being compromised in the event that your username and password is.

The way I see it, not knowing your password removes some potential threats around managing that password incorrectly, at the cost of increasing the risk of losing access to your account if the recovery mechanism doesn’t work.

It offers some extra security, but very little. It's the digital equivalent of locking your back door but not bothering with the front door.

The comment I originally responded to seemed to think so.

The username isn't supposed to be a secret, social engineering will most likely be very easy.

A sufficiently large random unknown password is actually significantly less likely to be brute forced than the service itself is to be exploited.

So you would have addresses like:

[email protected]

It would only be for receiving.

I know that there are lots of options already: 20 minutes mail, [email protected] or just a catch-all. But this could at least provide somewhat end to end encryption.

Plus it can allow sending and receiving of email and files, if you so choose.

I'm serious but my todo list is quite long.

I was thinking about dedicated application on phone for it instead of regular mail client. Mainly to provide easy interface to manage big amount of accounts, banning hosts etc. Also then the app could just use service like Google's Firebase Cloud Messaging. That would wake my app and then it would get a message. I hope that it is fast enough that a sending SMTP server would not timeout.

One downside has traditionally been that backup MX servers were generally much less stringent in their connection level spam filtering/blocking (since the downstream server is generally responsible for that, and they may be a backup server for multiple downstream servers), so it became common for spammers to send directly to lower priority mail servers to take advantage of this and bypass a lot of that active filtering at the eventual destination. Expect a lot of spam to queue up.

In your case, you actually would control the backup MX and the eventual destination (if it indeed is a separate SMTP server), so that's less of a problem. You could just put a pretty harsh timer on the queued mail, and throw it away after 24 or 48 hours. Then again, you could probably do all this almost identically by replacing the SMTP server run on the client device with an IMAP client, and just have delivery end at your server.

Nowhere near as inconvenient as it sounds - It is the sort of service that you would rarely log in to. Mainly when setting up a new server or adding a third party service to your list of environment variables on your server.

I can see that for a service that you would use several times a day (Twitter etc.) then it would be a major PITA.

Well, even then, it depends on how long sessions last in combination with your browser cookie policy. How often do you authenticate your HN account?

Even EnvKey that I mentioned above has a session cookie of some sort - I can usually use the app for several days after logging in, even if I close the app - but after that I am prompted to instigate the email with my unique login key.

It works really well for most users although it does have some quirks.

If your account name and associated email is known, it's not really better than a username and password (except that it's delegated to what should be one of your strongest accounts that you protect more diligently), but if the email is not generally known for that account name then it's extra identifying information that must also be known to access the service account.