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.
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...
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.
> 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.