Support SMTP Proxy Services

[fpietrosanti]

In order to foster the developer of an Internet-to-Darknet diffusion, this ticket is to brainstorm the possibility to implement within Tor2web also an SMTP Proxy to let TorHS receive emails from the Internet to their internally running TorHS system.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/14807171-support-smtp-proxy-services?utm_campaign=plugin&utm_content=tracker%2F318575&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F318575&utm_medium=issues&utm_source=github).

[fpietrosanti]

The service should accept email for blahblahblah.WHATEVER.TLD .

Any user must be able to configure the Tor2web SMTP proxy as their MX with THEIR own domain.

The proxy will just strip the DOMAIN and TOP LEVEL DOMAIN part and will forward the connection to the SMTP server (running on TorHs) present in the RCPT TO header.

The RCPT TO format must be strictly parsed as USER@TORHS.YOUROWNDOMAIN.TLD .

The server must configurable to reject email destinated to the Tor2web configured domain.

Example: Server: www1.tor2web.org MX domain: blahblahblahblah.mypersonaldomain.tk Destination email: george@blahblahblahblah.mypersonaldomain.tk

In that situation the SMTP proxy will actively forward the SMTP connection in realtime, without storing it to the disk (no store and forward), to blahblahblahblah.onion:25 TCP port .

The RCPT TO address will be translated from george@blahblahblahblah.mypersonaldomain.tk to george@blahblahblahblah.onion .

The inbound connection has to be TLS encrypted, refusing any kind of SMTP exchange without TLS encryption.

It would be useful if this service, other than enforcing TLS on Internet-SMTP side, would also look at the content of email and only forward email that contain OpenPGP encrypted data.

That way the liability of the Tor2web node operator is highly reduced and LEA will know that it make no-sense to force a Tor2web operator to intercept email in transit.

[funzoneq]

Not storing e-mail will cause undeliverability if the blahblahblahblah.onion:25 address is temporarily unavailable.

Also what does the return path look like? Getting inbound mail via a proxy is relatively easy. However returning via tor is not an option, as almost all tor exit nodes are on an e-mail blacklist. The alternative would be to directly send, but that would uncover the actual address of the hidden service.

[fpietrosanti]

@funzoneq undeliverability is only if the answer will be SMTP error "550", but not if it will be 450 (retry) .

Tor2web is stateless and without any queue. Having to store something to the disk would provide additional liabilities and risks.

Regarding the return path, i think that this is outside the scope of what Tor2web can do. Tor2web only allow inbound connection between internet and Tor Darknet.

Outbound SMTP connection will be something up to the email server administrator to decide what/how to do it.

What do you think?

[tomrittervg]

The tor2web SMTP server would have to send immediate bouncebacks if it could not reach the Hidden Service. What I wonder about, is if connections to a HS are reliable enough that the tor2web node really does store the mesage for seconds only (circuit setup) or if the HS can't be contacted, if the tor2web node will need to store it for 5-30 minutes to retry it before 'giving up' and sending the bounceback.

The onion address that ultimately receives the email and has a client who replies (or sends a bounceback themselves) will be the folks who have to figure out how to get their email out to the real Internet's SMTP servers without running into the SMTP blocks on Tor exit nodes. That will be a hard problem.

(It seems that remailers tend to fly in under the radar of these blacklists because people aren't actually using them for spam - I think because they can't handle the volume spammers need.)

[fpietrosanti]

@tomrittervg mmmm, while i agree that would be more reliable i think that's better if tor2web does not handle a queue (for implementation simplicity) and does not write email data to disk (for paranoid purposes and to keep the current stateless design of tor2web).

However it would make a lot of sense to have different kind of error depending on the issues encountered like: a) TorHS not found in directory (host not found) b) TorHS connection timeout (host exists but connection timeout) c) TorHS connection refused (host exists, is up, but SMTP port is closed) d) TorHS connect but remote SMTP server gives Error code XXX

I think that: a) need to give back 550, fatal error b+c) need to give back a 4XX, non-fatal error (the remote server will retry) d) just transparently forward the SMTP error

What do you think?

Regarding "outbound email", i think that this is something that will need to be fixed by: a) the end-user (he can use an outlook.com email account with authenticated SMTPS over Tor, it works, with a different From sender authorized) b) the mail service provider (he can have some outbound relay somewhere)

[tomrittervg]

I do not think the first one would be feasible, and the second one I don't think would work =P

Fir inbound mail, what you're talking about is recieving a message over SMTP from a client, and then delaying your response to that client until you a) lookup the HS, b) build a circuit to it, c) create a TCP connection, d) translate and send the message you just recieved over this SMTP link. That would require major source code level changes to the mailserver you're running. I think a much simpler architecture is to feed all incoming messages into a ramdisk-based queue like the mailserver is built for, return a normal response code to the client, process the messages via python, and then do (a)-(d). If the message succeeds, yay. If it fails, send a bounceback. That bounceback can contain detailed explanation of the failure you recieved, and those error codes and explanation will be given to the user in the bounceback. The user would never see them in the SMTP protocol.

My thoughts on 1 minutes vs 5 minutes vs 30 minutes was how long to keep the message in queue and retry contacting the hidden service.

While you could build it your way, you should first confirm that clients will sit around for 30-90 seconds (or more) to recieve a SMTP response to their mail request. Then you can confirm you're willing to dive into the source code of exim or sendmail or lamson or whatever and modify it to do this.

For 'outbound' email - that is, the user whose email is user@blahblahblahblah.onion wants to send a reply. Well if they used an outlook.com email address (instead of their .onion) they certainly could reply easily. But then why bother recieving email at blahblahblahblah.onion? Why not just use this outlook email address?

I think what you want to do is when user@blahblahblahblah.onion wants to reply or send an mail to tom@ritter.vg, have them set a Reply-To address of user@blahblahblahblah.tor2web.org, and then they connect to their SMTP server (which is blahblahblahblah.onion), authenticate, and queue up an email message. Then, blahblahblahblah.onion reaches out through tor, to the ritter.vg mailservers. I'll recieve the message, and if I click Reply, it will go to user@blahblahblahblah.tor2web.org. (If I copy and paste the email, my mailserver won't be able to resolve .onion of course, but thems the breaks.)

The hard part there is getting ritter.vg's (and all mailservers) not to reject the email just because it came from Tor.

Maybe, and I'd actually want to talk to some anti-spam people at google if I could find them, what could happen is blahblahblahblah.onion could give tor2web.org a DKIM key to put in the DNS for blahblahblahblah.tor2web.org, plus tor2web.org publishes a SPF record for blahblahblahblah.tor2web.orgsayig "No really, email may legitimately come from any IP address on the interenet". Now when blahblahblahblah.onion connects, through tor, to mailservers like ritter.vg it actually lies, and says this email is coming from blahblahblahblah.tor2web.org. The mailservers go "Oh really? You're not spam? Let me check..." and they see that the SPF record checks out, and that the DKIM signature is valid. So it doesn't get flagged as spam. And the nice part is the email really does appear to come from blahblahblahblah.tor2web.org so I can hit reply, or copy/paste, and it all works out.

One concern there is someone may come along and say "You're cooperating with this Hidden Service by inserting their DKIM key. That's a stored piece of data, that's not proxying data." Maybe the answer there is to proxy the DKIM request key to the hidden service?

[fpietrosanti]

It would be useful if this service, other than enforcing TLS on Internet-SMTP side, would also look at the content of email and only forward email that contain OpenPGP encrypted data.

That way the liability of the Tor2web node operator is highly reduced and LEA will know that it make no-sense to force a Tor2web operator to intercept email in transit.

[moba]

I am interested in hosting such a service on onion.to. I don't think it should become part of Tor2web, but rather be a separate thing.

I would configure Postfix to accept incoming mail for *.onion.to, and use a milter to reject non-PGP mail. How would you process the spool and forward mails to the respective .onion? Anyone interested in writing such a thing that picks up mail from the spool?

I don't care so much about (temporarily) storing the content. In US law, see http://www.law.cornell.edu/uscode/text/17/512 section b.

[fpietrosanti]

@moba a friendly hacker told me that within 2 weeks time (his holiday period) he is going to work on the development of this kind of extension for SMTP proxying logic. I agree that the SMTP proxy service should not probably be runned on the same machine as the Web proxy service run. If it will be Tor2web software it will be easier, with no system integration or configuration to be kept/handled.

Inshallah by my 33' birthday, i'll have this feature as a gift! :-)

[cyphunk]

Many years later I'd just like to add that the ability to host a mail server and set the MX on a domain to a SMTP2TOR proxy would not just be for anonymity. In fact perhaps a more popular use would be for hosting one's mail on their own server. Tor's NAT traversal makes self hosting easier. In this use case sending out via a different SMTP server which would de-anonymize the host isn't a problem.

I would advocate for supporting such a use case because it add's public utility to Tor as a service network, in a manner that could for many become indispensable if maintained for some time.

[fpietrosanti]

@cyphunk Do you want to implement some basic support for Tor2web smtp proxy? :-)

[cyphunk]

@fpietrosanti actually I'd love to. I visit the topic every few years. Perhaps one of these times I'll have the time to play with the idea.

[fpietrosanti]

@cyphunk If you wish to have a look at Twisted SMTP Server https://twistedmatrix.com/documents/current/_downloads/emailserver.tac it shouldn't be too difficult to enable StarTTLS by policy and then forward to a remote Onion TLS server. The only constraint that shall be taken into account are:

• Avoid buffering (to avoid twisted to buffer a 100MB message, it shall send the tcp buffer in "streaming") to the upstream SMTP server
• Validate that the email address will be the in the format george@blahblahblahblah.mypersonaldomain.tk so that it can be translated immediately to george@blahblahblahblah.onion
• Check that the message only contain OpenPGP encrypted email (no plain text one)

[cyphunk]

I should be clear (so as to not create expectation) I cant work on it at the moment :/ But i appreciate the direction. Should help in the future if myself or others have time to work on it.

[virgil]

If we're going to do this for SMTP it makes me wonder if there's a more generic solution for any port.

-V On Tue, 25 Aug 2015 at 21:20 Nathan Fain notifications@github.com wrote:

I should be clear (so as to not create expectation) I cant work on it at the moment :/ But i appreciate the direction. Should help in the future if myself or others have time to work on it.

— Reply to this email directly or view it on GitHub https://github.com/globaleaks/Tor2web/issues/81#issuecomment-134602050.

[evilaliv3]

sure there is @virgil and it's simply implementing a TCP proxy.

[fpietrosanti]

@virgil I think that the SMTP proxy must be an SMTP proxy because of the need to use STARTTLS within the SMTP protocol. However a generic TCP proxy can be done with the SNI approach discussed with @donnchac on #252