0

We want to setup our corporate SMTP server to use AWS SMTP, which uses credentials separate from the AWS Access key and secret. I am thinking that Amazon keeps these separate so that if someone is sending spam through our SMTP server, Amazon can shut down that account while not affecting our website/app that sends email through the SES API using the Access Key and Secret. Our IT admin proposes that if (somehow) someone sends a bunch of spam through our SMTP account (using AWS STMP credentials), Amazon would may shutdown both our SMTP credentials and our access key+secret leaving all our sites without the ability to send email through the API because someone abused the SMTP access.

StartupGuy
  • 220
  • 2
  • 6
  • If you send spam via either method your SES will probably wind up rate limited regardless of which method was used. – ceejayoz May 06 '14 at 17:38
  • They obviously know that the different credentials belong to the same customer. If they find that a customer is abusing their service it does not seem inconceivable that they will block the customer altogether. http://aws.amazon.com/aup/ and http://aws.amazon.com/agreement/ seem relevant. – Håkan Lindqvist May 06 '14 at 17:40
  • At the same time though, I would think that the reason they have segregation is specifically because they expect one set of credentials might be abused or there might simply be a bug in the system/app related to a IAM credentials. I perceive that this is why they include in their [documentation as an example](http://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPractices.html#use-groups-for-permissions), that you might have a "Developer" group. A junior dev with a bug in the code should not be able to take your corporate SES SMPT service, right? I can't find anything definitive though. – StartupGuy May 06 '14 at 17:48
  • 1
    A junior dev should probably be using dev credentials on another AWS account. You might be able to get a one-off support remediation of your spam rep, but Amazon has to protect the other users of SES. – ceejayoz May 06 '14 at 17:53
  • @M.Mugge If they just block specific credentials it will be more difficult for them to deal with those that really are there to spam. As for the required separation it could also be seen as "for your own protection" in a different regard, not that it's ok if your SES credentials are compromised and abused but rather that whoever got access to those can only send mail; not shut down all your other services, run a huge bitcoin farm on EC2 or whatnot. – Håkan Lindqvist May 06 '14 at 18:12
  • Since SMTP credentials are ubiquitously put onto Windows and Android devices throughout many organizations, I would automatically regard those credentials as being compromisable. It's simply a matter of time. So why should your site's SES API usage get hosed just because your company has 500 employees with email on their Android devices? ... It seems impractical (to me at least) that the compromise of one user device, (and by extension one IAM account) should affect your site's SES API usage/credentials/reputation – StartupGuy May 06 '14 at 18:43
  • It was mentioned by @ceejayoz how it could make sense to suspend a customer to save their other customers from further negative side effects. That said, I very much doubt that Amazon sees it as their best option to suspend or terminate accounts even though they clearly reserve their right to do so (presumably for severe cases). Also, I'm not sure what the chances are that someone can actually directly address your question as it seems to come down to how this specific service provider enforces their policies in practice which they are not at all as open with as what their policies are. – Håkan Lindqvist May 06 '14 at 19:28
  • I think you'd be loony to use SES for Windows/Android end-user device SMTP. That's not what SES is intended for, as far as I'm aware. It's a bulk email platform - sending transactional mail, newsletters, etc. I wouldn't want to use it for corporate mail. – ceejayoz May 06 '14 at 20:01
  • @ceejayoz :: No, it's not loony, it's by design which is the whole point why it uses IAM credentials instead of AWS key + secret. See [Ref-1](http://techwirenews.com/2011/12/14/aws-adds-smtp-support-for-amazon-simple-email-service/) + [Ref-2](http://docs.aws.amazon.com/ses/latest/DeveloperGuide/configure-email-client.html) ~ Alternatively instead of using individual accounts you might use a group IAM account for your corp mail server to [relay through SES SMTP](http://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-email-smtp-existing-server.html). – StartupGuy May 06 '14 at 23:06
  • I might add that there are various motivations for doing this, one of which is that it's VERY effective to keep our day to day corp emails out of people's spam boxes. – StartupGuy May 06 '14 at 23:09

0 Answers0