[HN Gopher] Show HN: SMTP Tunnel - A SOCKS5 proxy disguised as e...
___________________________________________________________________
Show HN: SMTP Tunnel - A SOCKS5 proxy disguised as email traffic to
bypass DPI
A fast SOCKS5 proxy that tunnels your traffic through what looks
like normal SMTP email, bypassing Deep Packet Inspection firewalls.
How it works: - Client runs a local SOCKS5 proxy (127.0.0.1:1080) -
Traffic is sent to server disguised as SMTP (EHLO, STARTTLS, AUTH)
- DPI sees legitimate email session, not a VPN/proxy Features: -
One-liner install on any Linux VPS - Multi-user with per-user
secrets and IP whitelists - Auto-generated client packages (just
double-click to run) - Auto-reconnect on connection loss - Works
with any app that supports SOCKS5 Tech: Python/asyncio, TLS 1.2+,
HMAC-SHA256 auth GitHub: https://github.com/x011/smtp-tunnel-proxy
Author : lobito25
Score : 122 points
Date : 2026-01-07 00:30 UTC (22 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| thedougd wrote:
| Quite a few things use STARTTLS. I imagine the same technique
| could be applied to those other protocols, giving users some
| options as they fight hostile networks.
|
| Clever
| montyanne wrote:
| Just curious - how much of this was AI generated? The readme
| has crazy emojis & the code was all checked in at once, which
| is usually my telltale for these kinds of things. Didn't see
| anything crazy in the source files.
|
| I think its polite to indicate AI agent usage in security
| related projects like this since they can have huge holes if
| they're just being vibe coded.
|
| -- Edit: Intended to post this on the board root, sorry.
| zamadatix wrote:
| It's a fair question but I had a bit of a chuckle at the idea
| having a shit ton of emojis in your GitHub readme was the
| first flag it might be AI. Mostly because I always assumed
| the opposite - that GitHub readmes were a big part of the
| emoji ridden listicle training data (the other being slop
| "news" site/social media listicles) for AIs in the first
| place. After all, they are decently well written and come
| with grabbing the code to train from anyways.
| userbinator wrote:
| Before the rise of AI, I had not seen much GitHub content
| with emojis at all, much less overused; I suspect their
| source is actually the latter of what you noted. Either
| way, it's a negative signal.
| jeroenhd wrote:
| High emoji use is something I've noticed a certain
| generation/subgroup of developers just default to. Keeps
| things informal/quirky. The AI had to steal that style from
| someone, after all. This repo is actually very low on the
| emoji side.
|
| Looking through the code itself, I can't tell if it's AI
| generated or not, but I wouldn't assume the use of emoji
| automatically mean AI wrote the text.
| m132 wrote:
| 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.
| catlifeonmars wrote:
| What would you reach for out of curiosity?
|
| For me RTP+rateless erasure codes come to mind, but I'm feeling
| Rube Goldbergy today.
| sebazzz wrote:
| I think HTTP web sockets would be an interesting tunneling
| protocol.
| bauruine wrote:
| Tor has a transport using exactly that.
|
| https://blog.torproject.org/introducing-webtunnel-evading-
| ce...
| megous wrote:
| 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.
| m132 wrote:
| 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.
| nofunsir wrote:
| IP over Avian Carriers
| pogue wrote:
| 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 wrote:
| 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 wrote:
| >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 wrote:
| 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.
| GoblinSlayer wrote:
| Spamhaus blocks port 25, not 587. If they blocked port
| 587, they would blanket ban all email clients.
| pogue wrote:
| SpamHaus lists IPs to blocks, not ports.
| bauruine wrote:
| 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)
| megous wrote:
| > 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.
| bauruine wrote:
| 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 wrote:
| Any decent firewall these days is layer 7 aware. The port
| doesn't make a difference
| Gathering6678 wrote:
| I suppose it would be trivial to simply block or severely
| throttle high-volume SMTP traffic?
| userbinator wrote:
| Additionally, this will make it look like you're a spammer.
| stackskipton wrote:
| You could block SMTP on almost all end user networks with no
| one noticing. 99.9+% of email client submission is HTTPS.
| neilv wrote:
| How does this get past firewalls that would block the
| alternative, of SOCKS5 traffic tunneled through port-443 HTTPS
| with keepalives?
|
| (Even with complete HTTPS decryption in the firewall, the
| downstream traffic could look like, say, random CSV data file
| downloads or innocuous HTML text, and upstream traffic could look
| like innocuous requests (avoiding large lists of problematic
| keywords).)
| bmenrigh wrote:
| Large volumes of SMTP-like traffic are a huge red flag. Competent
| companies an ISPs should already be looking for large volumes of
| outbound mail to identify abuse / spam bots / data exfiltration.
|
| If I came across this in netflow data I'd first assume outbound
| spam. But a hallmark of sending mail is that the client to server
| byte ratio is extremely skewed towards client -> server bytes,
| whereas running a VPN-like service is usually more balanced but
| still skewed towards server -> client bytes. I'd see the large
| server -> client byte count and immediately know something
| strange was going on.
|
| That said, very little code here is involved in looking like
| SMTP. The SMTP obfuscation basically boils down to a few lines of
| plaintext between the client and server before a STARTTLS and
| then everything after that has nothing to do with SMTP. You could
| swap out the fake stub conversation quite easily to look like
| many other protocols. Whether the in to out bytes ratio makes
| sense for those protocols is another matter.
|
| These days, I think the best thing to disguise as is HTTPS. There
| is so much variety in HTTPS traffic and such a huge volume of it,
| that spotting hidden tunnels is very hard.
| compsciphd wrote:
| a former company I was at, didn't allow outbound ssh (which I
| liked to enable me to vnc into boxes at home). I installed
| installed a webvnc application on my home machine (protected by
| https / password) and was able to access it without an issue.
|
| When I left the company they went through my outbound email and
| were like "why did you forward an email you got out of the
| company". That e-mail was a friend visiting and me getting sent
| their picture from the lobby telling me that I had a visitor
| (so figured it be cute to share the image with them). I was
| amused that they only bothered to ask me as I was leaving, not
| when it actually occurred.
| janwillemb wrote:
| I used to host an SSH server at home at port 443, for the
| same reason! The sysadmin of my employer was so strict that
| 'solutions' like this were the way of the least resistance.
| Security gets worse when policies get stricter.
| geocar wrote:
| Making a dumb iphone game is a good excuse to send random HTTPS
| traffic, but receiving packets encoded as emails via (say) IMAP
| would be a good way to bring back large(ish) amounts of data.
|
| Someone watching closely might try to correlate the strangeness
| of the emails you receive with your candy crush habits...
| mr_mitm wrote:
| > These days, I think the best thing to disguise as is HTTPS.
| There is so much variety in HTTPS traffic and such a huge
| volume of it, that spotting hidden tunnels is very hard.
|
| I'd assume this project is meant for scenarios in which this
| isn't an option.
|
| In a pentest scenario, you sometimes have a shell on a system
| which has no route to the internet, and you lack permissions
| for a web proxy or you don't have access to one.
|
| Your next best bet is probably tunneling over DNS with Iodine
| or something similar. Many internal DNS servers resolve
| external host names.
|
| There might be scenarios in which DNS tunneling doesn't work
| and you have access to an internal SMTP server which you can
| then use to exchange data with your C2 server. These are
| exceedingly rare in my experience, and as you say running an
| entire SOCKS proxy over them would probably raise all kinds of
| alerts. I'd be very selective in what I would transfer.
| bmenrigh wrote:
| Your pentest scenario where you have an internal host without
| outbound access is an _entirely different situation_ than
| what this SOCKS masquerading as SMTP code addresses. The
| posted code can 't speak SMTP to an internal server and have
| the traffic relayed outside. The SMTP server the code
| provides is nothing more than a SOCKS proxy that pretends to
| speak SMTP for a few packets before the TLS connection starts
| and then everything inside the TLS session stops being SMTP.
|
| A SOCKS-over-SMTP relay tool for your pentest scenario would
| be _much_ more interesting (though with the way email works,
| probably not entirely realistic, much less stealthy). But
| there should be more work put into relaying tools to
| establish bidirectional traffic with the outside on highly
| restricted internal network. DNS is great but comes with a
| lot of limitations. Surly there are other common services
| available in companies that could be used.
| mr_mitm wrote:
| Oh, sorry, I guess I should have read more carefully. I
| don't really see the point of this either, then.
| Gormo wrote:
| > In a pentest scenario, you sometimes have a shell on a
| system which has no route to the internet, and you lack
| permissions for a web proxy or you don't have access to one.
|
| How would using a proxy masquerading as SMTP be any more
| viable in this situation than a proxy masquerading as HTTPS?
|
| > Your next best bet is probably tunneling over DNS with
| Iodine or something similar.
|
| DNS typically does not involve bidirectional transfer of
| large volumes of encrypted traffic. Doing this over DNS would
| stick out like a sore thumb to anyone doing traffic analysis,
| whereas this is exactly what you'd expect to see over HTTPS.
|
| > Many internal DNS servers resolve external host names.
|
| Sure, but the internal DNS in this scenario would typically
| be either forwarding external DNS requests to an outside
| resolver determined by its own configuration, or is itself
| hosting a full DNS table. How would you be able to use your
| own proxy masquerading as DNS in this situation?
| bmenrigh wrote:
| The goto tool that practically anyone doing any DNS
| tunneling uses is dnscat2
| (https://github.com/iagox86/dnscat2). It works fine through
| recursive/forwarding resolvers because those resolvers must
| recurse out to the authoritative nameserver for a given
| domain in order to resolve the name request. With dnscat2
| you use the server component "hosting" a "zone" using a
| domain name you own / control (so that you can point the
| authoritative nameserver record to the dnscat2 server
| component). You then use the dnscat2 client to packages up
| TCP traffic into DNS specially crafted DNS requests to the
| domain you control where the server is listening. The
| design is very clever and has to solve a lot of tricky
| technical problems.
|
| As for detection, you're entirely right that sending large
| volumes of traffic over DNS is both incredibly slow, and
| incredibly obvious to any network defenders paying
| attention to DNS.
| Haaargio wrote:
| Get yourself an IP with Port 443 free and just use that.
|
| SMTP is blocked by a lot of firewalls by default. All cloud
| providers do that and you need to request opening them up.
| ralferoo wrote:
| This seems daft to me as it would be trivial to identify on a
| network. Real SMTP will have significant data flow in one
| direction towards the destination, will close the connection
| fairly quickly once it's transferred (so no pauses) and has very
| little traffic being returned. It's hard to think of a worst
| protocol to try to hide a proxy in.
| mycall wrote:
| It would be great if it also worked as SMTP server
| ok123456 wrote:
| Back in the 90s, I ran telnet on the POP3 port so I could IRC in
| the lab during high school. The more things change, the more they
| stay the same.
| dfajgljsldkjag wrote:
| So many comments explaining this is a bad idea while OP just
| asked claude code to write this and probably doesn't even know
| the difference between TCP and IP.
___________________________________________________________________
(page generated 2026-01-07 23:01 UTC)