That's an interesting protocol choice, especially given the purpose. SMTP is probably the most filtered protocol on residential networks, SMB being a runner-up.

▲

bauruine 3 days ago | parent | next [-]

SMTP isn't filtered it's port 25 that is. And from a short look at the readme it looks like it's using the transmission port 587 which shouldn't be filtered.

	▲	lateral_cloud 2 days ago \| parent [-]
		Any decent firewall these days is layer 7 aware. The port doesn't make a difference

▲

pogue 3 days ago | parent | prev | next [-]

I was thinking this too. I'm assuming it doesn't look like an SMTP server from the outside? Because if it does, that would absolutely land your IP up on many, many DNSbls very quickly if it started getting probed.

Interesting idea though, spoofing other protocols than HTTP/HTTPS are probably a good idea for censorship evasion in countries with incredibly strict national firewalls.

▲

zamadatix 3 days ago | parent [-]

TECHNICAL.md lays it out a bit more, but it claims to be RFC 5321 compliant with a realistic initiation sequence so it should somewhat look like a real SMTP server for the first bit.

Ending up on any DNSBLs shouldn't be a problem unless you have a static home IP you plan on running an actual SMTP server from after this though.

▲

pogue 3 days ago | parent [-]

>SMTP traffic on port 587 (submission) is expected and normal

Any residential dynamic or static IP with this port opened is definitely going to get flagged. Most ISPs already prevent these ports from being open, either by policy or by residential routers.

It would probably very quickly end up on something like SpamHaus's PBL, which looks for this kind of thing.[1]

I would imagine you would also find yourself on Shodan pretty quickly getting hit with constant nmap & login attempts from malicious actors. Spam bots are always looking for insecure servers to send emails from.

I feel like ssh, SFTP, or even a secure DNS server would probably make more sense as something to hide traffic from DPI than an SMTP server.

[1] https://www.spamhaus.org/blocklists/policy-blocklist/

▲

zamadatix 3 days ago | parent | next [-]

Again, unless you're actually planning on sending "real" SMTP traffic to other "real" SMTP servers from your own "real" SMTP server operating on the same address, then getting put on SpamHaus (or other DNSBLs) for having the port open w/o rDNS or etc configured is irrelevant. Like you say, there is a decent chance your ISP just blocks the port anyways and makes such a setup unfeasible though, but that's why the readme says to host this on a VPS which allows the port.

Any time you have any externally open TCP port (home or VPS) you should expect to get scanned to shit by Shodan and millions of other bots. It doesn't matter if it's the default port for SFTP, DNS, SMTP, HTTP, Minecraft, or whatever - all of them are great targets for malicious actors and as soon as the bots detect one open port they'll scan everything on that IP harder. I once forgot to disable certain default enabled login types and failed connection/authentication logging when exposing SSH/SFTP externally and ended up with GBs of logs in just one week.

▲

megous 2 days ago | parent | prev | next [-]

> Any residential dynamic or static IP with this port opened is definitely going to get flagged.

That's not what the referenced website says and it does not make sense at all.

▲

GoblinSlayer 2 days ago | parent | prev [-]

Spamhaus blocks port 25, not 587. If they blocked port 587, they would blanket ban all email clients.

▲

pogue 2 days ago | parent [-]

SpamHaus lists IPs to blocks, not ports.

	▲	bauruine 2 days ago \| parent [-]
		Sure but from your link >The PBL detects end-user IP address ranges which should not be attempting to directly deliver unauthenticated SMTP email to any Internet mail server. All the email originated by an IP listed in PBL is expected to be submitted - using authentication - to a SMTP server which delivers it to destination Means in practice port 25 (unauthenticated) and port 587 (authenticated)

▲

catlifeonmars 3 days ago | parent | prev [-]

What would you reach for out of curiosity?

For me RTP+rateless erasure codes come to mind, but I’m feeling Rube Goldbergy today.

▲

m132 3 days ago | parent | next [-]

All boils down to the kind of DPI you're trying to work around, but generally the most common encrypted or otherwise difficult to process protocols strike me as the most preferable.

RTP isn't a bad choice, especially the WebRTC flavor of it:

- it's UDP; there's no need to worry avoid the TCP meltdown

- it's most commonly used for peer-to-peer and PBX communication; packets going in and out, from and to random IPs are expected

- high bandwidth RTP traffic is normal, so are high irregularities

- it most often carries video; huge room for steganography

- WebRTC makes encryption mandatory

I've come across corporate networks that do block non-intranet WebRTC, however this probably isn't feasible at the Internet scale.

Other good choices are QUIC and WebSockets (assuming your network doesn't do MitM), and SSH, which by default comes with strong protection against MitM and actually has SOCKS5 tunneling built into the most popular implementations (try `ssh -D`). SSH is what some of my friends successfully use to bypass the Great Firewall.

That being said, the shift of client-to-server SMTP from a common part of everyday internet traffic to something rather esoteric may have created some potential for firewall misconfigurations, and those might result in it being passed with minimal inspection. All depends on your particular firewall in the end.

▲

sebazzz 3 days ago | parent | prev | next [-]

I think HTTP web sockets would be an interesting tunneling protocol.

▲

megous 2 days ago | parent | next [-]

You don't need websockets, just Connection: Upgrade to anything you want. You can upgrade directly to ssh protocol and just pass on decrypted data from https socket to local port 22 from then on with no further processing.

	▲	ranger_danger 2 days ago \| parent [-]
		Proper DPI can tell that wouldn't be acting like a typical HTTP stream, encrypted or not.

▲

bauruine 3 days ago | parent | prev [-]

Tor has a transport using exactly that.

https://blog.torproject.org/introducing-webtunnel-evading-ce...

▲

nofunsir 3 days ago | parent | prev [-]

IP over Avian Carriers