cross-posted from: https://sopuli.xyz/post/12515826
I’m looking for an email service that issues email addresses with an onion variant. E.g. so users can send a message with headers like this:
From: replyIfYouCan@hi3ftg6fgasaquw6c3itzif4lc2upj5fanccoctd5p7xrgrsq7wjnoqd.onion To: someoneElse@clearnet_addy.comI wonder if any servers in the onionmail.info pool of providers can do this. Many of them have VMAT, which converts onion email addresses to clearnet addresses (not what I want). The docs are vague. They say how to enable VMAT (which is enabled by default anyway), and neglect to mention how to disable VMAT. Is it even possible to disable VMAT? Or is there a server which does not implement VMAT, which would send msgs to clearnet users that have onion FROM addresses?
TL;DR you can send emails from .onion addresses if you want, but no clearnet server is going to accept them.
So when you send an email, you can actually put whatever you want in the
fromheader. I could send an email that says from “made.this.up@website.doesnotexist”. The protocol doesn’t care.Do you know who does care? The email server you’re sending messages to, because spammers and scammers love to try and send email with fake
fromaddresses.So, there’s an entire verification system in place that involves looking up public keys from the website that the email claims to be from. (this is a gross over simplification. Look up SPF, DKIM, and DMARC for more info). The problem is you can’t even reach
.onionsites from the clearnet to do the lookups. So no email servers would be able to validate your address is legitimate and so would drop it as spam.Do you know who does care? The email server you’re sending messages to, because spammers and scammers love to try and send email with fake from addresses.
The receiving servers do not generally care what’s in the FROM field. They care that the sending server they are connected to is authorized and has their SPF, DKIM, and DMARC shit together. It’s not for the receiving server to control the email aliases of individual senders. Some rare over-zealous servers will look at the FROM field and expect the domain to match but if I encounter that, the collateral damage is what it is. I can always still decide from there whether it’s worthwhile to go through extra hoops.
That mismatch between DMARC verification domain and the domain of the “from” header is called DMARC Alignment. Any modern spam filter is going to mark unaligned messages as spam. Especially if one of the domains is completely non-routable like .onion.
And even if you sent the email and it got through with your .onion address, no one would be able to reply to you because the replying mail server can’t even look up the MX record for your .onion domain.
I’m fine with all that. I’ve mostly abandoned #email anyway because I do not accept the terms Google has imposed on the world. I send most messages by postal mail when recipients have only exclusive and restrictive receiving options.
The inability of the recipient to reply to an onion address using their normal service is actually part of the idea. I would not want a gmail user to be able to use gmail to reply, for example. While Google drags people into their walled garden, I’m happy to exert pressure in the opposite direction.
(edit)
If I were to send a msg to gmail user in a way that they could simply reply from Google, then I become part of the problem by reinforcing the use of Gmail and helping Google get fed. That’s not going to happen. It’s a non-starter.
How do you expect to receive replies from clearnet users, or are you okay not receiving replies?
Also most mail hosts these days toss emails that dont match dmarc/dkim/spf, which would be especially hard to do for an onion email
How do you expect to receive replies from clearnet users, or are you okay not receiving replies?
Indeed that’s the idea. If you’ve ever received a message where the sender’s address is “noreply@corp.xyz”, it’s similar. But in fact the onion address is slightly more useful than a “noreply” address because the responder would at least have the option of registering with an onion-capable email server to reply.
Imagine you want to email a gmail user. You can ensure that the message contains nothing you don’t mind sharing with a surveillance advertiser, but you cannot generally control what gets shared in the response. An onion address ensures that replies will be outside of Google’s walled garden, for example. That’s just one of several use cases.
Also most mail hosts these days toss emails that dont match dmarc/dkim/spf, which would be especially hard to do for an onion email
Those are server to server authentication protocols, not something that validates the functionality of a sender’s disclosed email address. Otherwise how would a bank send an announcement from a “noreply” address?
Because dmarc, DKIM, and SPF validate the domain against the sending server, not the address.
When i send from noreply@ at work, it passes dmarc, DKIM, and SPF, because the recipient mail server validates the message came from an authorized mail server for the domain (mosty based on dns entries).
Without that validation, you can certainly still send emails, but most clearnet mail hosts will drop your messages. Google, Microsoft, and yahoo at the bare minimum will
The server is checking that the EHLO domain matches that of the IP of the sending server. Whatever is in the FROM: field is entirely irrelevant to that. The RFC even allows multiple email addresses in the FROM field. It’s rarely practiced, but it’s compliant. So if you have FROM: bob@abc.com, bob@xyz.onion, bob@xyz.org, are you saying the receiving server would expect the domain of all FROM addresses to match that of the sending server? What happens when a sender has a gmail account but uses a vanity address? Instead of bob@gmail.com, he has bobswidgets@expertcorp.com. Are you saying expertcorp.com ≠ gmail.com, so the receiving server will reject it? I think not. Google offers the ability of their users to use an external address last time I checked.
That is 100% what im saying, yes. The sending server needs to sign all messages with a private DKIM key where the public key is in a dns text entry. Then the reverse dns lookup for the mailserver needs to match the SPF txt record. Then your DMARC record has to match the dkim and spf settings.
Ive set this up for exchange at work as well as my own personal mailserver, which is just a debian server running postfix and dovecot.
When you want to use gmail as a mailserver for your own domain, you set these three things up so that your messages arent all blocked.
Keep in mind, you do not need these to simply send and recieve messages, but if you want to interact with the rest of the world you do. Email is too easy to spoof, so everyone has agreed on these protocols for authenticity.
That is 100% what im saying, yes.
Okay, so AFAICT you’ve not said anything that prevents individual users from using an onion FROM address, so long as the sending server is authorized via all the shitty spf, dkim, dmarc, dane hoops. This is what I’m after. In fact, I’m even less demanding. I don’t care if a service provider doesn’t bother with dkim and gets rejected by some servers. Email is in such a broken state anyway… I just need the option to set the FROM field to an onion address. The reason my own server is insufficient is the residential IP is very widely rejected.
No you can totally modify mail headers anytime you want to, just be prepared to get mail rejection if you’re not following current mail security best practices.
I’d recommend just renting a cheap vps from vultr or something, then you can setup your mailserver to send from anything you like. That’s how my mailserver works. I pay like $3 a month, and its plenty of space for a single user mailserver (i have like 3 mailboxes)
I did go through the work to setup dkim/dmarc/spf. Took a weekend, but wasnt too bad. My mail is received by gmail yahoo and Microsoft. I imagine doing the same with onion addressing would be complicated.
Maybe i need to further clarify that none of this is in the email RFC. Email is very old. These are new standards that everyone has agreed to on top of the RFC
I’m not surprised. Google took an anti-RFC posture when they broke email and brought in their own rules under the guise of anti-spam (the real reason is domination). The whole point of RFCs existence is interoperability. That was broken when servers reject RFC-compliant messages.
I’m not interested in bending over backwards to accommodate. Satisfying Google’s dkim reqs requires the server admin to solve a CAPTCHA. That’s a line I personally will not cross. So at the moment I simply do not email gmail users (or MS Outlook users, same problem).
