I am trying to set up mailgun with a real domain (meaning not with sandbox99887#.mailgun.org).
When coming to domain verification I hit a problem.
The SPF entry has been successfully verified within 5 minutes.
On the other hand the DKIM entry is still not good after much longer.
If it is only because it is taking more time, it is OK.
But I fear I may have done some setting wrong that could be the cause of the problem.
Anyone had this kind of experience before?
Related
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.
I have been testing out a ubuntu instance on GCS for the last couple weeks and a possible home for one of our web servers. Last week suddenly everything stopped working. I was not able to SSH to shell, and I couldn't even visit the site anymore through my browser. I logged into the dashboard and nothing seemed wrong. I had several other colleges try to go to the site and it loaded without any issues. I could not find any settings in the dashboard that would suggest some kind of block like this, so i assumed I must have triggered some kind of anti spam system. I decided to give a few days before trying to mess with it any further. after 6 days of not messing with it at all I still can not visit the site, or login via SSH.
Then to verify they are blocking my IP address and that it wasn't just something wrong with my machine. I switched my IP and then everything started behaving as expected once again. I can get to the site in my browser and can once again SSH into the VM. After switching back to my previous static IP everything went back to not letting me view the webpage, or ssh into the server.
My problem is that this isn't a permanent solution for me. I have many servers that only allow login from my previous IP address so I'd rather fix the issue with this VM rather then change all those system to allow from a new IP address. Any help on finding the solution would be greatly appreciated.
Please let me know if I can provide any additional info to help find the problem.
followup info:
The way our network is set up the IP we get from DHCP is the real world IP our device is seen with (I think we own a block or something)
this is the first time i've done anything with a GCS VM
Edit: added additional information
We started seeing this issue about 2 hours ago. It's happening very randomly. For example, if you copy and paste this URL for the image into browser, the chance of it not showing up for me is about 20%.
https://d1jbmqjs327xbn.cloudfront.net/_pa/spaces-developer.pxand/assets/images/apps/pos/pos-login-bg.jpg
Even after the browser able to load the image, it may not load if you do a hard refresh. Then it will eventually doing hard refresh 2-3 more times.
This seems like a networking issue on AWS side.
Another thing I saw is that 3 of my domains randomly became unreachable for a few minutes (I tested with ping) and then they eventually become reachable again without making any change on my side.
Is anyone experiencing the same issue today (Sep 20, 2017)? This is causing an issue for 10+ sites/apps I manage and I'm not quite sure how to solve this issue. Amazon is also not getting back to me on this.
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 :)
An exception occurred when setting up mail server parameters. This
exception was caused by:
coldfusion.mail.MailSpooler$SpoolLockTimeoutException: A timeout
occurred while waiting for the lock on the mail spool directory..
Recently i started to get this nasty exception in my mail.log file. Once this exception shows up, every mail that is sent from that coldfusion instance throws the same exception.
The only thing that seems to work is to restart the coldfusion server. After (usually) a day or two the same exception pops up again and we're back in the same situation.
I am aware of the hotfix to control the mailspool timeout but all it does is increase the timeout from 30 to 60 seconds. Since the mails are sent successfully until i get the exception, i don't think this is my solution.
Also i read the thread in the adobe forum where people have installed the hotfix, but still get the error.
I also tried a script to restart only the mailservice when this exception showed up, but this didn't work for me, as it didn't for others with this problem. This would also not be a concrete solution.
The mails that i send arre simple html mails.
The number of mails sent spreaded over a day is not more then 30.
I've sent mails from
the exact same coldfusion server many times before, but with
<cfmail>. This is the first time i'm sending them in cfscript. I
don't know if this has anything to do with it, but it's only since
i'm using the cfscript equivalent of <cfmail> that i started to get
this exception.
All related blog posts that i could find are all unanswered but also pretty old. I thought that someone might have a solution by now.
Thanks.
(using coldfusion 9.0.1 server on windows 2008 server)
We were also experiencing this mail spool lock issue. After the issue occurred a fourth time in 2 months, we started reviewing these forums and found no solution.
This made me think that perhaps the solution and problem are not really CF at all, so I went into the server's virus protection and excluded the CF mail spool directory so that the virus protection does not touch the spool directory at all. So far, we have not had the problem again.
So I am not sure that this is the permanent fix, but it has worked so far for us. No outside entities create emails within our systems, so the directory should be relatively safe but not having email-outs work is not an option.
this chain from talkingtree might give some light:
http://www.talkingtree.com/blog/index.cfm?mode=entry&entry=67FD4A34-50DA-0559-A042BCA588B4C15B
what they are saying is that it could be an issue with disk activity taking to long. you can increase the mail spool timeout with the jvm argument: -Dcoldfusion.spooltimeout=120
oh.... one more thing. if you're using cfmail to email dumps when an error occurrs, make sure to add 'format="text"' to the cfdump tags. some of the emails can get pretty big and might be causing the error.