It turns out that, since sometime around SmarterMail version 10.X
or 11.X, the ability of SmarterMail to properly do something called SENDER
HEADER REWRITE has not been functioning properly and this is causing 550 NON
DELIVERABLE ERRORS on e-mail which is FORWARDED from someone's SmarterMail
account.
For those of us who are involved, on a day-to-day basis with
e-mail services, and troubleshooting those services, this has been a thorn in
our sides since OUTLOOK.COM, YAHOO!, GMAIL, COMCAST, and many other e-mail
providers, ChicagoNetTech included, have enforced DMARC and other antispam
protocols in an effort to keep our user's in boxes as fee of spam as possible.
For those who have been sending e-mail and seeing 550 X.X.X errors
which specify that their e-mail was not delivered because of an SMTP
AUTHENTICATION ERROR, along with the techs who have been attempting to
troubleshoot these non-delivery issues, this has been an absolute nightmare, to
all of whom who have so suffered, I sincerely apologize.
Some background:
In our efforts to
prevent spam from being forwarded via an unauthorized source, many ISPs are now
performing hard checks SMTP + SPF | Protected by SPFon all incoming
messages to ensure that the SPF included in the message header actually matches
the
SPF information for the domain which is forwarding the message.
When someone has their
e-mail setup to FORWARD to another account, unless SRS has been enabled by the
relaying MX server, the SPF no longer matches the original sender's MX to SPF
mappings and the messages are now frequently rejected by the receiving MX
server. This is now being enforced by Gmail, YAHOO! and COMCAST, as well
as ChicagoNetTech, as we look for additional ways to prevent spammers from
"gaming the system" and they continue to find new ways to work-around
and circumvent the latest spam prevention techniques.
While this is almost
always an inconvenient incumbrance to the party who's forwarded e-mail is
rejected, after being forwarded, most modern MX servers have a way to insert
updated header information into the message, leaving the original headers
intact, and adding routing information to the message header so those MX
servers receiving forwarded messages will not reject the forwarded message.
In SmarterMail, this is
easily enabled by the primary MX server administrator by ENABLING SRS to
REWRITE the MESSAGE HEADER as it passes through the SmarterMail MX server.
Is There Anything Else to the Equation?
In February, 2013, a new player was introduced to the antispam
field. Called DMARC, this tool is
designed to allow e-mail server operators to tell those e-mail servers who
respect the DMARC protocol what to do with messages which originate from
sources other than authorized e-mail servers. The immediate effect of the
DMARC protocol was that it almost completely eliminated job-jobbing, a form of e-mail
spoofing which usually caused major headaches for the sender who's e-mail
address had been hijacked as the "reply to" address on bogus e-mail
messages.
DMARC checks for valid:
DomainKeys:
a private certificate, generated specifically for a domain, and mapped to the
domain both in the messages header and in the domain's DNS, which validates the
ability of that domain to originate an e-mail message;
DKIM
Records: digital signing of specific fields of a message, tied to the
DomainKey of the domain from which the message was sent;
SPF
Records: Sender Policy Framework records were one of the original tools
adopted to ensure the authenticity of messages and a very early form of
authentication which tied IP addresses and domains together;
rDNS or
IN-ARPA Records: a reverse address mapping of the IP Address from which the
message was sent to the Fully Qualified Domain Name (FQDN) of the e-mail server
with the authority to originate a message on behalf of a domain.
Because DMARC is a flexible protocol, designed to allow e-mail
server operators the capability to gradually "turn up the heat" on
spam messages received at receiving e-mail servers, an issue with message
forwarding was not readily apparent, until about a year ago, when GMAIL turned
up the head and started to completely restrict messages which did not
absolutely meet the DMARC protocol.
So, How is SRS Rewrite Supposed to Work?
With that in mind, let's go back and look at how SRS Header
Rewrites are supposed to work.
In traditional, or
verbatim, forwarding, the return-path is preserved in the outgoing message.
Here's a graphic to help illustrate the issue:
Forward
WITHOUT SRS Forwarding: Header Rewrite - will
fail
and here's a graphic
with the SRS rewrite added - allowing the message to pass SPF when received at
the new mailbox
Forward
WITH SRS Forwarding: Header Rewrite - will PASS
In an SPF world,
forwarders need to rewrite the return-path to stay in good standing.
The SRS library
implementations help perform the needed transformation and ensure
proper delivery. Full-time forwarding services may prefer to integrate
this logic directly into their MTAs. Smaller sites don't have to: they
can just call the srs utility which does all the work.
Once you have enabled
SRS, additional header information will be written into the header of the
original message, allowing it to meet the SPF compliance for the SmarterMail
server which is forwarding, or RE-SENDING the message to the party's off-site
e-mail address, without the receiving MX server rejecting the message for an SPF
error.
When the full force of DMARC is applied, and an SPF error occurs
because of a failed SRS header rewrite scenario, we end up with what is
referred to as a 550 ERROR
But wait, the 550 ERROR message says that the message was rejected
because the sender did not use SMTP AUTHENTICATION, and that's something that's
commonly checked as part of the antispam measures, to prevent spam from
reaching all of our in boxes, right?
Yes, but the 550 ERROR is also the error which is returned with
there is a MISMATCH on the SENDING E-MAIL ADDRESS DOMAIN because it is not
included in the SPF RECORD!
Pictures are Sometimes Very Helpful!
Here's a picture which might help you understand the issue better:
Point of information: an MTA is another way to reference an
e-mail server.
So, the ORIGINAL MTA sends the message to the RECEIVING MTA.
The receiving MTA then validates all of the informaiton in the
message header against a REMOTE MTA, generally a DNS SERVER, which contains information
on what server is responsible for what kinds of services for a specific domain
name and its services, and then reports back to the REPORTING MTA whether the
information contained in the message headers is GOOD or BAD.
When the SRS header is not properly rewriteen, the REMOTE MTA
reports back to the REPORTING MTA as BAD DATA and the REPORTING MTA rejects the
message, via the RECIVING MTA with a 550 ERROR.
The receiving e-mail server is rejecting a legitimately forwarded
e-mail message because it thinks it is from a spammer, IE: the SENDING DOMAIN
is not authorized, under SPF, to send on behalf of the domain which actually
sent the message
It turns out the 550 ERRORS are NOT a spam issue, but a FORWARDING
ISSUE -- a FORWARDING ISSUE which is caused by the fact that SRS HEADER
REWRITES were not properly written into the message header (a part of every
e-mail message which tells the receiving e-mail server where it came from, who
sent it, how the recipient should reply, etc, and also contains important
routing and antispam information.
Summary:
The messages are being rejected because SmarterMail, along with many other MX servers, is not
properly doing a SRS FORWARD HEADER REWRITE and the messages appear to be SPAM
which was sent through an OPEN RELAY.
I've opened a ticket with our SmarterMail vendor,
SmarterTools. You can read the ticket, comments, and progress, at: https://portal.smartertools.com/community/a2676/srs-header-rewrite-not-working-properly-on-message-forwarding-_-_-_.aspx
You can also see my original KB (Knowledge Base) article on SRS
Forwarding at: https://portal.chicagonettech.com/kb/a177/enable-srs-to-prevent-spf-fail-on-forwarded-e-mail-messages.aspx
While this particular instance relates to a software problem with
a specific product, SmarterMail, this is not an uncommon situation with e-mail
servers, which are also known as MX servers and MTAs.
If you have experienced issues with 550 errors and e-mail
rejection, you may want to forward this e-mail to your IT Department or e-mail support
group so they can look into whether their e-mail server product is properly
inserting SRS Header Rewrites into e-mail message headers.
Remember, ChicagoNetTech provides secure e-mail and web hosting
services and will be glad to help you make your online experience better.
Bruce Barnes ஃ
ChicagoNetTech Inc
SmarterTools Product Specialist
E-Mail and DNS Security Specialist
Network Security Specialist
Web: https://www.ChicagoNetTech.com
Customer Service Portal: https://portal.chicagonettech.com
FaceBook: https://www.FaceBook.com/chicagonettech
LinkedIN: https://www.linkedin.com/in/chicagonettech
E-Mail and DNS Security Specialist
Network Security Specialist
Web: https://www.ChicagoNetTech.com
Customer Service Portal: https://portal.chicagonettech.com
FaceBook: https://www.FaceBook.com/chicagonettech
Blog: http://networkbastion.blogspot.com/
Mobile APP: ChicagoNetTech via Google Play
ChicagoNetTech uses tools from SmarterTools, including SmarterMail, SmarterStats, and SmarterTrack to provide the best possible customer service at the lowest possible rates.
"Nam et ipsa scientia potestas est" "Knowledge is power" - Francis Bacon (1561—1626)
"Only the paranoid survive." - Intel Founder - Andy Grove (1936 - )
No comments:
Post a Comment
Please keep all comments on topic and respect the poster of the original message.
Messages which attack a poster, contain profain language, are off topic, or are otherwise defamatory will be deleted from the blog.