Back to Community Threads
Assignment of outgoing gateway to system messages (DSNs, NDRs, &c.)
Idea shared by AWRData - 9/17/2024 at 9:38 AM
Under Consideration
I recently found SmarterMail is not using my outbound gateways as egress for system messages.  Instead, SmarterMail is using DNS destinations (MX or A records) and sending via the server's Internet-facing interface.  This is an inappropriate configuration for my infrastructure, and would also present issues for environments using "smart hosts" to bypass carrier restrictions, block lists, &c.

I am told the gateways are only used for assigned domains' authenticated users.  The system as a whole lacks a gateway.  This is causing my DSNs to get stuck in the outbound queue until they expire.

I propose the ability to optionally set a gateway as a "default" gateway, which would then carry all outbound system messages.
+1
Gabriele Maoret - Head of SysAdmins and CISO at SERSIS
Currently manages 7 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 6 on-premise for customers who prefer to have their mail server in-house)
Shameless bump.  I still have to regularly clear out system notifications and NDRs from my spool.
We're in the same boat. I already reported this months(years?) ago without success. NDRs filling the spool because they're not relayed through our outgoing gateways.

At some point in previous versions, before one of the "big" release, it was using the gateways for NDRs and everything was ruinning smooth. Then one day, after an update, I noticed it started bybassing the gateway... :(
Sébastien Riccio
System & Network Admin
While troubleshooting this problem, I found that system messages are attempting to deliver to my domain's MX servers.  But, for some reason, the connection dies during the SMTP session.  Because the cipher is ECDHE, I am unable to decrypt the session in Wireshark.  Before getting more fancy with the process, Jereming recommended that I change the SMTP Out binding under Settings>Protocols to use the Internet-facing NIC.  Doing so fixed the issue with delivering system messages, but it broke mail flow for gateways on the internal network NIC.

The option at this point was obvious: regular client mail flow trumps system messages, so restoring the SMTP Out to the internal NIC and breaking system messages is the going-forward configuration.

This feature request is under consideration, but more "yes, please," would be helpful.  Thus the shameless bump.
J
Same request for *forwarded* messages.  We found that even when the client domain is set to use a specific outbound gateway, that only works for messages sent by the client.  When a forwarder is set up (eg. forwarding their mailbox go their Gmail or whatever) the gateway setting is ignored and the forward is sent directly without relaying it to the gateway.
 
Swinging back to this, I have been queried by both a customer and an outside sender about delivery receipts not being received by the requester.

SmarterMail honors delivery receipt requests, which is awesome, but they get stuck in the spool because of this issue.  So, bumping, again.
H
Does this have anything to do with the coming HA feature?
@Howell Dell No.
Back to Community Threads

Reply to Thread

Enter the verification text
Related Knowledge Base Articles
How an Email is Processed in Current SmarterMail BuildsSmarterMail > Server Configuration and Management
Configure a Smarthost Gateway in SmarterMailSmarterMail > Server Configuration and Management
Key Feature and Version Milestones in SmarterMailSmarterMail
554 Error - MTA Poor Reputation FixesSmarterMail > Troubleshooting
Common Ticket Issues and FixesSmarterTrack > Troubleshooting