Tag Archives: Amazon WorkMail

AWS Week in Review – October 24, 2016

Post Syndicated from Jeff Barr original https://aws.amazon.com/blogs/aws/aws-week-in-review-october-24-2016/

Another busy week in AWS-land! Today’s post included submissions from 21 internal and external contributors, along with material from my RSS feeds, my inbox, and other things that come my way. To join in the fun, create (or find) some awesome AWS-related content and submit a pull request!

Monday

October 24

Tuesday

October 25

Wednesday

October 26

Thursday

October 27

Friday

October 28

Saturday

October 29

Sunday

October 30

New & Notable Open Source

  • aws-git-backed-static-website is a Git-backed static website generator powered entirely by AWS.
  • rds-pgbadger fetches log files from an Amazon RDS for PostgreSQL instance and generates a beautiful pgBadger report.
  • aws-lambda-redshift-copy is an AWS Lambda function that automates the copy command in Redshift.
  • VarnishAutoScalingCluster contains code and instructions for setting up a shared, horizontally scalable Varnish cluster that scales up and down using Auto Scaling groups.
  • aws-base-setup contains starter templates for developing AWS CloudFormation-based AWS stacks.
  • terraform_f5 contains Terraform scripts to instantiate a Big IP in AWS.
  • claudia-bot-builder creates chat bots for Facebook, Slack, Skype, Telegram, GroupMe, Kik, and Twilio and deploys them to AWS Lambda in minutes.
  • aws-iam-ssh-auth is a set of scripts used to authenticate users connecting to EC2 via SSH with IAM.
  • go-serverless sets up a go.cd server for serverless application deployment in AWS.
  • awsq is a helper script to run batch jobs on AWS using SQS.
  • respawn generates CloudFormation templates from YAML specifications.

New SlideShare Presentations

New Customer Success Stories

  • AlbemaTV – AbemaTV is an Internet media-services company that operates one of Japan’s leading streaming platforms, FRESH! by AbemaTV. The company built its microservices platform on Amazon EC2 Container Service and uses an Amazon Aurora data store for its write-intensive microservices—such as timelines and chat—and a MySQL database on Amazon RDS for the remaining microservices APIs. By using AWS, AbemaTV has been able to quickly deploy its new platform at scale with minimal engineering effort.
  • Celgene – Celgene uses AWS to enable secure collaboration between internal and external researchers, allow individual scientists to launch hundreds of compute nodes, and reduce the time it takes to do computational jobs from weeks or months to less than a day. Celgene is a global biopharmaceutical company that creates drugs that fight cancer and other diseases and disorders. Celgene runs its high-performance computing research clusters, as well as its research collaboration environment, on AWS.
  • Under Armour – Under Armour can scale its Connected Fitness apps to meet the demands of more than 180 million global users, innovate and deliver new products and features more quickly, and expand internationally by taking advantage of the reliability and high availability of AWS. The company is a global leader in performance footwear, apparel, and equipment. Under Armour runs its growing Connected Fitness app platform on the AWS Cloud.

New YouTube Videos

Upcoming Events

Help Wanted

Stay tuned for next week! In the meantime, follow me on Twitter and subscribe to the RSS feed.

Spring SOC Report Now Available—Amazon WorkMail Now in Scope

Post Syndicated from Chad Woolf original https://blogs.aws.amazon.com/security/post/Tx2PTZ3RLM0Q54T/Spring-SOC-Report-Now-Available-Amazon-WorkMail-Now-in-Scope

Today, I’m pleased to announce that we have completed our semiannual AWS Service Organization Control (SOC) assessments and the reports are available to NDA customers now.

The AWS SOC program is an intense, period-in-time audit performed every six months. We have been releasing AWS services SOC Reports (or their SAS 70 predecessors) regularly since 2009, and we have gradually added more controls and services in scope over the years. These third-party assessments from Ernst & Young are comprehensive attestations to our alignment with the American Institute of Certified Public Accountants (AICPA) Security and Availability Trust Service Principles. The SOC program continues to be a key component of our efforts to provide transparency to our global customer base around information security, confidentiality, and privacy.

The AWS SOC Reports cover the US East (N. Virginia), US West (Oregon), US West (N. California), AWS GovCloud (US), EU (Ireland), EU (Frankfurt), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), and South America (Sao Paulo) regions, as well as AWS Edge locations. Visit the AWS website for more information about the AWS Global Infrastructure.

For this latest period’s SOC 2 and SOC 3 Reports, AWS was assessed against the latest edition of the TSP Section 100, which the AICPA released in March 2016. Amazon WorkMail is now also in scope for our SOC Reports. This increases the number of services covered in our SOC Reports to 26, and with 34 AWS Edge Locations also in scope, AWS customers can satisfy a variety of audit use cases.

Our updated AWS SOC 1 and SOC 2 Security and Availability Reports cover the report period of October 1, 2015, through March 31, 2016, and will continue to be reaffirmed in a six-month cadence. To request the latest SOC 1 or SOC 2 Report, contact AWS Sales and Business Development. Alternatively, depending on your compliance needs, the SOC 3 Report is publically available for download via our AWS Cloud Compliance website, or directly as a PDF.

If you have additional questions about SOC Reports, see our SOC Compliance FAQ on the topic. To see all publicly available certifications, see Compliance Resources. To keep up with the latest AWS Compliance news, see AWS Compliance – Latest News.

– Chad Woolf, Director of AWS Risk and Compliance

AWS ISO 27001 Certification Increases Total In-Scope Services to 33

Post Syndicated from Chad Woolf original https://blogs.aws.amazon.com/security/post/Tx3M70FHVIHHA5O/AWS-ISO-27001-Certification-Increases-Total-In-Scope-Services-to-33

AWS has just completed our annual audit of ISO 27001, a certification we achieved back in 2010. 10 new services are now in scope under ISO 27001:  

Amazon CloudFront

Amazon EC2 Container Service (ECS)

Amazon Elastic File System (EFS)

Amazon Simple Email Service (SES)

Amazon WorkDocs

Amazon WorkMail

Amazon WorkSpaces

AWS Directory Service

AWS Key Management Service (KMS)

AWS WAF – Web Application Firewall

For those just learning about the ISO 27001:2013 certification, the International Organization of Standardization (ISO) created the widely adopted global security standard that set out requirements and best practices for a systematic approach to managing company and customer information. This approach is based on periodic risk assessments appropriate to ever-changing threat scenarios.

Guidance on the 27001 certification from ISO includes:

“Using this family of standards will help your organization manage the security of assets such as financial information, intellectual property, employee details or information entrusted to you by third parties. ISO/IEC 27001 is the best-known standard in the family providing requirements for an information security management system (ISMS).”

This brings the total up to 33 services now available for use under the standard of ISO 27001. The complete list can be found in our AWS ISO 27001 FAQs.

Additionally, 10 regions are now in scope, including the newly added EU (Frankfurt). The complete list is as follows: US East (N. Virginia), US West (Oregon), US West (N. California), AWS GovCloud (US), South America (Sao Paulo), EU (Ireland), EU (Frankfurt), Asia Pacific (Singapore), Asia Pacific (Sydney), and Asia Pacific (Tokyo).

Download the AWS ISO 27001 certification.

In order to achieve the certification, AWS has shown it has a systematic and ongoing approach to managing information security risks that affect the confidentiality, integrity, and availability of company and customer information. This certification reinforces Amazon’s commitment to providing transparency into our security controls and practices.

AWS was certified by an independent third-party audit, EY CertifyPoint, an ISO certifying agent. Importantly, there is no increase in service costs for any region as a result of this certification. You can download a copy of the AWS certification and use it to jump-start your own certification efforts (you are not automatically certified by association; however, using an ISO 27001 certified provider like AWS can make your certification process easier). You may also want to read the AWS ISO 27001 FAQs.

If you’d like to learn more about compliance in the cloud, please visit our AWS Cloud Compliance page.

– Chad

AWS Certification Update – ISO 9001 Has 10 New Services in Scope

Post Syndicated from Chad Woolf original https://blogs.aws.amazon.com/security/post/Tx35NEO4Y3P7C6C/AWS-Certification-Update-ISO-9001-Has-10-New-Services-in-Scope

 

Today we’re happy to announce we’ve added 10 new services to our ISO 9001 certification:

Amazon CloudFront

Amazon EC2 Container Service (ECS)

Amazon Elastic File System (EFS)

Amazon Simple Email Service (SES)

Amazon WorkDocs

Amazon WorkMail

Amazon WorkSpaces

AWS Directory Service

AWS Key Management Service (KMS)

AWS WAF – Web Application Firewall

This increases the total number of AWS Services available for use under the certification to 33. The complete list can be found in our AWS ISO 9001 FAQs.

EU (Frankfurt) is now also available, bringing the regions available up to 10: US East (N. Virginia), US West (Oregon), US West (N. California), AWS GovCloud (US), South America (Sao Paulo), EU (Ireland), EU (Frankfurt), Asia Pacific (Singapore), Asia Pacific (Sydney), and Asia Pacific (Tokyo).

ISO 9001:2008 is a globally recognized standard for managing the quality of products and services. The 9001 standard outlines a quality management system based on eight principles defined by the ISO Technical Committee for quality management and quality assurance:

Customer focus.

Leadership.

Involvement of people.

Process approach.

Systematic approach to management.

Continual improvement.

Factual approach to decision making.

Mutually beneficial supplier relationships.

The key to the ongoing certification under this standard is establishing, maintaining, and improving the organizational structure, responsibilities, procedures, processes, and resources for ensuring that the characteristics of AWS products and services consistently satisfy ISO 9001 quality requirements.

AWS was certified by EY CertifyPoint, an ISO certifying agent. There is no increase in service costs for any region as a result of this certification. You can download a copy of the AWS certification and use it to jump-start your own certification efforts (you are not automatically certified by association; however, using an ISO 9001 certified provider such as AWS can make your certification process easier). You may also want to read the AWS ISO 9001 FAQs.

If you’d like to learn more about compliance in the cloud, see our AWS Cloud Compliance page.

– Chad

Receiving Email with Amazon SES

Post Syndicated from Peter Winckles original https://aws.amazon.com/blogs/ses/receiving-email-with-amazon-ses/

The Amazon SES team is pleased to announce that you can now use SES to receive email!

For the past four years, SES has strived to make your life easier by maintaining a fleet of SMTP servers ready to send mail when you want it. There’s no need to worry about scaling, ensuring message delivery, or navigating relationships with countless email service providers.

However, you’d still need to manage a fleet of SMTP servers if you wanted to receive mail. As with sending mail, receiving mail comes with its own set of headaches: scaling for traffic spikes, blocking malicious senders, filtering out spam and viruses, and ultimately routing mail to your application, to name a few.

As of today, the SES team would like to invite you to say goodbye to these hassles, and rely on SES to simply receive your mail just as you rely on us to simply send your mail.

Why should I use SES to receive mail?

SES is ideally suited for servicing mail that is programmatically actionable. The following are a handful of common use cases that you can now leverage SES to solve:

  • Automatically create support tickets from customer email.
  • Implement an email auto-responder.
  • Process email list unsubscribe requests.
  • Process email bounces and complaints.
  • Create an email archival solution.
  • Update correspondence in tickets, forums, etc. by email.
  • Receive files from customers via email.

You can also use SES to manage your organization’s entire mail stream, directing mail destined to personal inboxes to Amazon WorkMail and processing customer service mail, etc. programmatically with SES.

How does it work?

Think of SES as an email gateway to the AWS ecosystem. After onboarding your domain onto SES, we will receive mail on your behalf, and allow you to consume it through a variety of different AWS services. For example, you can configure SES to deliver all of your mail to an Amazon S3 bucket, and process it directly using AWS Lambda.

SES empowers you to make decisions about how your mail is processed through the concept of a rule set. Every account that receives mail using SES has a single active rule set that you customize to dictate to SES what you’d like done with your mail across all of your SES-managed domains.

A rule set is simply an ordered list of rules, and a rule is a combination of a matching condition and an ordered list of actions. A condition is something like “All mail to [email protected]” or “All mail to example.com and all subdomains.” Actions are things like “Encrypt my mail using my AWS KMS key, write it to my S3 bucket, and notify me of the delivery via Amazon SNS” or “Asynchronously execute my Lambda function that updates my mailing list based on unsubscribe emails” or “Send me a SNS notification containing the email.” A more thorough discussion of rule sets, rules, and actions can be found in our developer guide.

Your rule set is sequentially evaluated for every message SES receives, and only the actions that apply to the message are executed. This enables you to write rules that route mail differently based on individual message characteristics. You can have a rule that drops mail that SES flags as spam across all of your domains, another that writes mail to a.example.com to one S3 bucket, another that writes mail to b.example.com to a different bucket and then executes a Lambda function but only when the email contains a specific header value, and so on.

Amazon SES rule set

The system was designed to be both highly customizable and convenient to use. Our goal is to minimize the amount of custom email routing or parsing logic that your application needs to do, and, if you capitalize on our Lambda integration, you may not even need an application at all!

How do I get started?

The best place to start is the SES developer guide. It provides detailed instructions on how to onboard a domain onto SES to receive mail, as well as walks you through the process of setting up rules to govern your mail flows. Then, head over to the SES console to set up your domains to begin receiving mail!

Finally, if you’re heading to AWS re:Invent this year, be sure to check out our presentation showcasing our new features!

Receiving Email with Amazon SES

Post Syndicated from Peter Winckles original http://sesblog.amazon.com/post/Tx3HQEJUJNVABG8/Receiving-Email-with-Amazon-SES

The Amazon SES team is pleased to announce that you can now use SES to receive email!

For the past four years, SES has strived to make your life easier by maintaining a fleet of SMTP servers ready to send mail when you want it. There’s no need to worry about scaling, ensuring message delivery, or navigating relationships with countless email service providers.

However, you’d still need to manage a fleet of SMTP servers if you wanted to receive mail. As with sending mail, receiving mail comes with its own set of headaches: scaling for traffic spikes, blocking malicious senders, filtering out spam and viruses, and ultimately routing mail to your application, to name a few.

As of today, the SES team would like to invite you to say goodbye to these hassles, and rely on SES to simply receive your mail just as you rely on us to simply send your mail.

Why should I use SES to receive mail?

SES is ideally suited for servicing mail that is programmatically actionable. The following are a handful of common use cases that you can now leverage SES to solve:

Automatically create support tickets from customer email.

Implement an email auto-responder.

Process email list unsubscribe requests.

Process email bounces and complaints.

Create an email archival solution.

Update correspondence in tickets, forums, etc. by email.

Receive files from customers via email.

You can also use SES to manage your organization’s entire mail stream, directing mail destined to personal inboxes to Amazon WorkMail and processing customer service mail, etc. programmatically with SES.

How does it work?

Think of SES as an email gateway to the AWS ecosystem. After onboarding your domain onto SES, we will receive mail on your behalf, and allow you to consume it through a variety of different AWS services. For example, you can configure SES to deliver all of your mail to an Amazon S3 bucket, and process it directly using AWS Lambda.

SES empowers you to make decisions about how your mail is processed through the concept of a rule set. Every account that receives mail using SES has a single active rule set that you customize to dictate to SES what you’d like done with your mail across all of your SES-managed domains.

A rule set is simply an ordered list of rules, and a rule is a combination of a matching condition and an ordered list of actions. A condition is something like "All mail to [email protected]" or "All mail to example.com and all subdomains." Actions are things like "Encrypt my mail using my AWS KMS key, write it to my S3 bucket, and notify me of the delivery via Amazon SNS" or "Asynchronously execute my Lambda function that updates my mailing list based on unsubscribe emails" or "Send me a SNS notification containing the email." A more thorough discussion of rule sets, rules, and actions can be found in our developer guide.

Your rule set is sequentially evaluated for every message SES receives, and only the actions that apply to the message are executed. This enables you to write rules that route mail differently based on individual message characteristics. You can have a rule that drops mail that SES flags as spam across all of your domains, another that writes mail to a.example.com to one S3 bucket, another that writes mail to b.example.com to a different bucket and then executes a Lambda function but only when the email contains a specific header value, and so on.

The system was designed to be both highly customizable and convenient to use. Our goal is to minimize the amount of custom email routing or parsing logic that your application needs to do, and, if you capitalize on our Lambda integration, you may not even need an application at all!

How do I get started?

The best place to start is the SES developer guide. It provides detailed instructions on how to onboard a domain onto SES to receive mail, as well as walks you through the process of setting up rules to govern your mail flows. Then, head over to the SES console to set up your domains to begin receiving mail!

Finally, if you’re heading to AWS re:Invent this year, be sure to check out our presentation showcasing our new features!

Receiving Email with Amazon SES

Post Syndicated from Peter Winckles original http://sesblog.amazon.com/post/Tx3HQEJUJNVABG8/Receiving-Email-with-Amazon-SES

The Amazon SES team is pleased to announce that you can now use SES to receive email!

For the past four years, SES has strived to make your life easier by maintaining a fleet of SMTP servers ready to send mail when you want it. There’s no need to worry about scaling, ensuring message delivery, or navigating relationships with countless email service providers.

However, you’d still need to manage a fleet of SMTP servers if you wanted to receive mail. As with sending mail, receiving mail comes with its own set of headaches: scaling for traffic spikes, blocking malicious senders, filtering out spam and viruses, and ultimately routing mail to your application, to name a few.

As of today, the SES team would like to invite you to say goodbye to these hassles, and rely on SES to simply receive your mail just as you rely on us to simply send your mail.

Why should I use SES to receive mail?

SES is ideally suited for servicing mail that is programmatically actionable. The following are a handful of common use cases that you can now leverage SES to solve:

Automatically create support tickets from customer email.

Implement an email auto-responder.

Process email list unsubscribe requests.

Process email bounces and complaints.

Create an email archival solution.

Update correspondence in tickets, forums, etc. by email.

Receive files from customers via email.

You can also use SES to manage your organization’s entire mail stream, directing mail destined to personal inboxes to Amazon WorkMail and processing customer service mail, etc. programmatically with SES.

How does it work?

Think of SES as an email gateway to the AWS ecosystem. After onboarding your domain onto SES, we will receive mail on your behalf, and allow you to consume it through a variety of different AWS services. For example, you can configure SES to deliver all of your mail to an Amazon S3 bucket, and process it directly using AWS Lambda.

SES empowers you to make decisions about how your mail is processed through the concept of a rule set. Every account that receives mail using SES has a single active rule set that you customize to dictate to SES what you’d like done with your mail across all of your SES-managed domains.

A rule set is simply an ordered list of rules, and a rule is a combination of a matching condition and an ordered list of actions. A condition is something like "All mail to [email protected]" or "All mail to example.com and all subdomains." Actions are things like "Encrypt my mail using my AWS KMS key, write it to my S3 bucket, and notify me of the delivery via Amazon SNS" or "Asynchronously execute my Lambda function that updates my mailing list based on unsubscribe emails" or "Send me a SNS notification containing the email." A more thorough discussion of rule sets, rules, and actions can be found in our developer guide.

Your rule set is sequentially evaluated for every message SES receives, and only the actions that apply to the message are executed. This enables you to write rules that route mail differently based on individual message characteristics. You can have a rule that drops mail that SES flags as spam across all of your domains, another that writes mail to a.example.com to one S3 bucket, another that writes mail to b.example.com to a different bucket and then executes a Lambda function but only when the email contains a specific header value, and so on.

The system was designed to be both highly customizable and convenient to use. Our goal is to minimize the amount of custom email routing or parsing logic that your application needs to do, and, if you capitalize on our Lambda integration, you may not even need an application at all!

How do I get started?

The best place to start is the SES developer guide. It provides detailed instructions on how to onboard a domain onto SES to receive mail, as well as walks you through the process of setting up rules to govern your mail flows. Then, head over to the SES console to set up your domains to begin receiving mail!

Finally, if you’re heading to AWS re:Invent this year, be sure to check out our presentation showcasing our new features!

Announcing Sending Authorization!

Post Syndicated from Brian Huang original http://sesblog.amazon.com/post/Tx1471CTS1P1RUW/Announcing-Sending-Authorization

The Amazon SES team is excited to announce the release of sending authorization! This feature allows users to grant permission to use their email addresses or domains to other accounts or IAM users.

Note that for simplicity, we’ll be referring to email addresses and domains collectively as “identities” and the accounts and IAM users receiving permissions as “delegate senders.”

Why should I use sending authorization?

The primary incentive to use sending authorization is to enable cross-account identity usage with fine-grained permission control. Let’s look at two example use cases.

Say you’ve just been hired to create and manage an email marketing campaign for an online retailer. Until now, in order to send the retailer’s marketing emails under their domain name, you would have had to convince them to allow you to verify their domain under your own AWS account—this would let you send emails using any address under their domain, at any time, and for any purpose, which the retailer might not be comfortable with. You’d also have to work out who would get the bounce/complaint/delivery notifications, which might be additionally confusing because the notifications from your marketing emails would be sent to the same place as the notifications from the transactional emails the retailer is handling.

With sending authorization, however, you can use the retailer’s identity and receive delivery, bounce and complaint notifications while letting them retain sole ownership of it. Identity owners will still be able to monitor usage with delivery, bounce, and complaint notifications and can adjust permissions at any time, and use AWS condition keys to finely control the scope of those permissions.

Imagine instead that you own or administrate for a company that has several disparate teams that all wish to use SES to send emails using a common email address. Until now, you would have had to create and maintain IAM users for each of these teams under the same account (in which case they still would have access to each other’s identities) or verify the same identity under multiple different accounts.

With sending authorization, you can verify the common identity under the single account (perhaps yours) and simply grant the other teams permission to use it. If you still prefer the IAM policy route, you can take advantage of the new condition keys released with sending authorization to tighten up the IAM policies.

Sending authorization is designed to be powerful and flexible. In fact, Amazon WorkMail uses sending authorization to provide an enterprise-level email and calendaring service built on SES.

How does sending authorization work?

Identity owners grant permissions by creating authorization policies. Let’s look at an example. The policy below gives account 9999-9999-9999 permission to use the ses-example.com domain owned by 8888-8888-8888 in SendEmail and SendRawEmail requests as long as the “From” address is [email protected] (with any address tags).

{
"Id": "SampleAuthorizationPolicy",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AuthorizeMarketer",
"Effect": "Allow",
"Resource": "arn:aws:ses:us-east-1:888888888888:identity/ses-example.com",
"Principal": {"AWS": ["999999999999"]},
"Action": ["SES:SendEmail", "SES:SendRawEmail"],
"Condition": {
"StringLike": {
"ses:FromAddress": "marketing+.*@ses-example.com"
}
}
}
]
}

You could write this policy yourself, or you could use the Policy Generator in the SES console, which is even easier. Your Policy Generator page would look like:

Identity owners can add or create a policy for an identity using the PutIdentityPolicy API or the SES console, and can have up to 20 different policies for each identity. You can read more about how to construct and use policies in our developer guide.

How do I make a call with someone else’s identity that I have permission to use?

You’ll specify to SES that you’re using someone else’s identity by presenting an ARN when you make a request. The ARN below refers to an example domain identity (ses-example.com) owned by account 9999-9999-9999 in the US West (Oregon) AWS region.

arn:aws:ses:us-west-2:999999999999:identity/ses-example.com

Depending on how you make your call, you may need to provide up to three different ARNs: a “source” identity ARN, a “from” identity ARN, and a “return-path” identity ARN. The SendEmail and SendRawEmail APIs have new optional parameters for this purpose, but users of our SMTP endpoint or our SendRawEmail API have the option to instead provide the ARNs as X-headers (X-SES-Source-ARN, X-SES-From-ARN, and X-SES-Return-Path-ARN). See our SendEmail and SendRawEmail documentation for more information about these identities). These headers will be removed by SES before your email is sent.

What happens to notifications when email is sent by a delegate?

Both the identity owner and the delegate sender can set their own bounce, complaint, and delivery notification preferences. SES respects both sets of preferences independently. As a delegate sender, you can configure your notification settings almost as you would if you were the identity owner. The two key differences are that you use ARNs in place of identities, and cannot configure feedback forwarding (a.k.a. receiving bounces and complaints via email) in the console or the API. But, this doesn’t mean that delegate senders cannot use feedback forwarding. If you are a delegate sender and you do want bounces and complaints to be forwarded to an email address you own, just set the “return-path” address of your emails to an identity that you own. You can read more about it in our developer guide.

Billing, sending limits, and reputation

Cross-account emails count against the delegate’s sending limits, so the delegate is responsible for applying for any sending limit increases they might need. Similarly, delegated emails get charged to the delegate’s account, and any bounces and complaints count against the delegate’s reputation.

Sending authorization and IAM policies

It’s important to distinguish between SES sending authorization policies and IAM policies. Although the policies look similar at first glance, sending authorization policies dictate who is allowed to use an SES identity, and IAM policies (set using AWS Identity Access and Management) control what IAM users are allowed to do. The two are independent. Therefore, it’s entirely possible for an IAM user to be unable to use an identity despite having authorization from the owner because the user’s IAM policies do not give permission to use SES (and vice versa). Keep in mind, however, that by default, IAM users with SES access are allowed to use any identities owned by their parent account unless a sending authorization policy explicitly dictates otherwise.

On a related note, with the release of sending authorization, we’re externalizing several new condition keys that you can use in your sending authorization and/or IAM policies:

ses:Recipients

ses:FromAddress

ses:FromDisplayName

ses:FeedbackAddress

These can be used to control when policies apply. For example, you might use the “ses:FromAddress” condition key to write an IAM policy that only permits an IAM user to call SES using a certain “From” address. For more information about how to use our new condition keys, see our developer guide.

We hope you find this feature useful! If you have any questions or comments, let us know in the SES Forum or here in the comment section of the blog.

Announcing Sending Authorization!

Post Syndicated from Brian Huang original https://aws.amazon.com/blogs/ses/announcing-sending-authorization/

The Amazon SES team is excited to announce the release of sending authorization! This feature allows users to grant permission to use their email addresses or domains to other accounts or IAM users.

Note that for simplicity, we’ll be referring to email addresses and domains collectively as “identities” and the accounts and IAM users receiving permissions as “delegate senders.”

Why should I use sending authorization?

The primary incentive to use sending authorization is to enable cross-account identity usage with fine-grained permission control. Let’s look at two example use cases.

Say you’ve just been hired to create and manage an email marketing campaign for an online retailer. Until now, in order to send the retailer’s marketing emails under their domain name, you would have had to convince them to allow you to verify their domain under your own AWS account—this would let you send emails using any address under their domain, at any time, and for any purpose, which the retailer might not be comfortable with. You’d also have to work out who would get the bounce/complaint/delivery notifications, which might be additionally confusing because the notifications from your marketing emails would be sent to the same place as the notifications from the transactional emails the retailer is handling.

With sending authorization, however, you can use the retailer’s identity and receive delivery, bounce and complaint notifications while letting them retain sole ownership of it. Identity owners will still be able to monitor usage with delivery, bounce, and complaint notifications and can adjust permissions at any time, and use AWS condition keys to finely control the scope of those permissions.

Imagine instead that you own or administrate for a company that has several disparate teams that all wish to use SES to send emails using a common email address. Until now, you would have had to create and maintain IAM users for each of these teams under the same account (in which case they still would have access to each other’s identities) or verify the same identity under multiple different accounts.

With sending authorization, you can verify the common identity under the single account (perhaps yours) and simply grant the other teams permission to use it. If you still prefer the IAM policy route, you can take advantage of the new condition keys released with sending authorization to tighten up the IAM policies.

Sending authorization is designed to be powerful and flexible. In fact, Amazon WorkMail uses sending authorization to provide an enterprise-level email and calendaring service built on SES.

How does sending authorization work?

Identity owners grant permissions by creating authorization policies. Let’s look at an example. The policy below gives account 9999-9999-9999 permission to use the ses-example.com domain owned by 8888-8888-8888 in SendEmail and SendRawEmail requests as long as the “From” address is [email protected] (with any address tags).

{
  "Id": "SampleAuthorizationPolicy",	
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AuthorizeMarketer",
      "Effect": "Allow",
      "Resource": "arn:aws:ses:us-east-1:888888888888:identity/ses-example.com",
      "Principal": {"AWS": ["999999999999"]},
      "Action": ["SES:SendEmail", "SES:SendRawEmail"],
      "Condition": {
        "StringLike": {
          "ses:FromAddress": "marketing+.*@ses-example.com"
        }
      }
    }
  ]
}

You could write this policy yourself, or you could use the Policy Generator in the SES console, which is even easier. Your Policy Generator page would look like:

Policy generator

Identity owners can add or create a policy for an identity using the PutIdentityPolicy API or the SES console, and can have up to 20 different policies for each identity. You can read more about how to construct and use policies in our developer guide.

How do I make a call with someone else’s identity that I have permission to use?

You’ll specify to SES that you’re using someone else’s identity by presenting an ARN when you make a request. The ARN below refers to an example domain identity (ses-example.com) owned by account 9999-9999-9999 in the US West (Oregon) AWS region.

	arn:aws:ses:us-west-2:999999999999:identity/ses-example.com

Depending on how you make your call, you may need to provide up to three different ARNs: a “source” identity ARN, a “from” identity ARN, and a “return-path” identity ARN. The SendEmail and SendRawEmail APIs have new optional parameters for this purpose, but users of our SMTP endpoint or our SendRawEmail API have the option to instead provide the ARNs as X-headers (X-SES-Source-ARN, X-SES-From-ARN, and X-SES-Return-Path-ARN). See our SendEmail and SendRawEmail documentation for more information about these identities). These headers will be removed by SES before your email is sent.

What happens to notifications when email is sent by a delegate?

Both the identity owner and the delegate sender can set their own bounce, complaint, and delivery notification preferences. SES respects both sets of preferences independently. As a delegate sender, you can configure your notification settings almost as you would if you were the identity owner. The two key differences are that you use ARNs in place of identities, and cannot configure feedback forwarding (a.k.a. receiving bounces and complaints via email) in the console or the API. But, this doesn’t mean that delegate senders cannot use feedback forwarding. If you are a delegate sender and you do want bounces and complaints to be forwarded to an email address you own, just set the “return-path” address of your emails to an identity that you own. You can read more about it in our developer guide.

Billing, sending limits, and reputation

Cross-account emails count against the delegate’s sending limits, so the delegate is responsible for applying for any sending limit increases they might need. Similarly, delegated emails get charged to the delegate’s account, and any bounces and complaints count against the delegate’s reputation.

Sending authorization and IAM policies

It’s important to distinguish between SES sending authorization policies and IAM policies. Although the policies look similar at first glance, sending authorization policies dictate who is allowed to use an SES identity, and IAM policies (set using AWS Identity Access and Management) control what IAM users are allowed to do. The two are independent. Therefore, it’s entirely possible for an IAM user to be unable to use an identity despite having authorization from the owner because the user’s IAM policies do not give permission to use SES (and vice versa). Keep in mind, however, that by default, IAM users with SES access are allowed to use any identities owned by their parent account unless a sending authorization policy explicitly dictates otherwise.

On a related note, with the release of sending authorization, we’re externalizing several new condition keys that you can use in your sending authorization and/or IAM policies:

  • ses:Recipients
  • ses:FromAddress
  • ses:FromDisplayName
  • ses:FeedbackAddress

These can be used to control when policies apply. For example, you might use the “ses:FromAddress” condition key to write an IAM policy that only permits an IAM user to call SES using a certain “From” address. For more information about how to use our new condition keys, see our developer guide.

We hope you find this feature useful! If you have any questions or comments, let us know in the SES Forum or here in the comment section of the blog.

Announcing Sending Authorization!

Post Syndicated from Brian Huang original http://sesblog.amazon.com/post/Tx1471CTS1P1RUW/Announcing-Sending-Authorization

The Amazon SES team is excited to announce the release of sending authorization! This feature allows users to grant permission to use their email addresses or domains to other accounts or IAM users.

Note that for simplicity, we’ll be referring to email addresses and domains collectively as “identities” and the accounts and IAM users receiving permissions as “delegate senders.”

Why should I use sending authorization?

The primary incentive to use sending authorization is to enable cross-account identity usage with fine-grained permission control. Let’s look at two example use cases.

Say you’ve just been hired to create and manage an email marketing campaign for an online retailer. Until now, in order to send the retailer’s marketing emails under their domain name, you would have had to convince them to allow you to verify their domain under your own AWS account—this would let you send emails using any address under their domain, at any time, and for any purpose, which the retailer might not be comfortable with. You’d also have to work out who would get the bounce/complaint/delivery notifications, which might be additionally confusing because the notifications from your marketing emails would be sent to the same place as the notifications from the transactional emails the retailer is handling.

With sending authorization, however, you can use the retailer’s identity and receive delivery, bounce and complaint notifications while letting them retain sole ownership of it. Identity owners will still be able to monitor usage with delivery, bounce, and complaint notifications and can adjust permissions at any time, and use AWS condition keys to finely control the scope of those permissions.

Imagine instead that you own or administrate for a company that has several disparate teams that all wish to use SES to send emails using a common email address. Until now, you would have had to create and maintain IAM users for each of these teams under the same account (in which case they still would have access to each other’s identities) or verify the same identity under multiple different accounts.

With sending authorization, you can verify the common identity under the single account (perhaps yours) and simply grant the other teams permission to use it. If you still prefer the IAM policy route, you can take advantage of the new condition keys released with sending authorization to tighten up the IAM policies.

Sending authorization is designed to be powerful and flexible. In fact, Amazon WorkMail uses sending authorization to provide an enterprise-level email and calendaring service built on SES.

How does sending authorization work?

Identity owners grant permissions by creating authorization policies. Let’s look at an example. The policy below gives account 9999-9999-9999 permission to use the ses-example.com domain owned by 8888-8888-8888 in SendEmail and SendRawEmail requests as long as the “From” address is [email protected] (with any address tags).

{
"Id": "SampleAuthorizationPolicy",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AuthorizeMarketer",
"Effect": "Allow",
"Resource": "arn:aws:ses:us-east-1:888888888888:identity/ses-example.com",
"Principal": {"AWS": ["999999999999"]},
"Action": ["SES:SendEmail", "SES:SendRawEmail"],
"Condition": {
"StringLike": {
"ses:FromAddress": "marketing+.*@ses-example.com"
}
}
}
]
}

You could write this policy yourself, or you could use the Policy Generator in the SES console, which is even easier. Your Policy Generator page would look like:

Identity owners can add or create a policy for an identity using the PutIdentityPolicy API or the SES console, and can have up to 20 different policies for each identity. You can read more about how to construct and use policies in our developer guide.

How do I make a call with someone else’s identity that I have permission to use?

You’ll specify to SES that you’re using someone else’s identity by presenting an ARN when you make a request. The ARN below refers to an example domain identity (ses-example.com) owned by account 9999-9999-9999 in the US West (Oregon) AWS region.

arn:aws:ses:us-west-2:999999999999:identity/ses-example.com

Depending on how you make your call, you may need to provide up to three different ARNs: a “source” identity ARN, a “from” identity ARN, and a “return-path” identity ARN. The SendEmail and SendRawEmail APIs have new optional parameters for this purpose, but users of our SMTP endpoint or our SendRawEmail API have the option to instead provide the ARNs as X-headers (X-SES-Source-ARN, X-SES-From-ARN, and X-SES-Return-Path-ARN). See our SendEmail and SendRawEmail documentation for more information about these identities). These headers will be removed by SES before your email is sent.

What happens to notifications when email is sent by a delegate?

Both the identity owner and the delegate sender can set their own bounce, complaint, and delivery notification preferences. SES respects both sets of preferences independently. As a delegate sender, you can configure your notification settings almost as you would if you were the identity owner. The two key differences are that you use ARNs in place of identities, and cannot configure feedback forwarding (a.k.a. receiving bounces and complaints via email) in the console or the API. But, this doesn’t mean that delegate senders cannot use feedback forwarding. If you are a delegate sender and you do want bounces and complaints to be forwarded to an email address you own, just set the “return-path” address of your emails to an identity that you own. You can read more about it in our developer guide.

Billing, sending limits, and reputation

Cross-account emails count against the delegate’s sending limits, so the delegate is responsible for applying for any sending limit increases they might need. Similarly, delegated emails get charged to the delegate’s account, and any bounces and complaints count against the delegate’s reputation.

Sending authorization and IAM policies

It’s important to distinguish between SES sending authorization policies and IAM policies. Although the policies look similar at first glance, sending authorization policies dictate who is allowed to use an SES identity, and IAM policies (set using AWS Identity Access and Management) control what IAM users are allowed to do. The two are independent. Therefore, it’s entirely possible for an IAM user to be unable to use an identity despite having authorization from the owner because the user’s IAM policies do not give permission to use SES (and vice versa). Keep in mind, however, that by default, IAM users with SES access are allowed to use any identities owned by their parent account unless a sending authorization policy explicitly dictates otherwise.

On a related note, with the release of sending authorization, we’re externalizing several new condition keys that you can use in your sending authorization and/or IAM policies:

ses:Recipients

ses:FromAddress

ses:FromDisplayName

ses:FeedbackAddress

These can be used to control when policies apply. For example, you might use the “ses:FromAddress” condition key to write an IAM policy that only permits an IAM user to call SES using a certain “From” address. For more information about how to use our new condition keys, see our developer guide.

We hope you find this feature useful! If you have any questions or comments, let us know in the SES Forum or here in the comment section of the blog.