What are peoples' experiences with the spam rules at tmomail.net? I can email a
SMS or MMS from one external account hosted in Amazon's cloud, but not another
account at a slightly less mainstream but perfectly legitimate email provider. No
bounce came back from the failure, it was just never delivered.
The gateway is handy, especially for folks with old phones/accounts that can't text.
I'd be interested in others' results, like sending from gmail, comcast, aol, hotmail,
fastmail, etc. Does a quick test msg get through to YOURNUMBER@tmomail.net?
I found old threads describing messages getting outright rejected, but the silent
drop is a different problem.
Best answer by hobbit
This has been more or less resolved, about as well as it's ever going to be. "Srickar" was kind enough to
dip into the logs and visible rulesets on tmomail.net and observe that indeed, there was some SPF confusion
about which sources are authorized to send email claiming to be from "@t-mobile.com". Which this very support
site does, on a fairly regular basis. If a recipient address happens to be via the tmomail.net gateway, obviously
that needs to be let through, so in theory now that will work reliably.
The remainder of the difficulty is far more complex. In effect, the spam-prevention infrastructure around
tmomail.net is being run by robots instead of humans now, with several different dynamic block-list and
content-scanning providers in play, and the rules those apply can change very quickly. We also had a little
confusion about what's a SMTP envelope address versus a From: line, which spam gateways will examine
differently. There's apparently even a problem when Subject: lines are sent to be delivered via SMS, but
I'm sure that some people's automated notification systems do that so it should not be grounds for rejection
by itself. [The SMS comes up as Subject / Message anyway, so obviously the gateway is happy to handle it.]
So all told, delivery is less reliable than we'd like it to be but the criteria are effectively out of anyone's
hands to have fine-grained control over. Srickar was able to add a specific exception for one use case,
but the rest is being decided by machines. I appreciate that effort and it's good to know that someone
with engineering chops and working hands on the right resources is participating here.
Hopefully engineering staff will continue looking at the spam-rejection logs and work on eliminating
further false positives.