Solved

email to tmomail.net rejected for banned content

  • 15 October 2015
  • 71 replies
  • 3511 views

I've used tmomail.net for a couple of years.  Sometime between Sep 30 and Oct 3 the servers {dal or chi}-tmo-mm3-syniverse.com started rejecting messages from my mail server with the message: 544 rejecting banned content.

I've done some testing:

  • What works:
    • If I test with a gmail account, the message is delivered to my cell phone.
    • My mail server can deliver the same message to <phone>@vtext.com to a friend's phone.
  • What generates the same error:
    •    Prefixing my phone number with a "1".
    •    Using the T-Mobile phone number of my data device, my son's phone or my daughter's phone.
    •    Using a simple message with subject "test" and body "test" that has no content worthy of banning.

 

Would you say that the tmomail.net servers have effectively blocked my email server?  Has anyone else had

this issue and had it resolved?  Has anyone had their email server whitelisted?

 

Thanks,

Bill

icon

Best answer by tmo_lauren 22 October 2015, 17:29

View original

71 replies

Why isn't there an email address to send to? Why require users to have a twitter or facebook account in order to submit an issue electronically? This is one of the dumbest policies I've ever encountered, it makes me absolutely furious that t-mobile thinks this is acceptable.

Shame on you!

Userlevel 3
Badge +4

In case any TMO support admins see this....I have been in touch with subscriber via PM, and his investigation ticket issue was already in-progress by ECS and should be corrected in 24-48hrs. Thanks.

srickar,

where would i file a ticket? I've searched and searched, but cannot for the life of me find the page that allows me to file a ticket and submit my postfix/wireshark logs.

I am having the same issue. I have my google calendar send updates to my gmail and I have it filter to forward to myphone#@tmomail.net as an additional reminder. This has not been an issue till recently....any suggestions...below is what it looks like...

From:mailer-daemon@googlemail.com

To: @magenta5565064

Delivery to the following recipient failed permanently:

     myphone#@tmomail.net

Technical details of permanent failure:

Google tried to deliver your message, but it was rejected by the server for the recipient domain tmomail.net by dal-tmo-mm3.syniverse.com. [***.***.***.***].

The error that the other server returned was:

554 rejecting banned content

It is obviously not spam...Please help!!!

Thanks

yes - still happens a number of times each day.

Userlevel 3
Badge +4

Hey Brian!

Thanks for sending that over! I see the block and will get the false positive corrected. But I also see where these messages need some improvement to help avoid triggering automated detection.

For example, not sure why message body content is being crammed into the subject line. This is a red flag for spammy content to get the subject transferred over during the MTA handshake.

Subject: Please put show#xxxxxxMM into pending status. Facility commission|  ?? ****CUTOFF***

This is likely raising the artificial score and I recommend relocating this to the body. Please note there are also SQL character limitations and long subject strings could be cutoff resulting in incomplete messages.

Also, you are sending these messages in plain text content. Plain text MMS will redirect to SMSC for delivery and the sum of (sender + subject + body) = <>160 character ASCII content. Some iPhones cannot read these files crammed like this and will silently drop the message or attach an unreadable .txt file to a long MMS message.

Finally, every message is being sent with the following header flag:

Priority: urgent

Importance: high

Sending all messages with this flag triggers typical spammer tactics (Call!, reply!, due!, take action!, urgent!, High priority!) etc. Please remove these default message priority header flags as this triggers repetitive automated suspicion.

Thanks...

Userlevel 4

@srickar, thank you for getting @magenta1335019  squared away! 😊

So I am getting 550 errors daily from Tmomail servers sending Emails to the SMS gateway for clients who talk to their loved ones via this delivery method. I can send you the SMTP message I received if you want to give me a follow. I attempted to talk to customer support via phone but they were no help and suggested that the receiver of the text must not have any signal at the moment...which I tried to explain wouldn't be the cause of a 550 error but O.K.

Userlevel 3
Badge +4

@kameo2k​ I found the specific message in our logs. This particular message rejected by spam filtering due to several reasons. ALL CAPS, missing message IDs, and just the overall language tripped the filter.

Are you the administrator for textconnect.info? There are two issues here.

  1. Due to the variable nature of the transactions between recipients and prison language, this will inevitably trip spam filters. I counted approximately 7 blocked messages out of 212 in the past 7 days, due to an aggregate score count. Not one specific item is blocking the messages, unless it meets a specific criteria. With less than a 3% block rate, this type of block is acceptable.

  2. Lastly, this type of message traffic is A2P enterprise content. Enterprise messaging should truly be sent over shortcode providers and not through consumer P2P messaging gateways. Please refer to CTIA standards section 3.2 regarding the classification of enterprise traffic over P2P gateways and why this class of messaging should migrate to shortcode provider.  ctia.org/docs/default-source/default-document-library/170119-ctia-messaging-principles-and-best-practices.pdf  Textconnect.info is a texting provider for a specialized industry, but interfacing this enterprise traffic incorrectly to a carrier via consumer P2P messaging front-end gateway.

  • Per Cellular Telecommunications and Internet Association (CTIA) Industry guidelines, Inter-carrier guidelines and T-Mobile’s own terms of service, automated commercial SMS traffic routing on any network should use short codes.
  • Commercial trafficking is only allowed through short code, and not through long code (10-digit numbers) and a customer must opt in to receive content.
  • Third-party services can send bulk messages, but such vendors are unaffiliated with T-Mobile and we can't make recommendations. Examples include: Openmarket, 3Ci, mGage, SAP, iConectiv, Vibes Media, Syniverse, CLX.

In summary, this type of texting interface should be migrated to shortcode provider.

Userlevel 3
Badge +4

Sorry that you can't seem to get the notifications, but we are not blocking mios.com alarm notifications. Please open a ticket regarding @tmomail.net service and ask for a second look. I can reverse search by recipient number and can tell for certain the timestamp the message arrived and then check SMSC logs to see what happened at the device level.

 

Thanks!

 

Userlevel 3
Badge +4

Send me a follow request so that you can PM me the details. Thanks!

srickar,

Please help. I am an IT professional and receive SMS alerts when systems have problems from a corporate SMTP server of which I have little visibility into. Several of these emails fail (but surprisingly not all). I have followed you in hopes that you can PM me and help with my issue.

OK thanks. I accepted the follow and can look into it once the details are shared.

@srickar I have exactly the same issue. I just sent you a follow request too. I started receiving 550 permanent failure:blocked responses for all messages sent to a tmomail.net address within the last 24 hours. AT&T and Verizon still work flawlessly, as well.

I would super appreciate any help.

Thank you in advance. :)

Userlevel 3
Badge +4

OK thanks. I accepted the follow and can look into it once the details are shared.

@srickar I have exactly the same issue. I just sent you a follow request too. I started receiving 550 permanent failure:blocked responses for all messages sent to a tmomail.net address within the last 24 hours. AT&T and Verizon still work flawlessly, as well.

I would super appreciate any help.

Thank you in advance. :)

Thanks for tagging me. Please retest as spam definitions update multiple times per hour as well as spam attacks. If it continues to block, please check for SPF/DKIM/DMARC configuration is setup appropriately. If you still need assistance, please send me a DM with the domain and 1 recipient and I can verify the condition. Thanks!

OK thanks. I accepted the follow and can look into it once the details are shared.

@srickar I have exactly the same issue. I just sent you a follow request too. I started receiving 550 permanent failure:blocked responses for all messages sent to a tmomail.net address within the last 24 hours. AT&T and Verizon still work flawlessly, as well.

I would super appreciate any help.

Thank you in advance. :)

Thanks for tagging me. Please retest as spam definitions update multiple times per hour as well as spam attacks. If it continues to block, please check for SPF/DKIM/DMARC configuration is setup appropriately. If you still need assistance, please send me a DM with the domain and 1 recipient and I can verify the condition. Thanks!

@srickar  Thanks for your reply. I have tried multiple times in the pas 24+ hours and the problem remains. I am sending you a DM with further info. Thanks again!

Userlevel 3

I took a look at known issues for this and found:

REFERENCE ID: NA

IMPACT: Customers may be unable to receive messages to messages to their MSISDN@tmomail.net address. To help aid the attack against SPAM, T-Mobile is now blocking traffic where the sending Domain is altered from the true sending address: IE support@customerservice.com, when the domain is actually is support@gmail.com. senders will receive a 550 bounceback error . To correct this issue, Senders will need to revert their sending address to their actual email address. For assistance, direct customers to the sending party, and sending parties to their domain customer support. this service is functioning properly.

ETR: No ETR - The service is functioning normally.

This sounds like what may be impacting you, so you may need to contact the sending domain directly!

-Lauren

Thanks for taking a look.  I have seen the issue you describe.

In my testing, I tried to set up an email alias, tmomail@myserver, on my server that would forward the email to mynumber@tmomail.net.  Then I sent an email from a gmail.com account to tmomail@myserver.  tmomail.net rejected the email and the mail delivery system of my server sent an " Undelivered Mail Returned to Sender" bounce notice to my gmail account.  From the bounce notice:

<mynumber@tmomail.net> (expanded from <tmomail@myserver>): host chi-tmo-mm3.syniverse.com[173.209.217.234] said: 550 Rejecting for Sender    Policy Framework (in reply to RCPT TO command).

This is quite right.  Mail is being delivered for a sender with a gmail address by a server not authorized in the SPF record to deliver email for gmail.

Anyway, error 554 "banned content" is different from what you found.

Today T-Mobile has made some progress.  My mail server doesn't have a typical name like: mail.domain.com or smtp.domain.com.  If I understand correctly, the name of my mail server was being caught by a regular expression in the spam filter and blocked.  Hey, really, it was as innocuous as computer1.domain.com

I said "some progress" because earlier today, my test messages were not banned, but no SMS messages were delivered to my cell phone (using both my server and gmail's server). 

However, just now, I tried again and within 4 seconds of sending an email to myphone@tmomail.net the message was delivered to my cell phone.

So the problem is fixed.

Thanks T-Mobile.

Userlevel 3

I'll keep an eye out and research for other possibilities and report back if I find anything better fitting your situation!

-Lauren

Hi Lauren,

I work at a university and our students can sign up to receive SMS notifications from our Learning Management System when certain things happen in their courses. Over the past month and a half we've noticed getting bounces from primarily T-Mobile users with the message:

<number@tmomail.net>: host chi-tmo-mm3.syniverse.com[173.209.217.234] said:

    550 Rejecting for Sender Policy Framework (in reply to RCPT TO command)

I checked with one of the students and she was getting the messages as recently as last weekend when she upgraded from an iPhone 5s to an iPhone 6s. Would the sms messages be routed/received differently depending on the device?

I've also been exchanging emails with our LMS vendor on the issue and they recommended I direct the students to T-Mobile, but your post indicates the student should be contacting the university, who would then need to contact the DNS host (our vendor).

Thanks,

Wayne

Lauren,

We are also having problems with sending to Number@tmomail.net. The messages are not being blocked with the 550 error. Sometimes we have to try sending the message multiple times before it is delivered. Users using other carriers (Verizon, Sprint, AT&T, Republic Wireless) have no problems receiving messages.

Userlevel 3
Badge +4

I happened to notice this posting. I am the spam admin for @tmomail.net services and would like to assist.


Sender Policy Framework 550 status message is part of spam validation screening. "550" is part of a long list of SMTP status codes to help diagnose connection issues.  Mail relays connecting to @tmomail.net DNS and MX (mail) records must match or be authorized on behalf of another domain. The mismatch can occur in the registered domain or the shared ISP network connection.

This very simple FAQ provides a very high level understanding of SPF 550

SPF: FAQ/What it does

This can occur when a company or university has an affiliate brand or satellite university, attempting to send email on behalf of the parent company. The authorized administrator for the parent company or university, needs to update DNS and MX records permitting all authorized affiliate mail relays to send on behalf of the parent mail server. Otherwise, the assumed SAFE policy is to "reject" the mail until the record is corrected. SPF is a global standard policy and can be strictly enforced or relaxed to accommodate spam control. Most mail administrators already maintain current MX and DNS records to accommodate for all global mail hosts they may need to communicate with, but sometimes there are exceptions or missed segments as companies grow or change hands.

With that said, SPF 550 response codes are intentionally sent back to the message originator to alert the sending party their DNS/MX host records are not up-to-date or mismatched.  SPF prevents any rogue entity from spoofing the reply to: envelope on the received outgoing message sender.

T-Mobile cannot update DNS and MX records on behalf of sending mail servers, only the authorized administrator can perform this task.

Thank you for your reply. Our server admins updated our SPF record last week to included the sending parties domain, but are still getting returned. How long would you expect it should take for the SPF update to propagate to your system?

We don't get 550 returns from other major carriers, would they be doing something different?

Wayne

Userlevel 3
Badge +4

550 should clear in a matter of hours. Without knowing your domain, I can't determine the full reason for the denial other than SPF is not permitting the mail relay to send on behalf of the domain. Please submit a ticket to T-Mobile customer care regarding blocked emails to @tmomail.net and we can take a look. It would be helpful to provide the SMTP logs so I can see the IP and hosts associated in the transaction logs.

Userlevel 2

You'd Community-2153‌ over the phone or your best bet would be to reach out to our T-Force team via our Facebook page or Twitter (links are on the Contact Us page). You should be able to paste the relevant parts of the log in to the messages once making contact or they can likely give you a place to send them to them (or if you have them in Dropbox or Pastebin and can provide the link).

Tickets are created by our frontline teams and they'd have a series of troubleshooting/investigative steps they'd be required to do before creating a ticket and forwarding it up. Think of them as Level 1 support and you'd need to get to level 2/3 via the ticket.

Reply