We previously used Manager.io (older build / sandbox environment) to send invoices via an Exchange Online inbound connector using unauthenticated SMTP (IP-based trust).
This configuration worked reliably.
After upgrading to a recent Manager build (26.1.21.3171), SMTP delivery now fails unless authentication is provided, and unauthenticated relay is no longer possible.
This appears to be a regression in SMTP handling, not a configuration issue, as:
Microsoft Exchange Online inbound connectors still support unauthenticated SMTP
The same relay continues to work for other applications
Manager never attempts delivery (no TCP connection observed)
Can you confirm whether unauthenticated SMTP support was removed or changed, and whether this behavior can be restored or gated via configuration?
We tested Manager’s HTTP email mode as a diagnostic workaround after unauthenticated SMTP relay stopped working in newer builds. While the HTTP endpoint is reachable and works correctly via curl (including large payloads), Manager never establishes a TCP connection to the endpoint at all and always times out after 100 seconds. nginx logs and tcpdump confirm the request never leaves Manager. This suggests a regression or restriction in Manager’s outbound email handling rather than a configuration issue.
To clarify, this is an Exchange Online inbound connector configured for unauthenticated SMTP relay based on source IP (Microsoft-supported and documented).
This same relay continues to work with other applications and worked previously with Manager in an earlier build.
The issue we are seeing is that Manager always attempts SMTP AUTH, and if authentication is not available, delivery fails before a message is sent. There does not appear to be a way to allow Manager to proceed without authentication when the server does not advertise AUTH capabilities.
This appears to be a change in behavior compared to earlier versions. Could you please confirm whether unauthenticated SMTP relay is still supported, or if authentication is now mandatory regardless of server capability negotiation?
I see what you mean now. If you don’t enter anything into username field, then you do not want SMTP AUTH to occur. I have made it that way in the latest version (26.4.22.3427)
OK, so I’ve updated to 26.4.22.3427 but it’s still the same behavior for SMTP settings:
blank username/password errors out with:
Username field is empty. Please enter valid username. when running the test
entering a dummy username/password returns:
The SMTP server does not support authentication. when running the same test