[vidarh]

Nothing preventing offering delivery on alternative ports for people with incompetent security teams that thing port numbers is sufficient to determine if it's a threat.

As for "being hammered", rejection of invalid recipients before even getting to the DATA verb is cheap.

Having actually run both an e-mail service and SMTP used as messaging middleware, I have dealt with these issues.

[user5994461]

The security team is not incompetent. Large companies do not permit developers to spin up their own email systems without audit and regulatory retention. The port number is sufficient to determine that the request should be rejected.

You could work around it but should you? You're exposing the company to fines and risking your job.

Better think of another way to integrate with the vendor, or find another vendor.

P.S. SMTP is easy to identify on ANY port, it's replying a distinctive line of text when TCP connection is opened.

[vidarh]

> do not permit developers to spin up their own email systems without audit and regulatory retention

If they freak out over an SMTP server but don't freak out over a web server, then the are indeed absolutely utterly incompetent fools that should never work in this space.

In both cases code written by the company developers will eventually process untrusted textual input, and you need to deal with that with the same level of caution, and the protocol does nothing to change that.

> You could work around it but should you? You're exposing the company to fines and commiting a fireable offense. Better find another product that's easier to deploy.

I would not work around it - I would make the case that there's no difference in exposing a carefully chosen SMTP server than exposing a web server, and if the security team fail to understand that, I'd resign, because it'd be a massive red flag, and I've been successful enough to be in a position to not need to work for companies like that.

For that matter, in 25 years in this business I've yet to run into your hypothetical scenario, including at large companies, so I'm not at all convinced it'd be a genuine problem. Yes, I've been at companies where I'd need to provide a justification for getting a port opened. But never once had an issue getting it approved - including SMTP.

> P.S. SMTP is trivially identifiable on ANY port, it's giving a line of text when the TCP connection is opened.

I was responding to "Security will never open the firewall for email ports.". Point being that if they care about the specific port numbers, it doesn't matter.

[And I'll again point out I've actually run infrastructure like this].

[user5994461]

Never worked in a bank? Never worked in defense?

I'm speaking from real experience too. It takes a while to open firewall in some environments, if you ever can.

One bank was the worst. There was a super stringent process to expose things externally. Opening the firewall port was just the beginning and that'd take 2-4 weeks if all goes well.

You'd struggle like hell to expose a SMTP server though because it would be immediately be rejected and flagged based on the port. Banks have to store, monitor and ensure the origin of all emails, they don't allow shadow email servers. And it's plain text so more reasons to ban (also a problem with HTTP, you should do HTTPS if anything).

Defense was simpler, mainly because there was no external connectivity in many cases. You don't need to worry about how to open a firewall when there's none :D