Amazon EC2 Eメール送信ベストプラクティス

#Amazon SES

#AWS

大瀧隆太

2013.09.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ども、大瀧です。
EC2からEメールを送るという案件、たくさんありますよね。そして結構な確率でトラブるんですよね(涙目)。そんな苦い経験をベストプラクティスとしてまとめてみました。一応技術的なところは網羅したつもりですが、メールセキュリティの専門ではないので、不備や間違いがあればご指摘ください。

では、メール送信トラブルの元凶である、スパムメールとその対策からご紹介していきます。

スパムメールとの闘いダイジェスト

Eメールの歴史は、スパムメールとの闘いの歴史と言えます。不特定多数に送信されるスパムメール(未承諾の広告メール)は、メール受信者に不快な思いをさせるとともに、メールサーバーのメール流量を爆発的に増加させ、長らくメールサーバー管理者を泣かせてきました。

このスパムメールをなんとか撃退しようと、現在では主に以下のような対策が行われています。

1. 送信メールサーバー側のネットワークによる制限

送信メールサーバー側では、ネットワークでのOutbound Port 25 Blockingがよく用いられます。「スパムメールをインターネットに流さないように水際で押さえる」手法です。

Outbound Port 25 Blocking: メールを送信・転送する際のSMTP 25/tcpポートの通信を遮断する設定です。家庭やオフィスのネットワークからインターネットに接続するISPで広く用いられています。
利用者は、SMTPとは異なるサブミッションポートでISPのメールサーバーに接続し、メールを送信することになります。

2. 中継・受信メールサーバー側による制限

以下の通りいろいろありますが、要は、中継や受信側のメールサーバーが「怪しい送信メールサーバーを特定する」か、「正規の送信メールサーバーであることを確認する」ための仕組みと言えます。

2-a. RBL(Real-time Blackhole List): 過去にスパムメールを送ったことがある送信メールサーバーを報告してブラックリスト化し、ブラックリストを配信する仕組みです。有志やセキュリティベンダーによるRBL配信サーバーが複数あります。受信メールサーバーはRBL配信サーバーからブラックリストをダウンロードし、ブラックリストに送信メールサーバーが載っていたら、そのメールを破棄します。
2-b. DNSレコードの整合性: 「正規の送信メールサーバーであれば、真っ当なDNS設定になっているだろう」という仮定で、受信メールサーバーがDNSサーバーに問合せを行います。送信メールサーバーのホスト名とIPアドレスを対応づけるDNSの正引き(A)レコードと逆引き(PTR)レコードの内容が合致しないと、メールを破棄することがあります。
2-c. SPF(Sender Policy Framework)/Sender ID: 「このIPアドレスからのメールは正当です！」ということを示す専用のDNSレコードを、DNSサーバーに登録する手法です。受信メールサーバーはDNSサーバーにSPFレコードを問い合わせ、レコードに記載された送信メールサーバーのIPアドレスとメールヘッダにあるIPアドレスが異なる場合、メールを破棄することがあります。
2-d. DKIM(DomainKeys Identified Mail): SPFに似ていますが、送信メールサーバーがEメールに署名を付加しDNSと組み合わせて正当性を検証する仕組みです。受信メールサーバーはメールの署名を基にDNSサーバーへ問合せを行い、メールの正当性を検証します。

今回はEC2インスタンスからメールを送信するケースなので、上記1.は「AWSのネットワーク設定がどうなっているか」、上記2.は「EC2インスタンスのIPアドレスやホスト名がどうなっているか」を確認することになります。

結論から言うと、どちらも対策をしないと、まともにメールを送信することはできずトラブルの元になります!!
用途に合わせた対策をきちんと行いましょう。

レベル1 : 最低限、やらなければならないこと

EC2の初期状態では、上記1.のAWSのネットワーク制限と上記2-a.のRBLによる制限にひっかかるため、この2つは必ず対応しなければなりません。

1.については、AWSのネットワークからインターネットへのSMTP通信においてOutbound Port 25 Blockingのような制限が、AWSアカウントにひもづくEC2インスタンスに対してかかっています。ただ、実装は不明ですが、100%フィルタされる訳ではなく最初の数回は成功したり、数十回中数回は成功するといった挙動のため、テストでメールを送信するときは気づかずに、本番になってから気づくということが多く、トラブルになりやすいです。

2-a.のRBLは、AWSがElastic IPおよびPublic IPをストックし様々なAWSユーザーに割り当てることから、新規に取得するElastic IPおよびPublic IPが最初からRBLに載っている可能性が高いです。過去に同じIPアドレスを取得したユーザーがスパムメールを送信していたのか、54.250.XX.XX/26というようにCIDR単位でRBLにリストされ巻き添えを食っているのかはわかりませんが、Eメールレピュテーションサービスなどで調べると体感で50%以上の確率でRBLにリストされている感覚があります。

これに対応するためには、AWSのWebサイトでメール送信制限の解除申請を行います。以下のページにアクセスし、必要事項を入力し、フォームを送信します。

アマゾンウェブサービス Request to Remove Email Sending Limitations
https://portal.aws.amazon.com/gp/aws/html-forms-controller/contactus/ec2-email-limit-rdns-request

AWSアカウントでログインする必要があり、ログインすると以下のページが表示されます。入力にあたり、いくつか注意点を補足します。

このページでは、上記1、2-a、2-bの設定を一括で行うようになっています。1のみ、1と2-aのみといった一部登録ができるため、2-bの設定は空欄のままで構いません。また、一度登録してから、2-bの設定を同じページから再申請として追加することも可能です。
1.のうち、メールアドレスとアカウントIDはログイン時の情報から自動入力され、変更できません。申請理由(メール送信の主目的)のみ、記入します。一度申請すれば、Elastic IPを問わず同一アカウント全体で許可されます。Consolidated Billingを利用している場合も、申請は各アカウントごとに別々です。他のAWSサポートページとは異なり、親アカウントで申請しても子アカウントの制限は解除できません。
2-a.については、メール送信を行うEC2にひも付けるElastic IPを入力します。この登録を行うと、AWSがRBLからElastic IPを除外するよう、セキュリティベンダーなどに対応してくれます。Elastic IPを3個以上登録する場合は、同じ画面でくり返し申請します。
2-b.については、メールの送信を行うEC2インスタンスのElastic IPとホスト名の逆引き(PTR)レコードをAWSが登録してくれます。ただし、以下の条件があります。
- EC2に自動設定される、ec2-XX-XX-XX-XX.ap-northeast-1.compute.amazonaws.comというホスト名は不可。独自ドメインの取得が必要です。
- 事前にホスト名とElastic IPをひも付けるAレコードをDNSで登録する必要があります(DNSはRoute 53以外でも可)。
システムのアラートメールなど限られた宛先のみにメールを送信する場合、このためだけに独自ドメインを用意するのは敷居が高いですよね。2-b. DNSレコードの整合性については、チェックしない中継・受信メールサーバーもあるので、まずは2-b.は申請せずにメールが送れるかどうかを検証し、問題がなければ登録なしで運用するケースもありだと思います。

数日で申請結果がメールで通知され、対応完了です。思う存分、メールを送りましょう！

レベル1.5 : メールゲートウェイのススメ

先ほどの対応の通り、各EC2からインターネットに直接メールを送信する場合、メールを送信する全てのEC2インスタンスのElastic IPを登録しなければなりません。Auto Scalingなど、Elastic IPを使わない動的に付与されるPublic IPを使う場合も対応が難しいです。

そんなときには、AWS内で送信メールを中継するメールゲートウェイを経由させる構成がオススメです。EC2インスタンスからメールを送信する際にメールゲートウェイを経由するように設定することで、申請するElastic IPおよび逆引きレコードをメールゲートウェイのみにすることができます。

メールゲートウェイ自体は原理的には通常のメールの中継と同じなので、sendmailやPostfixなどのMTAを動作させるEC2インスタンスで対応できます。Amazon LinuxでのPostfixの設定例を以下に示します。あと、セキュリティグループの設定も忘れずに。

メールゲートウェイの設定

Postfixの設定例(/etc/postfix/main.cfの抜粋)

inet_interfaces = all

mynetworks = 10.0.0.0/16 # VPCのネットワークアドレスで1行追加

メールを送信するEC2の設定

メールを送信するEC2インスタンスでは、メールゲートウェイ経由でメールを送信するよう、設定します。アプリケーションから直接SMTP通信を行う場合はSMTPサーバーとしてメールゲートウェイを指定し、PHPのmail関数などローカルのMTAを経由する場合にはSMART_HOST(sendmail)やrelayhost(Postfix)を設定します。

Postfixの設定例(/etc/postfix/main.cfの抜粋)

relayhost = [10.0.0.150] # メールゲートウェイの内部IPアドレスを1行追加

レベル2 : やっておいた方が良いこと

レベル1でメールを送信できる状態にすることはできますが、メールマガジンなど多数のユーザーにメールを送信するケースの場合、送信精度を上げる目的で上記2-cのSPFおよび2-dのDKIMにも対応する方がベターです。

SPF

以下は、SPFのDNSレコード(example.comドメイン)の例です。example.comドメインのメールは、example.comの正引き(A)レコードのIPアドレスからであれば信頼できることを示します。

example.com.   IN TXT "v=spf1 a:example.com -all"

DKIM

Amazon Linux + Postfixの組み合わせであれば、EPELリポジトリに含まれるOpenDKIMの利用が手軽です。opendkim-genkeyコマンドでDKIMキーペアを生成し、一緒に作成されるレコードをDNSに登録します。

default._domainkey      IN      TXT     ( "v=DKIM1; k=rsa; "
          "p=XXXXXXXXXXXXXXXXXXXXXXXXXX.." )  ; ----- DKIM key default for example.com

続いて、Postfixの設定でメール送信時にOpenDKIMによってメールに署名を付加するよう設定します。

宛先メールアドレスリストのメンテナンス

また、メールの宛先のユーザーがメールアドレスを変更したり、退職やISPの乗り換えなどでメールアドレスが使えなくなり、送信エラー(User Unknown)になる場合もあると思います。この送信エラーが蓄積すると、RBLに載ってしまう原因になるため、送信エラーになるユーザーはリストから外すなど宛先リストの定期的なメンテナンスも重要です。

レベル1、レベル2のショートカット : SESの活用

Amazon SES(Simple Email Service)は、AWSが提供するメール送信のアプリケーションサービスです。
SESであれば、SMTP25番ポート以外での送信に対応しているのでメール送信の事前申請が不要ですし、RBL対策も必要ありません。SPF/DKIMについても、Route 53の設定を自動生成する機能があり、上記レベル2のような自前で準備する場合に比べ非常に簡単に対応することができます。

ただし、暗号化なし、認証なしの純粋なSMTP通信では利用できないなど、いくつかの制限事項があるため、EC2インスタンスでメールを送信するアプリケーションが、SESの要件を満たすかどうかを確認する必要があります。
使用できるケースであれば、SESがイチオシです！

具体的な設定方法は、横田のブログエントリーをご覧ください。

まとめ

EC2からEメールを送信する際に行うべき対策、行うとより良い対策についてご紹介しました。スパムメールの対策技術は日進月歩で、また新しい手法が登場するかもしれません。この記事も随時アップデートしたいと思っていますが、皆さんもぜひ関心を持ってスパムメール対策を行っていただけると幸いです。
うまく対応して、AWSで構築するメールシステムを使い倒しましょう！