I have been sending emails (through gmail accounts and gmail smtp server) to text gateways of various wireless providers and they worked pretty well for years until this year. The messages stopped working for all verizon numbers a few months ago. I didn't receive any feedback as to why it stopped working. It is as if the email was sent successfully and then silently swallowed by vtext.com. I tried to limit the number of recipients per email but it didn't help. I did a lot of searches online but could not find a sure reason what has been changed. I started to suspect that my ip or domain has been blacklisted by verizon, but I have no way to contact verizon support about its gateway policy and whether my suspicion is true. The customer support of the wireless department said he knew nothing about vtext.com and thus could not help. All my messages are sports team related (inclement weather, etc.) and they are not spams.
I'd really appreciate any help on finding out the true reason this stopped working, and who/where I can contact to resolve this. This is very important for my web site.
Thanks!
This is why...
It's all about revenue. If you were using Vtext, good chance you have been blocked by Verizon and they want you to purchase enterprise services. Happened to my company today and this has been a critical part of our system to page work orders out to field technicians that service medical equipment. Verizon has affected patient care, and seem to not care when I asked if they can unblock us just so we can make a strategic transition.
I noticed the same thing recently. When I called care they told me vtext is being decommissioned in favor of messaging+, which to my knowledge doesn't have an email gateway. Apprently your region and mine are gone and the plan is to have all vtext shut down by end of 2016.
Currently looking in to alternatives.
I noticed this, too. However, I've found that the mms gateway still works.
<phone_number>#vzwpix.com
Related
Our IP address recently got listed on UCEPROTECT-1 as a potential spam address, and we aren't able to figure out how to stop this. According to their website, UCEPROTECT-1 listing happens when: IP's get listed in Level 1 automatically if they either try to deliver e-mails to spamtraps or if they are involved in port scans or probes or any kind of attacks against our servers
Some research online suggests that the only way to ensure it doesn't happen again is to find out what is triggering these spam traps and plug them.
Any idea how we can go about looking for what is triggering these automatic listings? Any help would be appreciated!
Some background:
We use GSuite for our email servers, wix.com for our website, and namecheap.com for our DNS.
We'd originally paid to not be listed in the UCEPROTECT-2 and 3 listings but were automatically removed as soon as we got listed under UCEPROTECT-1.
I don't know how G-Suite works but in general check
logfiles of the outgoing e-mail servers for days with "strange" recipients patterns or for more e-mails than on other days
if your domain is listed on other blacklists, maybe that is giving you other hints
The problem is: if you are using the outgoing e-mail servers from Google and some of them are listed on UCEProtect (because other G-Suite customers are sending spam, mostly without knowing it cause they are hacked), you have little chance of fixing this yourselve. This is not really uncommon, me.com/icloud.com (17.58.63.0/24) is listed at UCEProtect right now too.
I'm aware this may not be the right place to ask this, but I don't know where else and others may encounter the same issue.
I'd like to have an aggregated view (or an alert) when some recipients in my contact list don't receive any of the emails my app sents. Is this possible?
I checked on the alert thing in the docs but it doesn't seem to do what I need. Although this seems like a pretty common need and there may not be necessary to setup webhooks and own app logic to handle this, wouldn't it?
Thanks
I have also faced same issue with cPanel and many other providers like Mailchimp. This usually happens due to Empty Subject due to which Cross-Server Contacts may not happen. Also, if you are using PHPmail() or sendmail function instead of SMTP, You need to be using TLS1.2 or TLS1.3 though 1.0 is also supported but many of my E-mails were not delivered so I upgraded to TLS 1.3 . Also, Check if your mail goes to Spam Folder. In that case, increase your Website and Domain Score and Try to rank in Google Safe Browsing. Also, this also happens due to misleading Hosting Provider whose SMTP servers are not setup correctly or Provider send many spam messages due to which, you domain score may got low. I currently use interserver_smtp and cloudmate_smtp collectively for all my clients as interserver deliverablility in India is low and cloudmate works in both texas and india correctly. Try cPanel or Plesk as it has the best deliverability. One More thing, This could also be an issue of DNS. Check your DNS settings if MX records are pointed to MailJet Servers.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
The mail server I manage is clean according to 92 blacklists checked by MXToolbox.
But ...
host mx.ecentral.com.cust.b.hostedemail.com[64.98.36.4]
refused to talk to me: 421 4.7.1 Service unavailable; Client host
[My Server IP] blocked using tms.urbl.hostedemail.com; Your IP has been
sending too much spam
How does one get off of this list? What puts one on their list but not on any of the ones with more obvious rules? Is hostedemail.com some kind of rogue provider?
Thanks!
What's crazy about this (to me, anyway) is that both hostedemail.com and urbl.hostedemail.com have no A records and no website, not even a redirect or a single page that would give people the bare minimum information about their blacklist or service. That's not how professionally run blacklists are managed these days.
My users are getting this:
host mx.DOMAIN.org.cust.a.hostedemail.com[216.40.42.4] refused to talk to me: 554 5.7.1 Service unavailable; Client host [1.2.3.4] blocked using urbl.hostedemail.com; Your IP has been manually blacklisted
It's the reference to manual blacklisting that flummoxes me. None of my servers are in any of the blacklists checked by MxToolbox (and like most mail admins, I work hard to keep it that way), so if someone has taken the time to manually add the IP address of one of my servers to the list then this sounds as amateur as my own manual blacklist I use on my servers when I have no patience waiting for a spammer to be shut down or blacklisted. And it has been there for at least a week; I haven't bothered checking last week's logs, as a week is long enough to determine whether or not a server is (still) sending spam.
After some research I found this post:
What does this error mean when emails are bouncing back to sender?
That led me to:
https://fbl.hostedemail.com/
... which is actually a branded CNAME for fbl-opensrs.app.returnpath.net that leads to:
https://fbl.returnpath.net/
So at the end of that long trail I ended up signing up for Return Path's FBL for their short list of 22 ISPs (including, as far as I can tell, a couple of individual companies' email systems). In doing so I have now agreed to them sharing my "Personal Information with business partners or other third party sponsors of sweepstakes, contests and similar promotions from time to time" (seems like a bizarre provision for the terms of service for a B2B company, especially one whose raison d'être is about reducing spam, but what choice do I have?), but I am none the wiser yet on why my one server's IP address has been blacklisted.
However, like #StephenB, I am going to abuse my standing as an OpenSRS reseller (an account I have all but abandoned because of their crappy service) and send their support department an email. I expect I'll get the usual "not my department" reply, as happened sometime last year when someone was registering phishing domains spoofing one of my user's domains. I'll post the results of that in a comment when/if I hear back.
UPDATE: I did email OpenSRS reseller support and (to my surprise) they responded within the hour to (belatedly) inform me of the FBL. Another seven hours later they de-listed my IP and the delayed mails in the queue went through.
I brought up some of my points above and this was their reply:
Thank you so much for your feedback, certainly your concerns are understandable. At OpenSRS/Tucows we're always looking to provide a better service, and definitely we can see your point as far as blacklist/delisting goes, for the time being I believe the reason for this is due to a lack of resources to put something like this together, but certainly I can assure you it is on our radar. I will pass this information along to our managers so that we can ensure your voice is heard.
Platitudes, but nevertheless positive platitudes.
UPDATE 2: Well, the platitudes didn't last long. They blacklisted my IP again, and this time I was just patronised instead:
I am just replying back on the RBL listing you inquired about and I can confirm the IP was once again de-listed but I did get some additional information for you as requested. I needed to do a bit of checking but the IP x.x.x.x is provided by RIPE Network Coordination Centre, the IP assigned to the user by the hosting provider carries the reputation of the rest of the CIDR. The nature of VPS/Shared IPs is to be disposable, and it is not suitable for sustainable mail services. I would suggest that you should be renting a dedicated IP/CIDR directly from ARIN or any other static IP provider to avoid further listings from happening in the future since its [sic] not necessarily your customers being listed but the IP being listed. But of course for the time being we have de-listed the IP but assuming nothing changes its [sic] likely it will be listed again in the future. Let me know if you have any questions from here.
We've been using VPSes for mail since 2008 (after a lot of thought and research), and have never in that time had an issue. I understand the sentiment that VPS IPs have a lower reputation in the minds of sysadmins with long memories, including myself, but in this day and age this is like saying that "I don't like x nationality because of what they did to my great-grandfather during the war." Properly maintained blacklists are supposed to have a memory hours long (in most cases; not all, of course), not generations long, and OpenSRS/Tucows/Hostedemail are blocking data centres worldwide full of legitimate mail servers, that nobody else are blocking. I diplomatically told them they're using thinking that became obsolete around the end of the last century.
I already have one of their customers (that our users were having trouble emailing) talking to us about moving.
If WiTon Nope's answer was correct at one point, it doesn't appear to be accurate anymore. They blacklisted my server as well, for no apparent reason, and it took a week of chasing them to get that resolved - and it appears that the only reason it didn't take longer (or got resolved at all) is because I'm already an OpenSRS reseller for domain registration (I don't use their EMail service, and I certainly won't be after this experience). Even then, I had to resort to calling them, because the attempts I made to contact them via their reseller support EMail & Twitter were all ignored. Oh, and unlike nearly every other RBL I've dealt with, they fail to provide any method for requesting delisting.
Also, the suggestion to check MX Toolbox doesn't seem to be relevant, since they don't actually monitor urbl.hostedemail.com - and same as with Daniel Wilson, my server wasn't on any of the (more than 40) RBLs that MX Toolbox does monitor.
To top it all off, once they finally DID resolve the problem, they refused to provide any useful details, like ANY reason for having listed my server, or even so much as confirming that there WAS a reason in the first place. I try not assume that people are acting in bad-faith, but I can't think of any reason not to provide the justification for the listing - unless they discovered that was no valid reason for blacklisting the server, and are just trying to weasel out of admitting that they screwed up.
hostedemail.com is used by OpenSRS providing email hosting service and it's not a blacklist directory. You don't have to worry you have to wait for couple of days while your IP will be refreshed accross all mailservers and dns globally.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
[Our website] is very dependent on being able to successfully send email to its members. We are currently having trouble reaching all our members, especially hotmail users.
What do you recommend we do to improve our sending of email?
We are sending heavily user customized emails. So a third party solution would need a good api
to support this.
Possible solutions:
Would sending email through the app
engine help for delivery rates?
Does returnpath help? http://www.returnpath.net/
Update:
Some good comments on how to improve and test our own email sending capabilities. Another option would be a third party solution.
We're sending updates on your networks activities, registration emails, new comment emails, new follower emails these type of things. Especially your networks activity is highly individual and problematic with most third party emailing solutions. Would need a very flexible email solution.
Are there sufficiently capable solutions out there?
We had a similar issue a while back.. You probably want to read up on Microsoft's Sender ID:
https://www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx
and look at the link called "Sender ID SPF Record Submission Form".
Postmark and Sendgrid seem to offer a very decent api to use for sending email and improving deliverability. As a bonus stats are also handled by them.
1 ) using shared ip
2 ) sending more than 1000 email per hours may cause Spam
3 ) sending from root server without SMTP login may cause this problem
4 ) contents email has links from websites blocked from RBL ( Real Time Blacklist )
5 ) ...
I'd in general be pessimistic about the IP reputation of platform-as-a-service type offerings. Testing Google AppEngine is on my to-do list, but I've there's been much talk about Amazon EC2 presenting a real problem -- these products are not very efficient preventing use by spammers, and reputation is taking a hit.
As for the practical steps of setting up outbound email, Jeff Atwood has a very nice and nearly comprehensive article on his blog.
What I'd certainly suggest is:
Make sure your sending IP has a reverse DNS.
Check your IP reputation for example at senderscore.org (though that's heavily US centric)
Make sure bounces are handled on your side, and postmaster#your.domain is reachable
Set up SPF and DKIM. SenderID if you want to.
Sign up for all feedback loops at major mailbox providers / ISPs and act on spam complaints -- if your user complain, you're doing something wrong. Also, set a "friendly name" on your From: address, as some mailboxes will only display the local part -- " Update" is friendlier than only seeing "automatic" (Gmail does this).
Watch the volume you send. If it's high from the start (>1000s/day to each major ISP) you may get blocked outright.
You'll find a lot of deliverability tips, most of the time from interested parties (email service providers). A relatively reputable resource is deliverability.com, backed in part by Return Path. Of course, going with a commercial email service provider might be a solution for you, but your use case is quite specific and you'll need real-time individual messaging, not marketing newsletters, if I understand you right.
I worked for a company that re-sold Return Path's tool -- so take this with a pinch of salt: It' won't help you get delivered. It can, however, be a valuable tool tracking down where your problems are. It is on the other hand expensive, and hiring a specialist that can go through your specific case might be more affordable. Or reading a lot and experimenting a lot yourself.
#chryss does a great job pointing out the important factors that need to be taken into consideration:
-- reverse DNS, sender reputation, list management (ie, cleaning lists of addresses who have marked your email spam, invalid addresses, etc and keeping track of hard and soft bounces and acting accordingly to those events), SPF records, DKIM signatures, ISP feedback loops, ISP rate limits. Also, email content is important to keep in mind.
Generally speaking, this is all pretty complicated and annoying stuff to deal with, especially as your email volume increases.
In terms of IP reputation with PaaS systems, the key thing to remember is this:
-- if you share an IP with someone who earns a poor reputation (say, a spammer on EC2), that reputation will negatively affect your deliverability. On the other hand, if you send from a dedicated IP, you have the opportunity to earn your own reputation - if you are a good sender, follow best practices, and your customers want the emails they expect to receive from you (which they should since it sounds like you are sending mostly transactional emails), you will maintain a great reputation and should enjoy good deliverability (granted all of the technical stuff mentioned above is taken care of).
We generally keep an eye on deliverability "chatter" online, and send out all the cool/useful stuff that we find on a daily basis through our twitter feed -- feel free to follow us: twitter.com/sendgrid. We are also beginning to ramp up our own blogging, so you can join the conversation if you like: blog.sendgrid.com.
If you want a comprehensive solution without having to do a lot of troubleshooting/fact-finding, just check out SendForensics.com. Disclaimer: I am affiliated with the company.
Regards,
Russ
Deliverability issues generally happen if there is something wrong with any or all of the following elements:
Email Content
Server Configuration
Email address and Domain reputation
IP address reputation
More information here
We run a large online community in the Netherlands. Because of that we send a lot of mail to the hotmail email addresses of our members.
Recently we have noticed that not all mail is reaching our members, because we have hit a certain limit or so it seems.
Google doesn't give a solution (yet) but we see a lot of others having the same problem.
Note, We have added (since long) SPF records for our domain, in TXT and SPF types.
What else can we do to tackle this problem?
// Ryan
To add to what bzlm said, hotmail probably isn't rejecting your mails, so much as trying to use rate-limiting to prevent spam. That said, there are a few potential solutions you could use here. You could contact hotmail and see about getting your mailserver exemption status from their rate-limiting. Depending on the size of your community, they may or may not respond to you or be willing to work with you. I suggest this only as the "diplomatic" solution.
Or, you could set up two mail servers; one for hotmail users, and one for everybody else. I know from some of the sites that I run that a lot of people register with hotmail accounts, mostly because everybody has one which they use as a "spam dump" for online services where they don't want to use their real email address. So, as you no doubt realize, the number of hotmail users in your database represents a fairly substantial percentage. Therefore, when you need to send an email, you could determine whether to send it to your normal SMTP server, or your hotmail-designated one. On the hotmail SMTP service, you'd need to add some type of waiting mechanism to sleep a certain amount of time after receiving a 421 response.
The problem with this idea is that the number of hotmail users you have, plus the delay you'll encounter in sending, means that the queue length might very well exceed the number of mails you must send. You could alleviate this problem by setting up secondary/tertiary servers, preferably on other networks... but I'm getting ahead of myself here. At any rate, I did a bit of googling around (as you probably have, too), and this isn't such an uncommon problem, but there is no obvious solution to it.
So likely, you'll either have to create some type of slightly-unorthodox network workaround, or try the "diplomatic" route and contact an organization unlikely to care about your problem. I'd suggest doing both in parallel. :)
421 means that the service is not currently available, and that the client should try again. This could be for any number of reasons, including trying to discourage you from too frequent mailing if Hotmail thinks you might be a spambot.
Why not simply let your outbound smtpd queue the mails and try again?
Why is "not all mail reaching your members"? Don't you try again if you get a 421 response?
EDIT: Do what sqook says.
The only real way to "get around" this is to become a good e-mail citizen. Make it easy for people to unsubscribe from your notifications, establish complaint feedback loops with the major mail providers, remove bouncing e-mails from your list automatically, don't send people e-mails they don't want to receive. Failing to adhere to these simple requirements makes you look like a spammer, and providers like Hotmail will treat you like one.
The mail server IP connecting to Outlook.com server has exceeded the rate limit allowed. Reason for rate limitation is related to IP/domain reputation. If you are not an email/network admin please contact your Email/Internet Service Provider for help.
https://mail.live.com/mail/troubleshooting.aspx
I advise you too wait some times