Hi, My team has been using a homegrown monitoring package to send SMS alerts to our phones when there are system problems at our office. When there is a problem it sends email to email@example.com. This has been working great for months, and some time in the last couple days it stopped working. I can still send to the sprint address from gmail, and even from my corporate exchange account, but nothing from my monitoring package gets through. When I tell the monitoring package to send to my gmail account instead of the messaging.sprintpcs.com address, that works fine, and here are the headers from that message:
Received: by 10.43.63.141 with SMTP id xe13cs167613icb;
Fri, 11 Mar 2011 08:47:01 -0800 (PST)
Received: by 10.151.28.11 with SMTP id f11mr2901734ybj.297.1299862020947;
Fri, 11 Mar 2011 08:47:00 -0800 (PST)
Received: from netflow01 ([188.8.131.52])
by mx.google.com with ESMTP id u33si11592763yba.91.2011.03.11.08.46.59;
Fri, 11 Mar 2011 08:46:59 -0800 (PST)
Received-SPF: pass (google.com: domain of XXXXX@silverpop.com designates 184.108.40.206 as permitted sender) client-ip=220.127.116.11;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of XXXXXX@silverpop.com designates 18.104.22.168 as permitted sender) smtp.mail=XXXXX@silverpop.com
Received: from vigalert.atlis1 ([10.120.41.87]) by netflow01 with Microsoft SMTPSVC(6.0.3790.3959);
Fri, 11 Mar 2011 11:46:59 -0500
Date: Fri, 11 Mar 2011 11:47:32 -0500 (EST)
Content-Type: text/plain; charset=UTF-8
X-Mailer: ColdFusion 8 Application Server
X-OriginalArrivalTime: 11 Mar 2011 16:46:59.0515 (UTC) FILETIME=[F08BD8B0:01CBE00B]
So, Gmail will happily take email from my monitoring package straight to the inbox, and it is passing SPF. How do I figure out why Sprint won't take these messages and more importantly fix the issue. If Sprint is going to block what we are depending on for critical alerts with no notice, we are going to have to look at alternatives for the entire production operations team, whihc we don't want to do - please help!
Our mail servers external IP is: 22.214.171.124
Sprint uses the Senderbase reputation network to protect our customers from spam. Unfortunately, your server has a 'poor' reputation in Senderbase:
You can work with your ISP and IT admins to check out your mail server to see what may be causing the poor reputation.
We have same problem. I just checked our IP true http://www.senderbase.org and saw that we have GOOD reputation. But anyway we getting the following.
The following organization rejected your message: [126.96.36.199].
I have tried sending a message to the sprint SMS gateway from 4 seperate email addresses (powerreviews.com, gmail, tdl.com, & pccowboy.com) - none of them worked, and all show up fine in senderbase.
When I send an email from my blackberry to the SMS gateway, the text message comes through.
This tells me that Sprint has a network configuration problem with their SMS gateway, as internal emails get to the gateway, but external sources are being lost. It would sure be nice if this worked, as it is part of what I am paying for...
Aug 8 15:33:49 **** postfix/pickup: 30BA615380E5: uid=1205 from=<****>
Aug 8 15:33:49 **** postfix/cleanup: 30BA615380E5: message-id=<20110808223349.30BA615380E5@****.powerreviews.com>
Aug 8 15:33:49 **** postfix/qmgr: 30BA615380E5: from=<****@powerreviews.com>, size=367, nrcpt=1 (queue active)
Aug 8 15:33:50 **** postfix/smtp: 30BA615380E5: to=<****@messaging.sprintpcs.com>, relay=mx.messaging.sprintpcs.com[188.8.131.52]:25, delay=0.9, delays=0/0/0.65/0.24, dsn=2.0.0, status=sent (250 ok: Message 185114376 accepted)
Aug 8 15:33:50 **** postfix/qmgr: 30BA615380E5: removed
We have the same issue and the tech support folks are total morons.
Our server is in a Tier 3 datacenter with dedicated IPs. IPs are not blacklisted - SPF checks out. I have spent 4 hours on the phone with the quality human beings in the support department explaining to them how an SMS gateway works. Not sure if they even know how to spell SMS.
I'd be grateful if they could transfer a call without dropping it - and that goes for supervisors as well. Totally Useless.
We were getting 554 errors sporadically - now we get 220's but after the data command is sent the connection drops.
Our solution is to move our handsets over to Verizon.
I seem to be experiencing the same problem. I have checked SMTP logs on our mail servers that have sent messages that were never delivered to my phone (or any other Sprint phones), and all log entries to Sprint phones show "250 ok: Message <message number> accepted" from 184.108.40.206. We have also been using <phone number>@messaging.sprintpcs.com for years and are not having problems with any other providers at this time. This Sprint thread looks similar:
I have checked our mail servers' reputations with SenderBase, but our servers have a good reputation. I have called Sprint support about this three times since March 21. Each time, a Sprint representative has told me that someone would call me back within some window of time (usually 72 hours), but I haven't gotten a single call back. The first time I called, tech support told me that it was due to a network problem on their end that they estimated would be fixed on Friday, March 23. The rep I spoke with said she'd call me back with an update that Friday at 2:30 p.m. Eastern time regardless of whether or not the problem had been resolved, but that never happened. I have waited at least 72 hours each time I have called. I have also mentioned these discussion threads and the fact that I have called before and have case numbers, but I keep having to re-explain myself. The last person I spoke with at least acknowledged that I had called the other times, but she just gave me yet another case number and promised a callback in 72 hours. I'm not sure what else to do at this point.
I got a call back from Sprint today, and they said they'll have to transfer my case to another group. I'll post something here if I get any helpful information.
Honestly, I got so tired fo the run-around and bad support that I just started relaying everything through a gmail account. I figure Sprint is never goign to block Gmail from sending to their gateways. Now my automated solution sends to a gmail account and a rule in the gmail account forwards to my phone via the Sprint SMS gateway. Having to take the extra hop is really dumb, but the Sprint gateway would accept mail from my Mail servers one day and then not the next, andf then start working again. This is a corporate mail server for a company, not some random server sending spam. I needed it to work 100% and this was the best I coudl come up with after getting bad/inconsistent answeres from sprint.
Wonderful how I as the user and paying customer have no say in sayign what servers I do want messages from, and can't even get a straigt answer from support...
Oh - one other benefit of the gmail solution... Now when I'm out of the country or can't get SMS service on my phone for whatever reason (heck even lose or misplace my phone), I have the gmail account as a backup and also can see the history of all messages sent to my phone in case something goes missing - that part actually kinda works out nice...
Exactly the same problem. Email to <myCellNum>@messaging.sprintpcs.com from my email server at work never arrives, but from my home or gmail accounts it works fine. My network administrator tells me that the logs show it being delivered, but it never arrives.
This has worked fine for the past 2 years or so, and it just stopped working last week. My 2 calls to Sprint tech support have been unhelpful. On the most recent one, the tech guy told me it was the 3rd such call he had received today, and then we were disconnected.
Delivered with TLS
Wednesday, Sep 19, 2012 09:36:09 AM EDT
Anyone at Sprint care to help me with this? I really need this to work, I have checked our domain and ip address ranges on senderbase.org as per previous posts on this subject, but everything is "neutral". Help?
Having trouble posting or viewing your Private Messages? We made an update to the Community registration process which requires you to validate your email, click here to read more about it.