[jeroenhd]

Things like this are to be expected with shared IP addresses for mail services.

This sounds like something Amazon should figure out more than anything. There's probably something going on with a customer or theirs (misconfiguration, spammer, vulnerability exploited) that's triggering spam detection rules.

At least Google reports the issue back to you instead of silently dropping all of your email like many other mail servers do.

[nomilk]

Very useful thread. I recently considered SES for a quick app and didn't discover the purpose of dedicated IPs. They're listed under add ons, but seem somewhat essential if the emails are important.

Checking out the pricing page, a dedicated IP costs $24.95 per month, which would be more than the actual cost of emails for many small-medium apps (e.g. 100K emails per month would be about $10).

Ooc, do other email providers have the same shared-IP problem? E.g. Mailgun, Postmark, Sendgrid?

Source: https://aws.amazon.com/ses/pricing/

[LinuxBender]

do other email providers have the same shared-IP problem?

Yes, that is why they let people get a dedicated IP pools and FCrDNS using their corporation name for a price. It is not uncommon for the shared IP pools to get rate limits, temporary blocks, etc... and the corporation specific dedicated IP's are more likely to get through especially if they handle UCE complaints properly.

[nomilk]

> Yes

I didn't spend a huge amount of time reading the docs (just enough to get up and running), but I didn't notice this about other providers either. Great to be aware of this for future reference.

[dubcanada]

Postmark spends A LOT of effort to keep their shared IPs perfect. Rather complex setup with verification. And lots of stuff in place to prevent anything spam related.

But everyone else doesn't really care much.

[shmoogy]

Dedicated can be an issue unless you have sufficient volume, unless I've been mislead in the past.

[bdcravens]

Sendgrid's cheapest plan with a dedicated IP is $89/mo.

[alyandon]

I finally started sending anything from AWS SES straight to trash because the spam on their platform is persistent and they are non-responsive to spam reports. I was getting 30+ fraudulent/spam emails a day in just one inbox alone.

[nostrebored]

That's untrue. I can tell you that spam reports and bounces are monitored, and customers do have to go through validation of their workflows if they breach thresholds.

I had to help multiple customers who had access to SES shut off for valid use cases because they didn't handle events coming back from customers appropriately.

[alyandon]

  I can tell you that spam reports and bounces are monitored

If they are, I saw no evidence of that (except for the initial auto-response) based on the numerous spam reports I manually submitted with headers, dates/times and body content.

If you work for SES, you all aren't acting swiftly enough to shut down egregious spam operators using your platform that are making other people's lives miserable.

[dpifke]

I have never gotten a response to an SES spam report.

A quick search turns up 50 or so in my sent mail folder within the past year or two.

3 of the most recent 5 reports are all the same message content (likely the same sender, although possibly using different—maybe hacked—accounts).

By way of comparison, I've sent a similar volume of complaints to Twilio Sendgrid, received a response to every single complaint, and a random sampling of recent reports doesn't show any repeat message content.

Google doesn't even provide a way to report spam from Gmail users, which is ironic given the OP is complaining about Google's aggressive spam blocking. Spam from Gmail is comparable in volume to what I receive from SES and Sendgrid, and almost all of those messages are obvious phishing and 419 scams. (One would think one of the largest tech companies in the world would be able to implement basic filters to catch these, if they cared enough to do so.) Cf. spam from SES, which is mostly either cryptocurrency pump-and-dump, or semi-legit companies sending to spamtrap addresses that appear on publicly-indexed web pages, in WHOIS, etc. but which have been never used for real correspondence (and have obviously never opted in to any lists).

[whoknew1122]

No response != nothing being done with the report

[alyandon]

Sending the report to /dev/null would technically be doing something with the report though.

My problem is "no response to report" combined with "I continue to receive the same or substantially similar volume and types of emails from the same sender(s) from the same email provider weeks after submitting the reports" == "non-responsive email service operator".

[0ct4via]

Your experience of customers not handling events appropriately - and then having SES access revoked - does not negate or disprove alyandon's experience of getting no responses to spam reports.

You may have had a different experience, but that doesn't make their (differing) experience "untrue."

[moltar]

Not sure if this is an edge case or not. But getting approved for SES isn’t that simple. And then shut downs happen very quickly even for legitimate cases. AWS is very aggressive with SES.

[alyandon]

Maybe they care now. They certainly did not appear to care when my mailbox was getting spammed into uselessness by their customers.

[baobabKoodaa]

Google also silently drops mail in some cases.

[jeroenhd]

I've never experienced that. When mail gets dropped, my experience is that you either receive a notice from the SMTP service or get a DMARC report that tells you about the percentage of dropped mail.

[baobabKoodaa]

Please explain how you measured your email deliverability.

[jeffbee]

Which cases?

[betaby]

Impossible to know. But in my cases from any IP with low volume. I.e. I have a bunch of personal servers for 10+ years, there are rarely outgoing emails from them and google happily just black-hole emails from such low volume IPs.

[jeffbee]

I'd be surprised if this was accurate. A low-volume IP might get a temporary failure code 4xx, but that's not silent. If they accept your message they intend to deliver it, or bounce it. Perhaps your return path is defective.

[alyandon]

Google used to do this for low volume emails I was literally sending to myself by authenticating with my google smtp account credentials. I could find no rhyme or reason to it. It would claim to accept emails and they would never show up in my inbox or in spam. Sometimes they would get delivered to spam. Sometimes to my inbox like expected.

It most often involved security log snippets which would include ip addresses and hostnames that were likely already on "is a known bad actor" list.

Bug on their end? Intentional thing to disrupt spammers? I don't know.

[jeffbee]

Well, I won't contradict your personal experience, but I will say that I worked on gmail delivery for six years and if during that time it had ever come to light that any message had been accepted and not ultimately disposed of in some way, that would have been P0 and dozens of people would have dropped everything in order to root-cause and remediate that.