YAyamrzou·Sep 14, 2022Submission
Onionmx: Mail Delivery over Tor
19 points · Open discussionehloonion
onionmx
Ruby2017–2022
ehloonion / onionmx
onionmx
Onion delivery, so delicious
5Distinct people
6Mentions
0Explicit recommenders
208GitHub stars
What to know before exploring
What it is
Onion delivery, so delicious
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year6 dated mentions
Observed mentions: 2017-01-20 11:56:19 UTC to 2022-09-14 23:22:56 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
6 sourcesGreat question! onion vhosts (user@foobar.onion addresses) don't need that, as long as your client can resolve onion addresses (Gajim/Conversations have good tor integration, otherwise Tor's AutomapHostsOnResolve will do the trick systemwide but in that case your client may complain that the domain doesn't support TLS or with a wrong certificate).
"Advanced" connection settings is required when the vhost you are connecting to doesn't match the hostname you need to reach on the network. For example, if you're reaching your server over a VPN/SSH/IPSEC tunnel.
Another example is if you wish to login as user@foobar.com by reaching foobar.onion. This is useful if you want to be part of the broader Jabber federation, in which not every host supports federation over onion addresses (i'd be curious to make stats about that) but it still gives you
Read the rest
the security guarantees of Tor when reaching your server (though not for server-to-server connections).
Onion name discovery for automatically upgrading to onion routing when Tor is available client-side is not yet specified within the XMPP ecosystem. Onion discovery in the HTTP ecosystem is usually done via Onion-Location HTTP header (HTTPS only), in the email ecosystem they use _onion-mx DNS SRV records: see https://gitweb.torproject.org/tor-browser-spec.git/tree/prop... and https://github.com/ehloonion/onionmx/blob/master/SRV.md respectively
Implementing something similar XMPP side would be easy. Prosody already has a community mod_onions, but currently only supports a static map of hosts to their onion addresses. It could use some love: https://modules.prosody.im/mod_onions.html
Another problem we face from a UX perspective for onion services is that currently XMPP server implementations are very strict about which node/resource messages are intended for, and to my knowledge none support aliasing systems as we have in the email world. In this specific example application of aliases, there's currently no way (that i know of) to have the same account across .org/.onion domains and having servers to know it's the same account in a federated manner, eg. to prevent you from adding the same person twice to your contact list.
All in all there's interesting challenges and none of them is really hard so if you'd like to get involved or just let us know about your ideas and expectations, feel free to drop by xmpp:privacy@joinjabber.org?join
Yes, email providers must see sender and recipient email addresses, and corresponding server names (and how to reach them). However, if you and your correspondents use ~anonymous email accounts, none of that get's tied to meatspace. And if you're really paranoid, you can have multiple accounts, and mix them up.
About 30 "activist" email providers exchange messages via Tor onion addresses.[0,1] But you still need to trust your provider, unless you trust your OPSEC enough.
Back in the day, we had Mixmaster remailer nyms, with PGP and message delivery to alt.anonymous.messages. You downloaded all messages, and then selected based on public key. But not enough people ever used it, so the anonymity space was tiny. But there is still activity. I recently came across something ~new on Github, but I don't remember exactly what.
0) https://github.
Read the rest
I'm not sure MX records would work without either modifying SMTP servers or using Tor in transparent proxy mode.
Postfix, for instance, has [transport maps](http://www.postfix.org/transport.5.html), but those let you pick a transport based on the email domain, not the MX host.
Right now, some people use [onionmx](https://github.com/ehloonion/onionmx), which maintains both a [static mapping](https://github.com/ehloonion/onionmx/blob/master/sources/map...) from domains to onion services, and a dynamic one using [SRV records](https://github.com/ehloonion/onionmx/blob/master/SRV.md).
In Privacy is Power: Why the fight for privacy mattersOnionmx: mail delivery via tor
4 points · Open discussionThis is a great idea [your edit]!
And its already being developed by some (not protonmail though). See https://github.com/ehloonion/onionmx
In Introducing ProtonMail's Tor hidden service