I'm toying with an idea of a SMTP proxy service so you could have a SMTP server on your smartphone. I would like to use Let's Encrypt certificates so my service would be just a dumb pipe.
Then you could register using random email for every service. SMTP would handle signal outage as message would be eventually received. Or one could set up secondary SMTP server in DNS.
I would like to give an option of subdomains handling. So every email would be on different subdomain. That would make blocking easier.
So you would have addresses like:
foo@mjlptle3sq.emailproxy.net
It would only be for receiving.
I know that there are lots of options already: 20 minutes mail, user+whatever@gmail.com or just a catch-all. But this could at least provide somewhat end to end encryption.
The idea of having easy to use single-use email addresses is good, but I don't think it's practical to run an SMTP server on a smartphone (you need the relevant ports open and forwarded through various NATs) and email anonymisers are already banned from signup on many sites, so *.emailproxy.net would quickly be, too.
If you're serious about this, consider running UUCP as the mail transport. It can be tunneled through SSH easily (or have TLS applied to it with something like stunnel), allows either end to initiate a transfer of data (assuming open ports), handles dynamic network addresses easily, and will likely be a much smaller drain on mobile phone batteries.
Plus it can allow sending and receiving of email and files, if you so choose.
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.
Backup MX servers do this every day. One of the commonuses of differing MX priorities is to provide a backup MX server to accept mail on the behalf of your mail server if it is overloaded or unavailable. This has been used in the past to provide reliable mail transport to mail servers that are not always connected.
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.
So you would have addresses like:
foo@mjlptle3sq.emailproxy.net
It would only be for receiving.
I know that there are lots of options already: 20 minutes mail, user+whatever@gmail.com or just a catch-all. But this could at least provide somewhat end to end encryption.