Delivery of bounced messages
Problem reported by Thomas Stensitzki - 1/17/2016 at 10:58 AM
I am using an inbound/outbound mail gateway which has been whitelisted in the SmarterMail (13) configuration.
An email being sent to a SmarterMail inbox, which is automatically forwarded to an external email address shows up as bounced in the delivery logs.
Delivery for user@externaldomain.com to forwardedrecipient@externaldomain2.com has completed (Bounced)
The domains handled by the gateway have been configured in the incoming gateway (domain forward) settings. User verification is set to None.
Any ideas?
Thomas Stensitzki
MCSM Messaging, MCM: Exchange Server 2010

1 Reply

Reply to Thread
Bruce Barnes Replied
Enable and enforce SMTP authentication for ALL user accounts.  YAHOO!, GOOGLE, and, now, COMCAST, all look for the AUTHENTICATED AS headers and will bounce anything that is not properly authenticated when sending via the original server.  Not being properly SMTP AUTHENTICATED also denies the ability of the receiving MX server to check, and properly validate, SPF and DKIM - BOTH of which are now required for YAHOO! and GOOGLE, with OUTLOOK also jumping on that bandwagon..  YAHOO and GOOGLE also require DMARC now, too, or they will begin to reject your messages.
Additionally, even with proper forwarding procedures in place. many MX servers still modify the message headers in such a way that DKIM, SPF and DMARC are "broken" by the forwarding.
While, for lack of a better term, bounces caused by header updates on legitimate messages are still a royal pain in the butt, there may soon be hope.
This is a post from my ChicagoNetTech Facebook page at: https://www.facebook.com/chicagonettech/
An ARC is coming to the Internet!
No, that doesn't mean that Noah, or anyone else, for that matter, will be rounding up data bits -- two-by-two.

ARC e-mail authentication does mean a new form of AUTHENTICATION for e-mail: an e-mail authentication method which preserves the initial email authentication results as the original e-mail message is processed cross subsequent intermediaries (“hops”), many of which currently modify the message.  These subsequent modifications will frequently cause current email authentication processes to fail to verify when the message reaches its final destination, resulting in a message bounce, often with a cryptic result message, causing frustration for MX server operators.
For more information on the ARC e-mail authentication protocol: the "Authentication Results Chain" (ARC), which provides a means to preserve email authentication results and verify the identity of email message handlers, each of which participates by inserting certain headers, before passing the message on to the next handler, or final destination, see: http://arc-spec.org
The ARC-Spec, once adopted, will enforce proper updating of e-mail message headers by every MX server through which they pass, but. again, emphasizing the fact that they are properly SMTP AUTHENTICATED, ONLY when a message has been properly SMTP authenticated.
So, in your case, make certain that you set your USER VERIFICATION to "ALL RELAY to NOBODY". 
In some cases, this may also mean changing protocols in any web services which generate e-mail so that e-mail which is generated in web services is also properly SMTP authenticated.
Bruce Barnes
ChicagoNetTech Inc

Phonr: (773) 491-9019
Phone: (224) 444-0169

E-Mail and DNS Security Specialist
Network Security Specialist

Customer Service Portal: https://portal.chicagonettech.com
Website: https://www.ChicagoNetTech.com
Security Blog: http://networkbastion.blogspot.com/

Web and E-Mail Hosting, E-Mail Security and Consulting

Reply to Thread