I have a serious problem here. I run a labor dispatch website, where users can register their cell phones (I send them an auth code via text, they enter it at the website, it's entirely opt-in). A job dispatcher can then send offers of work to these users via a web interface, and it will use email-to-SMS gateways to send the job offers to the users. For 8 years it worked, with minimal issues.
Recently, though, T-mobile did something asinine and now every message I send is being flagged as 'spoofed'. I have SPF, reverse PTR, and DKIM configured, and until recently, the messages were sent with a local bounce address in the MAIL FROM, and the dispatchers chosen reply address in the From: header. The offers would go out, and people could reply to them, and they would go either to the dispatcher's email or phone (whichever he chose when sending the message). Now, in an attempt to deal with irate customers and a sheer wall of ignorance at T-Mobile, I'm trying every possible thing I can think of to get around the Tmo idiocy.
To be clear, it's not DMARC or DKIM or anything related. The long and short of it is, if I try to send a message to Tmobile with a @tmomail.com address in the From: header, they will claim it is spoofed. So to work around this, I tried implementing SRS, and it ALMOST worked. The first step, dispatcher to user, works. The outgoing 'from' address is rewritten, and the message gets to the user.
The second step also works. The user replies to the message, it gets sent to the rewritten address, and it gets delivered to my mail server.
The third step is the issue. Once that message hits, the server reverses the rewrite (with the reversed address being used in the RCPT TO:), and forwards the message on to the dispatcher, without altering any of the original headers of the email (Which would break DKIM for the adults who have opted to use proven solutions for anti-spam, rather than just taking heavy-handed, idiotic approaches that result in massive collateral damage). During this step, the "real" From: header is not overwritten, so in the event that a dispatcher with Tmo had messaged a user at Tmo, the From: header would display xxxxxx@tmomail.net. And that is enough for T-mobile to reply with "550 rejecting spoofed message".
I don't know what to do at this point. My users are angry, and I have no idea how to solve this problem. At this point, I am thinking the best thing I could do is "take ownership" of the message, by rewriting the FROM on all forwards, and then resigning them with DKIM, but I don't know how to do that. SRS is rewriting the envelope sender during the initial message and the forwarded reply, but the From: rewriting is only happening on the initial message. When the reply comes in and I go to forward it, the From: is being left intact.
What postfix settings do I need to configure to get the end result I'm looking for? Or, alternately, if anyone has any better suggestions for dealing with this problem, please post them. I am desperate.
