「ほぼ週刊AWSマイスターシリーズ第11回〜Simple Email Service〜」メモ

AWSのウェビナーを聞いて、内容と質疑応答のメモを取ったので、貼っておきます。

今回のテーマは、Simple Email Service（SES）で、講師はAmazonソリューションアーキテクトの荒木さんでした。

SESは、名前のとおり、メール送信のサービスですね。

マイスターシリーズは、当初は全10回といわれていましたが、ネタが続く限り開催するとのことで、今回で11回目でした。一応、次で最終回だそうです。

次回は、12月15日だそうです。

• 申込みページ https://www2.gotomeeting.com/register/814096954

本編メモ

SESを簡潔にまとめると？

• メール送信のためのMTA運用の手間から、ユーザを解放
• 配送機能のみに特化して提供する
• APIで利用できる

Amazon.com（ECサイトの方）で実際に利用されているそうです。

メールシステム超基本編

まず、一般的なメールの基礎について解説されました。

（とても分かりやすかったです。ちなみに、講師の荒木さんが以前別の場所で発表されたメールシステムの資料も、非常に分かりやすいです。ウェビナー開催中、「このメール配信の仕組みの説明を、新入エンジニアに聞かせたい」というコメントが、#jawsugタグで流れていました。そういう用途なら、こちらも参考になると思います。→「メールシステムのおはなし #Mailerstudy」http://www.slideshare.net/ar_maniacs/mailerstudy）

まず、メールシステムの関係者について。

• NTP
  • 配送時刻をサーバ間で同期するため
• DNS
• MTA
  • 受信、送信（SMTP、MDAへ）、キューイング、エラー通知（MAILER-DAEMON）
  • （例）Sendmail、postfix、Exchange
• MUA
  • 各ユーザはMUAを介してメールシステムに触れる。読み、書き、保存、検索

SESは、この中のMTAの部分を行うサービスです。

次に、「メールメッセージ」について。メールメッセージを構成するものとは何か。

• Subject
• Body
• Source
• Destination(To,CC,BCC)
• Reply To
• Return Path

SESの主役のプロトコルは、SMTPです。ちなみに、SMTPのRFCは、821 -> 2821 -> 5321と変遷してきたらしい。

メールシステムのためのDNS設定の注意点は、

• MXレコードを使用する。
• 数値の小さい方が優先される。
• 現在ではCNAMEは指定しない。

あたり。

メールシステム現実編

メールをスパム扱いされないために、サービス利用者が気をつけることについて、解説がありました。

• 第三者中継チェック
• スパムデータベースの定期的確認
  • http://www.dnsbl.info/dnsbl-database-check.php
  • http://www.senderbase.org/help/blocked
• DNSの設定
  • 逆引きを忘れずに（特にIPv4）
  • DNSのSPFレコード設定（RFC4408参照）
• 送信側の作法を守る
  • DKIM導入リコメンド（http://www.dkim.jp/dkim-jp/recommend/）を参照

SESで提供されるAPI

• メール送信API
  • SendEmailAPI（定型フォーマット）
  • SendRawEmailAPI（自由フォーマット）
  • 既存MTAからのリレーも可能
    • postfixやsendmailで使えるAPIコールスクリプトもある

• FeedbackAPI
  • GetSendStatistics API

これらのAPIをラップしたSDKが、Java、.NET、Perlなどで提供されています。

SESの利用手順

1. サービス登録（サインアップ）
2. 送信元メールアドレスの登録
3. サンドボックス環境でのテスト
4. production環境での利用

他のサービスよりも、利用までにちょっと段階を踏む必要がありますね。最初は1日あたり1000通まで送ることができます。その後、利用実績に応じて、配送制限が少しずつ緩和されていきます。

なお、最初から大量のメール送信に使いたい場合は、WebフォームからAWSに申請すると、いろいろと（スパム目的でないか確認するための）質問を受けた上で、緩和してもらえるようです。

質疑応答メモ

SESで送ったメールが、他のWebメールで迷惑メールとして扱われる可能性はありますか？ その場合、AWSは何か対応してくれますか？

他社サービスで迷惑メールとして扱われる可能性はあります。AWSは、ISPからAWSからのメールをどれくらい迷惑メール扱いにしたかについて、ときどきフィードバックを受けています。それが多い場合は、SESのメール送信時間帯や送信数に対して、制限をかけています。そのあたりの情報は、Management Consoleに表示されるので、SESで大量にメール送信するサービスを作っている人は、ぜひManagementConsoleをこまめに見てくださいね。

SESでメール送信上限引き上げの条件は？

最初は1日1000通まで送れるので、たとえば、前日に500〜700通のクリーンな（＝スパムでない）メールを送っていることをAWS側が確認できれば、翌日から2000通、3000通と段階的に上限を上げていきます。上げ方は、倍倍方式ではなく、割合です。

SESの送信上限を超えたメールは、遅延して送信されるのですか？ それとも破棄されてしまうのですか？

上限を超えた場合、そもそも、メール送信のAPIが正常終了しません。HTTPのステータスコードでエラーが返ります。SESのAPIは、実行したら必ず成功するというわけではないです。

SESはリージョンに依存しますか？

現在、SESはアメリカ東海岸でのみサービスです。ただし、日本のユーザは、東海岸のエンドポイントに対して、リクエストを問題なく投げることができます。メールは若干の遅延が許されるサービスなので（注※リアルタイム実行が要求されない、という意味だと思います）、us-eastを使っていただければと思います。

Google AppsとSESの二択だとどう使えばよいのでしょう？

Google Appsを個人で使うことあると思いますが、Googleが保証しているサービスではまだないはず。そのあたりを考えて使われてみては。また、もちろん、どちらかに絞るのではなく、両方使ってみてもよいのではないでしょうか。

メールヘッダの中で送信日時を指定できますか？

できるはずです。

SESの設定で、メールの内容を暗号化できますか？

そのような機能は提供していないので、必要があればお客様側でしてください。ただ、暗号化すると、SPAMかどうかを判定できなくなるので、誤ってSPAM判定してしまう場合があるかもしれません。もしそういうことがあった場合、連絡いただければ調査します。

メールの送信状況について。

GetSendStatistics APIで、フィードバックが見えます。Management Cosoleから見ることもできるので、そちらを参照するとラクでしょう。送信したメールに宛先到達不能なメールがあった場合も、Hard Bouncesとして把握できます。

自前でAPIを叩く場合、エラーコードをAPI側で受け取ってコントロールできますか。

MTAが配信エラーメールを作成するはずなので、使えるはずです。APIコールスクリプトを作り込んだり、MAILER-DAEMONの機能を活用したりすれば、使えると思います。

と、こんな感じでした。

あと、SESの稼働保証と、ポートが変更可能かどうかについて、Twitterの#jawsugタグで質問が上がっていましたね。そのうち回答があるかも？ →今探したらなかった。幻を見たんだろうか。