> These vulnerabilities could have been exploited to read all mail traffic or as an entry vector into the internal network.
https://thehackernews.com/2026/05/seppmail-secure-e-mail-gateway.html
Mail gateways sit in a nasty trust spot, so I’d treat patches here more like VPN/firewall patches than normal appliance updates.
One of our MSP clients had a mail DLP rule that blocked outbound attachments containing customer IDs. I wrote it years ago, tested CSVs and PDFs, got clean blocks, then mentally filed it under handled.
Last week a user copied the same customer IDs out of a spreadsheet, pasted them straight into the email body, BCC'd a personal account, and the message sailed out. No attachment, no match, no alert.
The ugly part is the rule was not broken. It matched the scope I gave it, and my threat model stopped at files leaving by email instead of data leaving by email.
I'm now tightening body inspection and personal-mail recipient checks, but I hate how easy it is to create DLP that only protects the path you happened to test. Curious where other mail admins draw the line before outbound rules become noisy enough that everyone starts bypassing them.
Postfix will accept the first matching relay restriction, so if permit_mynetworks fires before reject_unauth_destination, that client gets to relay. That is fine when mynetworks is tight. It is ugly when years of config drift left a whole subnet in there.
I have seen this bite after distro upgrades because people assume the old recipient restriction stack is still doing the real work. Then Postfix 3.x behavior exposes the fact that relay policy belongs in smtpd_relay_restrictions, and ordering matters.
After upgrades, test from outside your trusted ranges and from anything inside mynetworks that should not be a mail relay. Don’t just read postconf output and call it done.
My rule now is simple: keep mynetworks boring, keep reject_unauth_destination explicit, and prove the queue refuses unauthenticated third-party destinations before handing the box back.