Years ago I created a simple xinetd rule to use a custom port for SMTP.
I set this up years ago when my local ISP started to block outbound SMTP connections on port 25 as an anti-spam measure. I had been using our web server for SMTP relay for several years before this because this same ISP had quite poor uptime in the past. When my ISP blocked port 25, my email stopped going out. I could either switch to the ISPs mail servers, or find another way to get my mail to our web server.
I can’t recall the exact reasoning, IIRC, the ISP also required that you use an email address from their domain in either the from or reply-to lines. Whatever the reasons, I created a custom port to route email through our server to continue to bypass our ISP’s email system altogether.
I chose an unused, non-standard, low TCP port and set up the redirect in xinetd. Sendmail, our SMTP server, was previously configured to relay for specific IP addresses, I didn’t change that.
That was at least 5 years ago. It was a simpler time and spammers stuck to searching on default ports for open email relays.
Well, today I can confirm that spammers will do a port scan to find open email relays – surely there are better ways to make money that come up with crazy ways to send a bit of spam?
I learned that I had created an open relay on a non-standard port by accident. When an inbound connection is relayed by xinetd to a different port number (at least the way I did it) the service has no idea what is the real remote IP address. Sendmail thought it was relaying for email from localhost! Argh.
Unfortunately, for a few hours today our web server was relaying spam for some Brazil IP address and advertising something or other in Portuguese. The old relay rule was turned off as soon as I traced the hole.