What secret Masonic handshake do I need to sign up to AWS/SES or SendGrid?


(Jon) #1

I am continuing to work on my form-to-email project, and it is going well, albeit slower than I anticipated. I am currently working on a subsystem to let a user confirm their email address.

I’m currently using the free compute tier of AWS, and that was something of a struggle to sign up to. I’d triggered their automated security checks (possibly by virtue of using a VPN and NoScript), and they’d sent a message requesting images of “recent utility bills” and all manner of stupid hoops to jump through. They already had my confirmed phone number, real name, business name, and postal address. I emailed them a fairly stiff message, and thankfully they relented:

Greetings from Amazon Web Services.

We have reviewed your account and removed the temporary hold.

We apologize for any inconvenience this may have caused and appreciate your patience with our security measures.

Thank you for your interest in Amazon Web Services.

So, I thought I’d try their messaging service (SES) for transactional email. This is understandably sandboxed to start off with, and one can only send to authorised addresses until the hold is taken off the account. So I applied for this, giving all manner of details, and requesting a very low sending limit (I’m just testing and prototyping for now).

I received the following corporate stupidity in response:

Hello,

We regret to inform you that we cannot grant your request for increased Amazon SES sending limits in AWS Region EU (Ireland) at this time.

We have determined that your use of Amazon SES may adversely impact our services. For further information about our policies, please review our Acceptable Use Policy and Service Terms:

Amazon Web Services™ Acceptable Use Policy: http://aws.amazon.com/aup/
AWS Service Terms: http://aws.amazon.com/serviceterms/

If you wish to appeal this decision, please reply to this case and provide as much information as you can to let us understand your use case.

Best regards
ZZZ
Amazon Web Services

Urgh. So I have no idea what the problem is, and they don’t want to tell me. I’ve complained, for all the good that will likely do, and even if I were to pay for services from them in the future, they can certainly afford to lose any trivial business I might give them.

So, undeterred, I tried the same with SendGrid, who also have a good free tier. I managed to trigger their security gremlins as well, and my account was put on hold. I logged a support case, and received this:

Hello,

I apologize for any confusion.

It looks like there was an error in your sign up information. In this case you will need to create a new account.

In creating this new account, please verify that all of the information used is valid and correct.

Let me know if you have any other questions.

Best,
AAA

Lots of “regards” from people who are not empowered to help me. So, I created a new account, and that was automatically blocked too. When I complained a second time I got this gem:

Hello,

Thanks for reaching out. SendGrid leverages many different vetting techniques and as such we’ve determined that you’re not a good fit for our platform. Because of this, we will not be able to activate your account. Our system does not provide myself or other members of Support with details regarding decisions made in the sign-up process. As such we are not able to provide any more information to you.

I apologize for this inconvenience.

Best,
BBB

I don’t know if it is the Silicon Valleyism of my having “reached out” that irritated me so much, or the further supply of cheery wishes from someone who has no intention of helping. And I’m being told by this plonker, who knows nothing about my work, that he’s sure I am “not a good fit for our platform”. :angry: :rage:

OK, apologies for the rant. It makes me feel better, if nothing else. I am not sure if it is aimed at the general soullessness of corporations or the phenomena of modern customer support departments whose sole purpose is apparently to wind up customers.

So, AWS and SendGrid were worth a try as they both have good free tiers (ideal for the unfunded entrepreneur) but they look like they’re out for now. I can use SMTP from my VPS, but any suggestions as to other senders I can try? What are you using in your own projects?


(Greg Robson) #2

Coincidentally I had a YouTube suspension on my new screencasting channel account today - due to “violating spam or advertising terms”. I followed their process (telling them why I think they blocked me) and it was restored. I think the screencasts might have triggered a bot for having some mostly static video being attributed as spam! Would be nice to be told why they blocked me so I can avoid it happening again!

Anyway, your issue! (My rant is also over :wink: )

Personally I use SparkPost - 15,000 emails a month for free with a dev account with tiered pricing volumes. They got a lot of attention for transactional emails after Mandrill was consumed by MailChimp.

First things first, has your email sending domain been verified by your providers? Normally they ask for some domain records to be set and/or ask for you to place a record on your website that they can load to verify you do manage the domain?

What volumes are you sending? Some services don’t like you sending a lot of emails very quickly. I think it was this episode of the CodePen podcast when they discussed having to “ramp up” usage on an IP address. If an IP goes from 0 to 50,000 emails/day within a couple of days it’s often assumed to be a spammer’s server. I think most providers like you to send a trickly in the early stages.

I would imagine a VPN and noscript might make email services edgy. Probably best to reach out to SparkPost first and ask them if your usage scenario is compatible. They seemed quite amenable when everyone fled from Mandrill. They prioritised a lot of features that they were missing that Mandrill users still needed.

(Incidentally SparkPost runs on AWS’s infrastructure!) :man_shrugging:


(Jon) #3

Thanks for suggestions. Having been driven to distraction today by infuriating and robotic helpdesks, I am grateful for the tea and sympathy!

My domain has not been verified in either case. I believe I have access to the dashboard functionality to do so at Amazon (since I still have access to the free EC2 tier) but presently their response suggests to me that they aren’t interested in letting me out of the sandbox, even if I dance an elaborate jig of their choosing. It’s even worse at SendGrid, where I have lost access to the dashboard completely.

Neither have suggested 2FA, which surely would resolve the issue (I am already confirmed via 2FA at AWS!).

At present, it would be only a few transactional emails a day, for my manual testing. I don’t have any users, and I don’t expect to open the doors for alpha testing for another month or two. From that point, I would expect usage to rise slowly and organically (in a way that does not frighten the provider horses).

Good idea, I will do that.

Out of interest, from their pricing page, there’s this:

Our free Developer Accounts provide a sandbox for ongoing development and testing. Send 15,000 emails/month with the same built-in functionality and performance as our paid tiers — with no time limitation.

What does “sandbox” mean - are they only delivered to a limited subset of to addresses? Ideally I am hoping to send real email on the real internet for free until my business generates some money :blush:

Well done for slaying the Google Support monster, that must have taken some doing! :dragon_face:


(Greg Robson) #4

I’m not aware of any limits. I believe they meant some kind of “testing environment” in the sense that you can use it to see if it suits without worrying about cost.

I would definitely get any sending domains verified before sending emails https://www.sparkpost.com/docs/getting-started/setting-up-domains/ - I think the trust level is probably less than 10% without it and 90%+ with it.

2FA only shows that nobody else can compromise your account. DKIM and SPF can validate that you definitely have the right to send from a domain (otherwise anyone else could sign up to AWS/SendGrid/SparkPost and pick a domain at random).

Good luck with the app, keep us updated :slight_smile:


(Jon) #5

Great, thanks.

True. But my implication was that spammers would not be willing to jump through 2FA hoops because they’d very quickly run out of numbers that were not blacklisted.

In other news, Amazon just emailed to annoy me some more. Thankfully, they included some more best regards, which helps enormously. Nice one Dilip!

Hello,

After reviewing the additional information you provided, we have confirmed our original action of denying your Amazon SES sending limit increase request in AWS Region EU (Ireland) .

Unfortunately we are not able to provide specific details as to why your application has been denied, but we took this action because your use case is one that could adversely impact our services.

Best regards,

Dilip Kumar K.
Amazon Web Services


(Stuart Langridge) #6

I’ve always had good experiences with Mailgun.


(Marc Cooper) #7

There’s a lot to be said for a $5/month Linode and an ansible script.

Old school, I know, but it “just works” year after year.

(I do have an AWS account too. Just in case you think I’m a complete fossil.)


(Jon) #8

Thanks. In the unhappy event of SparkPost falling through, I will look at those folks next.

Yeah, nowt wrong with that, and when I go live, sending SMTP myself may be what I end up doing. I like the look of Linode too - they just bumped up the RAM on all their machines, and there’s a lot to be said for fixed cost pricing. Hopefully their support is a bit less miserable than Amazon’s!


(Daniel Hollands) #9

Subscribed

As a business, we’re moving from SendGrid to SparkPost. We were somewhat upset that they suddenly changed the way they worked (limited the number of sub accounts allowed) without telling anyone, leaving us scrambling for a new process that was compatible with the changes.

Only one client have been moved over so far, but it was trouble free, so (at this early stage) I’m happy to recommend SparkPost.


(Greg Robson) #10

Thank you. It’s a work in progress. I’ve been learning a lot about sound and video editing… and that HD video takes a freakin’ age to encode and upload (to YouTube and BackBlaze). So far the feedback has been positive :slightly_smiling_face: - but even (constructive) negative feedback is welcome as well.


(Jon) #11

I popped into their Slack channel for a chat, and noted a few things of interest:

  • They seem to allow a high degree of access between devs and customers, so you can always talk to someone knowledgeable
  • Unless they were PR plants, their customers seem to appreciate this, and say so frequently
  • The dev staff were putting out a lot of fires - auth broken for both SMTP and the API, long timeouts, periods of unreliable sending not reflected in their status page, etc. I would recommend a local MTA like Postfix for retry functionality on the app side, or a queue system that retries HTTP API calls until they are done

One of their folks has shown me how to get started as well, which I will do in due course.


(Matt Andrews) #12

To be honest it sounds pretty understandable to me: they’ve detected you’re using a VPN, and presumably other less nice users of that service have abused these email services in the past, therefore you’re a big risk for them.

Is using the VPN a requirement?


(Jon) #13

No, not at all. My laptop is configured to use one permanently, to the degree I mostly forget it’s there. I agree this might have been their gripe. I didn’t even send a single message via SES - didn’t even get a chance before being told to get lost.

My frustration is that neither of the above organisations will confirm what the issue is, and repeatedly refuse to let me correct it (as Greg says, this can be done with domain records). I have therefore been banished to the sin bin permanently, which is then compounded by some infuriating and hollow apologies about my “inconvenience”.

Once I get hosted SMTP working, it’ll be called from my static AWS IP anyway. For now, I’ve just used my ISP’s SMTP service, which is fine for testing.