Chris's Wiki :: blog/sysadmin/UnauthenticatedSMTPTradeoffs

The tradeoffs of having an internal unauthenticated SMTP server

January 30, 2025

One of the reactions I saw to my story of being hit by an alarming well prepared phish spammer was surprise that we had an unauthenticated SMTP server, even if it was only available to our internal networks. Part of the reason we have such a server is historical, but I also feel that the tradeoffs involved are not as clear cut as you might think.

One fundamental problem is that people (actual humans) aren't the only thing that needs to be able to send email. Unless you enjoy building your own system problem notification system from scratch, a whole lot of things will try to send you email to tell you about problems. Cron jobs will email you output, you may want to get similar email about systemd units, both Linux software RAID and smartd will want to use email to tell you about failures, you may have home-grown management systems, and so on. In addition to these programs on your servers, you may have inconvenient devices like networked multi-function photocopiers that have scan to email functionality (and the people who bought them and need to use them have feelings about being able to do so). In a university environment such as ours, some of the machines involved will be run by research groups, graduate students, and so on, not your core system administrators (and it's a very good idea if these machines can tell their owners about failed disks and the like).

Most of these programs will submit their email through the local mailer facilities (whatever they are), and most local mail systems ('MTAs') can be configured to use authentication when they talk to whatever SMTP gateway you point them at. So in theory you could insist on authenticated SMTP for everything. However, this gives you a different problem, because now you must manage this authentication. Do you give each machine its own authentication identity and password, or have some degree of shared authentication? How do you distribute and update this authentication information? How much manual work are you going to need to do as research groups add and remove machines (and as your servers come and go)? Are you going to try to build a system that restricts where a given authentication identity can be used from, so that someone can't make off with the photocopier's SMTP authorization and reuse it from their desktop?

(If you instead authorize IP addresses without requiring SMTP authentication, you've simply removed the requirement for handling and distributing passwords; you're still going to be updating some form of access list. Also, this has issues if people can use your servers.)

You can solve all of these problems if you want to. But there is no current general, easily deployed solution for them, partly because we don't currently have any general system of secure machine and service identity that programs like MTAs can sit on top of. So system administrators have to build such things ourselves to let one MTA prove to another MTA who and what it is.

(There are various ways to do this other than SMTP authentication and some of them are generally used in some environments; I understand that mutual TLS is common in some places. And I believe that in theory Kerberos could solve this, if everything used it.)

Every custom piece of software or piece of your environment that you build is an overhead; it has to be developed, maintained, updated, documented, and so on. It's not wrong to look at the amount of work it would require in your environment to have only authenticated SMTP and conclude that the practical risks of having unauthenticated SMTP are low enough that you'll just do that.

PS: requiring explicit authentication or authorization for notifications is itself a risk, because it means that a machine that's in a sufficiently bad or surprising state can't necessarily tell you about it. Your emergency notification system should ideally fail open, not fail closed.

PPS: In general, there are ways to make an unauthenticated SMTP server less risky, depending on what you need it to do. For example, in many environments there's no need to directly send such system notification email to arbitrary addresses outside the organization, so you could restrict what destinations the server accepts, and maybe what sending addresses can be used with it.

Comments on this page:

By Sotiris Tsimbonis at 2025-01-31 02:55:18:

We've grown in an internet where unauthenticated smtp relay was normal, but over the years things have changed.

In today's reality, where the big players try to enforce smtp authentication and reputation, this week I had to change the config in an mta, in order to dkim sign bounces (non-delivery notifications) generated by postfix, in order to get them delivered to gmail.

By Miksa at 2025-01-31 06:37:08:

We had a similar situation in our university, and after couple spamming campaigns we decided we need to restrict unauthenticated SMTP.

We started with the low hanging fruits. There's no reason to send unauthenticated from VPN or VDI virtual desktop networks, so the SMTP servers will block those attempts. For printers our situation was better, we had centralized the printers and segregated them to their own networks long time ago.

For the SSH terminal/jump hosts with larger amount of users we use iptables OUTPUT chain to only allow the Postfix user to connect to the unauthenticated SMTP and Postfix only accepts email from root. This post proved useful, while typing this I decided to check and test how we had implement it. And I noticed that on the Ubuntu jump host we had released last week we had copied the firewall rules from a similar RHEL server and of course the postfix user had a different UID.

By Stephen at 2025-01-31 10:07:37:

you could restrict what destinations the server accepts, and maybe what sending addresses can be used with it.

Although, these days, most students coming to university will already have an e-mail address, and might prefer the scanner send to that address rather than a university account—which they might not ever bother setting up, unless pushed to do so (like if academic assignments need to be submitted from such an address). Especially if the account is gonna go away when the graduate.

Also, printers are a largely unexplored field of exploitation. We know they can be falsely accused of copyright infringment. But they also tend to be purchased and then sit around for 10 to 20 years (or longer; it seems parts and toner are still available for the popular HP LaserJet 4, and even the Apple LaserWriter II). How much faith should we have an a decade-old software stack?

Nevermind that universities tend to be pretty open places. I'm not sure about UofT, but anyone could've walked into my university, unplugged a printer, cloned its IP and MAC, and sent spam from its port. A tiny dual-port system could even be left behind for this purpose, while leaving the printer operational.

It's probably better to just try to detect and block suspicious usage.

Miksa, despite iptables and nftables referring to "uid", they both take names. Although the rulesets would then break on systems with no "postfix" user, if you have such systems.

By Tony Finch at 2025-01-31 20:19:20:

In my experience running the mail relays at Cambridge University over a decade ago, we had two major sources of outgoing spam: compromised mail accounts, and compromised web servers. Mail accounts were much more common. We didn’t have much VPN usage back then; that has clearly changed.

Anyway, if you have a web server that’s authorized to send mail, and it gets compromised to send spam, then it makes not a jot of difference whether the mail is authenticated or not.

After some flailing around trying to work out good countermeasures, I was generally happy with my ratelimiting setup. In the majority of cases, mail that hit the limit would get frozen on our mail queues, so that we could inspect it and respond appropriately.

There were enough infrequent high value and high volume newsletters sent by non-technical staff (alumni mailshots were the canonical example) that it made sense for us to quietly thaw and deliver legitimate messages - less fuss all round.

In cases where I knew the sending system was a server running an MTA with a proper queue and ability to retry, I would 450 messages that hit the limit, so that system’s admin could deal with it instead of me.

Our systems were generally lenient at filtering internal mail, basically just egregious malware, no spam scoring (except when mail took crazy routes). The ratelimiting was effective enough at keeping a lid on problems.

Written on 30 January 2025.

«	Our well-prepared phish spammer may have been chasing lucrative prey

Modern languages and bad packaging outcomes at scale