Anyone know how to get Mailgun's attention when they have a blacklisted IP? All my email is bouncing and there is no way to get support (for days) unless you get a very expensive plan with them.
I went to the "IPs" section of the Mailgun admin, but I am not allowed to remove the one (blacklisted) IP associated with my domain.
Sure wish I had gone with the competition at the moment.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 2 years ago.
Improve this question
I am using AWS SES to send out emails automatically through my application.
I have configured the Identity management as following:
DKIM is setup correctly. I have no issues sending emails from my domain except for GMX and WEB.de emails where I receive the following error:
Action: failed
Final-Recipient: rfc822; xyz#web.de
(mxweb111) Nemesis ESMTP Service not available
554-No SMTP service
554-Reject due to policy restrictions
Looking at further documentation, it seems that emails coming from my domain are classified as Spam by their servers.
I have done research and found that I might need to configure Reverse-DNS but as it looks like, AWS SES does not support this?
What else can I do to make my emails get through WEB.de and GMX servers?
Thank you.
I was in deep conversations with AWS SES support regarding this issue. This is the outcome:
I also would like to update you that SES internal team were able to confirm a deliverability issue with the recipient ISP and are actively working towards a resolution but we do not have an exact ETA at this time. Due to the nature of the shared IP pool, these types of blocks can happen periodically and we make every effort to resolve these issues as fast as possible. To prevent impact from these types of issues, it is always recommended to use dedicated ips for higher volume sending.
It means that the shared IP addresses used by AWS SES are blacklisted with GMX and WEB.de
AWS SES wants to resolve this.
In the meantime, they recommend to use dedicated IP addresses to solve this issue.
Please note that these IP addresses have to be "warmed up" in order to not cause trouble on the recipient end (e.g. spam folder issues).
Unfortunately, my sending volume is not that high (yet) so I have my fingers crossed I can get those emails send out easily. Otherwise I have to find another solution or need to wait for AWS so solve the blacklist issue.
I hope this helps anyone else.
Edit January 2021
I was able to send to GMX/WEB.de although my IP was only starting to warm up. Now after one month I am nearly at 100% with not many emails per day sendout volume.
Several e-mail services operated by United Internet (at least GMX, Web.de) seem to have blocked Amazon SES IPs. Validity of DKIM, SPF, DMARC does not seem to have any impact on the block. I'm seeing these rejections in my logfiles as far back as 2020-10-05.
The alternative of using a the dedicated IP address has its own challenges. Managing and warming up new IP addresses for delivery can be very painful (e.g., Outlook.com was known to accept and then silently discard e-mails after IP changes).
I would suggest to write to mailsecurity#info.gmx.net or use their contact form https://postmaster.gmx.net/en/contact. I've received a response from them, although they didn't seem to fully grasp the issue. Maybe more contacts will help them see the importance of addressing this. Until then I am informing my users per banner of the issue (and recommending alternative e-mail services).
Amazon support has not been helpful for me. I've received one first-level response which indicated the responder had not understood the issue at all, but promised to forward it to SES support. Since then I haven't heard anything for a week.
Edit: since 2021-03-24, there are no more 554-Reject due to policy restrictions failures in my logs. Seems that either GMX or Amazon have done something to address this problem.
We have a service responsible for sending emails using AWS SES. This is working pretty well since we deployed it. But one strange thing start to happen a day ago (April 22, 2020). We have change nothing from our side and start to receives a lot of emails from Amazon SES:
What we already know:
As it is happening with almost all emails we sent, not all users all
are clicking in the "unsubscribe" link
The users are receiving the emails, once we know they are clicking in
the links inside of the emails
The emails we sent two days ago are exactly the same emails we are sending today. Both content and configuration
If anyone have past for this kind of problem, any help would be great
I haven't encountered the report abuse but have encountered the related bounce email issue several times. Not much is useful from FAQ (https://aws.amazon.com/ses/faqs/) but it does mention the reputation dashboard which you should be following to see if you are on the road to recovery.
Your tasks include:
1) Investigating if you send an email that could be considered abuse/spam under local laws of the receiver
At a minimum, you need to make sure you are offering the capability to unsubscribe and actually unsubscribe users in timely fashion. But also review content with an eye on local laws.
2) Ensure that users who do not want to receive email from you are removed.
This should be part of above.
3) Build up your reputation by increasing the percentage of valid emails.
This has been an issue for us in systems that send a small amount of email...it takes time to build up from a dip.
Remember - AWS wants to ensure it's multi-tenant mail servers remain whitelisted and that other AWS customers aren't impacted by any one potential bad actor.
On Monday morning messages sent via MailGun to our Office 365 account started to fail with the following message:
5.7.511 Access denied, banned sender[198.61.254.54]. To request removal from this list please forward this message to delist#messaging.microsoft.com. For more information please go to http://go.microsoft.com/fwlink/?LinkId=526653.
I checked on MX Toolbox and found their IP 198.61.254.54 listed in SORBS.
I cannot delist the IP from SORBS as the request has to come from the IP address which is listed.
I emailed the delist# address at Microsoft, who replied to say that the ISP/ESP is responsible for delistings.
I opened a ticket on Tuesday at 15:11pm with Mailgun support, asking them to delist the IP or change us to a different IP. It's now 15:42 on Wednesday and they have not acknowledged or replied to my ticket.
We send around 5,000 emails per month so are well under their recommended 50k+ threshold for a dedicated IP address.
Mailgun's control panel says:
For technical questions we recommend asking the community on Stack Overflow.
So here I am. What's my next move?
Mailgun support responded after 51 hours and said: "We have reviewed the error, and we have made adjustments on our side that will help solve this issue moving forward".
They had changed the shared IP address my domains were allocated to, and now mails are being delivered again correctly.
Another possible solution to this would have been for me to purchase a dedicated sending IP, although I was close to the lower recommended limit for this so I'm not sure if they would have improved deliverability in my case. I'm not sure if the purchase process for dedicated IPs is automated, or if I would have had to wait for a support agent to assign the new IP in any case.
Certificate errors happen from time to time but this looks very fishy too me. A certificate for all those names? What's going on? Got the CDN hacked?
If so, what is the best thing to do? Removing it until it is fixed? That would be bad for a good part of our user-base. A hacked CDN is worse though, I guess… Maybe someone knows what really is going on?
I am one of the maintainers of polyfill.io, and a Fastly employee. Yesterday we enacted a change to our DNS configuration to enable support for HTTP/2.0. In doing so, a small typo was made in the hostname, resulting in our DNS targeting the wrong endpoint on Fastly's network, and a cert that was not valid for polyfill.io or cdn.polyfill.io. Having realised the error, we corrected the entry and it took around 30 minutes to propagate.
Lessons learnt include not increasing DNS TTL until some time after a change is made, in case the change needs to be rolled back.
The reason there are so many names listed on the cert is that we are sharing a cert with other Fastly customers. This is perfectly normal practice for CDN providers.
More information is available on the relevant GitHub issue:
https://github.com/Financial-Times/polyfill-service/issues/1208
We're very disappointed to suffer this downtime. Generally, polyfill.io has a very good uptime record, and we plan for origin outages. It's hard to mitigate the risks associated with DNS changes to the main public domain, but we are very sorry to everyone impacted.
Polyfill.io uses pingdom to independently monitor our uptime and reports that number here: https://polyfill.io/v2/docs/usage (data has up to 24 hrs latency).
Looks like "they" (see below) botched it, I can't see cdn.polyfill.io or *.polyfill.io on that large list, hence the error saying much the same.
(or maybe I overlooked some other problem)
To enlighten you about the names, virtual hosting (the act of hosting multiple websites on the same IP address on the same HTTP port) occurs over HTTPS /after/ the encryption is established, thus, at the time the server presents a certificate to the browser, it doesn't know which site exactly the user is after, that information is part of the encrypted request.
Thus, it is necessary for the certificate to cover all secure websites operating on that IP address and port combination.
CDN for Content Delivery Network, presumably a huge bunch of stuff is being hosted on this "network", probably not even owned by polyfill (i've no idea who they are), given the first name on the certificate is "f2.shared.global.fastly.net" you can speculate the true CDN, who actually messed up the cert, and what else they're hosting on the CDN there :)
does anybody know agood way in granting a connection from one service to another, so that both services benefits fromeach other?
I would like to have an easy but never the less safe way to do a connection between my server and another server, but I don't know how to do that.
It should be ...
easy, so that neither the user nor the service providers have to waste alot of time
traffic effecient, so that traffic is not wasted and conenction is fast
encrypted, so that no person in between can use the transmitted data
and it should be an open and flexible standard, so that there could be more connections to other services (with my server in the middle of this star connection and no connection in between all providers) and that I don't have to pay a fee ;).
the example in the title is something I think about, because when you have a twitter account you somehow connect facebook to your account and facebook can show your twitterfeeds on your account.
but I don't want a provider to gather a lot of information beside the really important one that the user want to transmit. so I don't want the provide to get the username of my user and I don't really need to know how my user is named there.
It's like a post-office box. you just have to know where to put your letter, but you don't need to know the box owner's name.
and I don't want the mail-carrier to know what he is delivering, so it should be encrypted.
every clue how to do that would be fine, because I don't know anything about this :)
thank you in advance, Andreas
What you need is OAuth, check out the "Getting Started" guide to learn all about it
And the wiki entry