I run a website online that deals with labor dispatch, and one thing we offer is SMS notifications when new jobs are available. All numbers we send to must be confirmed by the end user before we will allow notifications to be sent to them, so there is zero chance that someone is receiving 'spam' messages they didn't want to receive. Until recently (about a week ago maybe), things were working fine for 8 years. For those 8 years, the setup was:
- my domain was in the envelope sender
- the dispatchers info was in the From: header
- my domain has Reverse PTR, SPF, and DKIM set up
Those messages are now being rejected as 'spoofs', presumably because the 'From' header doesn't line up with the envelope sender. While it may be a bit overzealous to trash those, especially given the SPF verification passes, I have been trying to work around the issue. In the meantime, I am using a 'noreply' for the from address, so the messages are getting through, but no one can reply to them, and my users are pissed off (as they should be).
So where I'm at now, I have been trying to implement SRS in order to deal with your heavy-handed, ill-thought-out approach to dealing with SPAM. So the dispatcher can send the message, the envelope sender continues to be based at my domain, and the From header is rewritten via SRS to appear to be at my domain, while containing enough info for me to forward the message back to them when the reply comes in.
Step 1: dispatcher sends a message. This works
Step 2: user replies. Tmo sends it to my server, and I am able to reverse the SRS address and initiate the forward. This works.
Step 3: I then forward the message UNMODIFIED to the destination, using my server's envelope sender (for SPF checks). Altering the From: header from the original sender is ABSOLUTELY NOT AN OPTION because it would break any DKIM signature for any messages I am forwarding. So this part breaks, because Tmo, for some reason, can't figure out what to do with this message.
This is an example of the message send from tmobile to my server:
S: 220 mail.example.com ESMTP Postfix (Ubuntu)
C: EHLO da3p-tmo-mm3-sfw001.syniverse.com
S: 250 mail.example.com\r\n
250-PIPELINING\r\n
250-SIZE 10240000\r\n
250-VRFY\r\n
250-ETRN\r\n
250-ENHANCEDSTATUSCODES\r\n
250-8BITMIME\r\n
250-DSN\r\n
C: MAIL FROM:<btv1==8190f953ef1==1PHONENUMBER@tmomail.net> SIZE=518\r\n
RCPT TO:<SRS0=Kb27=NM=tmomail.net=PHONENUMBER@example.com> ORCPT=rfc822;SRS0+3DKb27+3DNM+3Dtmomail.net+3DPHONENUMBER@example.com\r\n
DATA\r\n
S: 250 2.1.0 Ok\r\n
250 2.1.5 Ok\r\n
354 End data with <CR><LF>.<CR><LF>\r\n
C: Received: from tmobile.net ([10.164.3.161]) by da3p-tmo-mm3-sfw001.
syniverse.com with ESMTP id 0qe6yfmnCwSHUuup for <SRS0=Kb27=NM=tmomail.net=PHONENUMBER@example.com>; Tue, 12 Jan 2016 10:13:31 +0000 (GMT)
To: SRS0=Kb27=NM=tmomail.net=PHONENUMBER@example.com
From: 1PHONENUMBER@tmomail.net
Content-Type: text/plain
Date: Tue, 12 Jan 2016 10:13:31 GMT
Subject: RE:testing
Message-ID: 20160012101331845490@mavenir.com
Sender: 1PHONENUMBER@tmomail.net
X-Virus-Scanned: by bsmtpd at syniverse.com
Jfkfjjt\r\n
.\r\n
QUIT\r\n
S: 250 2.0.0 Ok: queued as DBD7418110
221 2.0.0 Bye
And this is an example of the bounced forwarding attempt:
S: 220 Syniverse ESMTP Service CHI01
C: EHLO mail.example.com
S: 250 ch3p-tmo-mm3-sfw001.syniverse.com Hello www.example.com [xx.xx.xxx.90], pleased to meet you\r\n
250 SIZE 3145728\r\n
250 PIPELINING\r\n
250 8BITMIME\r\n
250 HELP\r\n
C: MAIL FROM:<SRS0=19rQ=NM=tmomail.net=btv1==8190f953ef1==1PHONENUMBER@example.com> SIZE=808\r\n
RCPT TO:<PHONENUMBER@tmomail.net>\r\n
DATA\r\n
S: 250 Sender <SRS0=19rQ=NM=tmomail.net=btv1==8190f953ef1==1PHONENUMBER@example.com> OK\r\n
S: 250 Recipient <PHONENUMBER@tmomail.net> OK\r\n
S: 354 Start mail input; end with <CRLF>.<CRLF>\r\n
C: Received: from da3p-tmo-mm3-sfw001.syniverse.com (dal-tmo-mm3.syniverse.
com [173.209.216.234])
by mail.example.com (Postfix) with ESMTP id DBD7418110
for <SRS0=Kb27=NM=tmomail.net=PHONENUMBER@example.com>; Tue, 12 Jan 2016 05:13:31 -0500 (EST)
X-DKIM: Sendmail DKIM Filter v2.8.1 mail.example.com DBD7418110
Received: from tmobile.net ([10.164.3.161]) by da3p-tmo-mm3-sfw001.
syniverse.com with ESMTP id 0qe6yfmnCwSHUuup for <SRS0=Kb27=NM=tmomail.net=PHONENUMBER@example.com>; Tue, 12 Jan 2016 10:13:31 +0000 (GMT)
To: SRS0=Kb27=NM=tmomail.net=PHONENUMBER@example.com
From: 1PHONENUMBER@tmomail.net
Content-Type: text/plain
Date: Tue, 12 Jan 2016 10:13:31 GMT
Subject: RE:testing
Message-ID: 20160012101331845490@mavenir.com
Sender: 1PHONENUMBER@tmomail.net
X-Virus-Scanned: by bsmtpd at syniverse.com
Jfkfjjt\r\n
.\r\n
QUIT\r\n
S: 550 rejecting spoofed message
S: 221 ch3p-tmo-mm3-sfw001.syniverse.com Goodbye www.example.com, closing
connection\r\n
What do I need to do to get around your ill-conceived rules? Why don't you just implement DKIM? It's obvious that I haven't manipulated any of the headers, I've left everything intact, and my SPF checks out, so if that's not enough for you, why not implement DKIM so you can VALIDATE YOUR OWN MESSAGES? This is absolutely ridiculous! You gave me the message-ID, i gave it right back, you can VERIFY that it's a forward, not a spoof! Do you not realize how asinine this approach is?
How do I work around this engineering catastrophe? (The answer is not 'rewrite the from header on a forward', because that would screw over the responsible adults who actually implemented DKIM).
I'm sorry if I sound upset here, but it's because I AM. I've done every single thing by the books to give anyone the ability to validate the content coming out of my server, and your actions have directly impacted my business. This server has been sending these messages for 8 years, and it has a great email reputation, but you've somehow implemented a disastrous policy without really knowing what you were doing.
Please tell me how to work with this new terrible system so my users can message eachother and reply to the messages.
Best answer by srickar
Hi Diesel.....I made some modifications to the setup and not seeing any further 550 rejections. It was not for SPF violation either. There were also prior successful messages routing through. Please be patient, these systems are dynamically trying to combat false negative and false positive spam threats and no employee is trying to deny legitimate traffic. A global expression could override "safe" traffic based on traffic trends.
Please review and maintain SMTP setup with RFC822 header standards. With that said, can you please PM me with your concerns and I will try to address them.
