Three failure modes from debugging a mixnet-routed SMTP service

I run n2usenet, nym to usenet, a small web gateway for posting to Usenet pseudonymously.

Outbound delivery goes over SMTP through nym-socks5-client into the mixnet.It stopped delivering, with no useful error anywhere.Debugging it surfaced three separate issues, two of which I think are worth the team’s attention.

  1. nym-socks5-client exits with code 0 when it gives up on its gateway

After losing its gateway, the client logged “failed to reconnect after 10 attempts”, then “assuming the gateway is dead”, and shut down.The shutdown was clean, so systemd saw exit code 0.

With Restart=on-failure, which is the obvious choice, the unit is never restarted.

Mine stayed down for twelve days without anyone noticing.I have switched to Restart=always locally, but I would argue that exiting 0 after an unrecoverable gateway failure is the wrong signal.

A non-zero exit would let standard process supervision do its job.

  1. A stale provider_mix_address fails completely silently

This was the actual outage, and it took the longest to find.

My config.toml pointed at a network requester whose node identity, the part after the @, was still valid and online.But the NR had regenerated its client keys, so the two segments before the @ no longer matched what the node was actually running.

The result: every Sphinx packet encrypted to keys nobody holds.No error, no rejection, no timeout from the client’s point of view.Just silence, on every port and every destination.

The local SOCKS handshake still returns “request granted”, because the local proxy has no way to know.

Comparing my config against description.network_requester.address from /api/v1/nym-nodes/described made it obvious in seconds, once I thought to look there.A warning at startup when the configured provider address does not match what the API reports for that node would have saved me several hours.

I suspect I am not the only one running a long-lived client from a config written months ago.

Futhermore, SPF cannot work over a mixnet.

Not a Nym issue, but it bit me immediately after fixing the above, and it is structural rather than a misconfiguration. Mail leaving the mixnet arrives from whichever exit node handled it. The receiving MTA checks SPF for the envelope sender domain against that IP and hard-fails, because no sane SPF record can enumerate exit nodes.If you send mail over Nym, use an envelope sender on a domain or subdomain that publishes no SPF record at all.That yields a “none” result instead of “fail”, and since SPF does not inherit from the parent domain, a subdomain is enough.

You do not have to weaken the policy on your main domain.

Gab

Hi Gabx,

it is IMHO the best, when offering public clearnet facing Nym services to not use the official nym-socks5-client, nym-network-requester or nym-client, as they rely on third-party gateways, as you figured out. This can be a major dealbreaker when offering public Nym services. These components are only very good when using them locally.

The best is to write your own code and running it with an own nym-node, or only using very reliable gateways, which run 24/7 over many years.

Best regards
Ch1ffr3punk

BTW. I do not understand your SPF etc. mail issue. I use Castor via the Nym Mixnet (NymVPN = App & Wallet Beta, port 1080 settings) with my Hermes email gateway and all works fine.

Hi @Ch1ffr3punk , thanks, that makes sense.

I understand your point that for public clearnet-facing Nym services it is better not to rely on the official nym-socks5-client, nym-network-requester, or nym-client as the
long-term foundation, because they depend on third-party gateways.

They are very useful for local use, but this dependency can become a major reliability risk for a public service.

I also understand that the stronger long-term approach would be to write a dedicated component and operate it with our own nym-node, or at least use gateways with a proven long-term uptime record.

Regards

Gab

1 Like

The N2Usenet SMTP and SPF observations came from live operational testing.

We tested the real deployment path: N2Usenet on pietro vps, nym-socks5-client on 127.0.0.1:11080, the Nym requester on victor vps, and SMTP/TLS delivery to mail2news.tcpreset.net.

We verified the SMTP greeting, EHLO, STARTTLS, TLS 1.3, and successful posts to misc.test.

The SPF issue appeared while observing real mail delivery through the Nym exit path.

The receiving MTA sees the exit node IP, so SPF for a normal sender domain cannot reliably authorize the sending address.

This is why we treated SPF as a structural SMTP constraint not as a Nym software bug.

Gab

Mayby try to set-up your MTA for Nym Mixnet usage as I did with my Hermes email Gateway, which works nicely with SPF, DKIM and dmarc. The Castor client uses TLS for connecting to Hermes, via the Nym Mixnet.