Email 配信にまつわる諸問題 #AWS

最近、自分が担当しているプラットフォームで、メールが届かない事象が頻発した。備忘録も兼ねて、記録を残しておく。

前提

対象システム：EC platform (B to C)
Eメール送信数： 3,000通／日程度

補足（というか、言い訳）

当該環境は海外のベンダーにより管理されており、十分な設計ドキュメントが整備されていなかった。また、Postfix のログ取得すら依頼が必要で、詳細を細部まで完璧に把握することは困難。そのため、こちらでの分析・調査は専らWindowsのコマンドプロンプトとGmailのメールヘッダ、各種Webサービスで行った。

環境

Cloud platform : AWS
メール送信サーバー : EC2 インスタンス
（Commerce solution の BackOffice server に Postfix が同居）
Global側との様々なコミュニケーションから、妄想でざっくりの構成を想像するに以下のような作りになっていると思われる。
CMS から Commerce solution への接続の際に、Internet 経由になっている点は、別topic なので、またの機会に。
ここでは例示のため、便宜上以下の表記にする。
送信元アドレス : hoge@subdomain.example.com
送信元IP : 198.51.100.3

メール未達事象と解決策（時系列）

Gmail で迷惑メールフォルダに振り分けられる
サービスローンチ当初、全くの無知から、数多くの受信サーバーで迷惑メールフォルダ送りになっていた。こういった場合、真っ先に確認すべきは SPF (Sender Policy Framework) の設定。メール送信において基本的な設定のため、SPFレコードの設定はほぼ必須と言える。

SPFの概念や説明は以下が詳しい。
https://salt.iajapan.org/wpmu/anti_spam/admin/tech/explanation/spf/

ここでは、手元で簡単に確認する方法だけ記載する。

1-1. SPF 認証結果確認
まずは、そもそもSPFの認証結果確認から。
これはメールのヘッダを表示して確認する。
Gmailだと、以下のように表示され、分かりやすい。

ここで Pass となっていれば、適切に設定されている。

1-2. SPF レコードの確認
続いて、設定そのものの確認。
nslookup で送信元ドメインの TXT レコードを問い合わせ。（以下では Google のDNS サーバー 8.8.8.8 に問い合わせている）
> nslookup -type=TXT subdomain.example.com 8.8.8.8

適切に設定されている場合：

適切に設定されていない場合：

この場合、上記サイトに記載の通り（4. SPFレコードの記述法）、設定を実施する。

Solution : SPF
iCloud メールに届かない
SPF の対応が完了したものの、Apple のメールを利用しているユーザーから、引き続きメール未達の問い合わせが。迷惑メールフォルダにも入っていないという。icloud.com が多かったものの、me.com など、Apple の提供するメールに広くブロックされている様子。Apple 関連だけに届かない・・・そんな時は、Proofpoint にブロックされているかも。
Proofpoint は Apple が使っている Eメールセキュリティソリューションの Saas ベンダーで、彼らが我々の送信元IPをブロックしているとメールが全く届かない。IP のブラックリスト登録確認はこちら。
Proofpoint : https://ipcheck.proofpoint.com/
確認してみると、見事、ブロックされている。

そのまま解除申請。

すると、暫くして、メールが届くように！！めでたしめでたし。

・・・とはいかず、その数日後、再度ブラックリスト入りし、その後は解除申請とブラックリスト化の繰り返し。しかも毎回、ブロックされるまでの日数が短くなる恐怖・・・やはりこういうのは根本原因の対処をせねばなるまい。ということで、先方に確認すると、どうやら reverse DNS が適切に設定されておらず、generic なものになっているのが原因とのこと。詳細は以下参照。
generic PTR : https://help.proofpoint.com/Get_Help-How_to_Contact_Proofpoint
早速、nslookup で調べてみると・・・
> nslookup -type=PTR 198.51.100.3 8.8.8.8

やはり generic なものに・・・
最終的には、以下の様にFQDNに解決されるよう、DNS 設定を行った。

実際の対応は、次の事象の対応の中で同時に行った（AWSに申請した）ので、そちらを参照。
結果、無事にブロック解除。

Solution : reverse DNS
突然の未達
年末が差し迫った頃、突然、メール配信が滞る事象が発生。
何かと思ったら、EC2 インスタンスのEメール送信上限に到達していたらしい。
どうやら、EC2 インスタンスは、そのライフサイクルの中で送信可能なメールの数に上限があるらしく、通常は 2週間毎の Blue/Green deployment によりメール送信数がリセットされていたのだが、年末は繁忙期のため、フリーズしていたのが災いした。

詳細はこちら：https://aws.amazon.com/jp/premiumsupport/knowledge-center/ec2-port-25-throttle/

結局、ここから[E メール送信制限解除申請]をし、その際に、上で論じていた reverse DNS の設定も依頼できるので、併せて対応。（正確には、海外のベンダーさんに申請してもらった。）

本当は、これで終わるはずだったのに・・・・（続く）

Solution : E メール送信制限解除申請 (AWS)
Spamhaus SBLCSS によるブロック
年明け早々から、中々メールが届かない問題が終わらない・・・
再びAppleさんに届かなかったり、今度はMicrosoftさん系列（hotmail.com など）にも届かなかったりした。さらに、今度は自社ドメインにさえも届かなくなってしまった。自社では、O365 を利用し、セキュリティとしては、MessageLabs : Symantec Email Security.Cloud を導入している。
前回同様、それぞれのメールセキュリティを確認してみると、Proofpoint のブラックリストには入っておらず、Symantec や Microsoft のブラックリストには入っていた。
Microsoft : https://sender.office.com/
Symantec : https://ipremoval.sms.symantec.com/
しかしながら、影響範囲が広いので、まさかとは思いながらも、一般的な Blacklist に登録されているのではないかと疑い、以下のツールで調べた結果、見事にHIT。
MxToolBox : https://mxtoolbox.com/blacklists.aspx
MxToolBox は、メールサーバ、DNSレコード、Webサーバの設定がきちんと反映されているかの確認はもちろん、設定の構文チェックまでできる便利なサイト。その一機能として、迷惑メール撲滅のための団体による各種ブラックリストへの登録有無が確認できる。そして、今回引っかかっていたのが、こちら。
SPAMHAUS : https://www.spamhaus.org/
この団体、この界隈ではかなりの有名どころらしく、こちらに引っかかっていると、結構な範囲でメールが届かなくなるとのこと。Blocklist Removal Center でIPを入力すると、SBL にリストされていた。

しかも、SBLCSS という少し特殊なコンポーネントらしい。
SBLCSS : https://www.spamhaus.org/css/
下の方に「request a delisting」なるリンクがあったので、IP、FQDN と自分のメアドを入力し申請。

直後に飛んできた確認メールに記載のコードを入力し、晴れて登録解除！30分程度でメールが届くように！・・・ってあれ、この流れは・・・というわけで、こちらの件も当然ながらブラックリスト化と登録解除のいたちごっこに・・・
こういった団体のものって、不親切なことに、どこが悪いのか明示されないので対処しにくい。さらにSBLCSSはProofpointと違って、そもそも上記のフォーム以外、コンタクト先が存在しない（SBLなどについてはあるようだが）。というわけで、かなり絶望的。
マーケティング用途ではないものの、バウンス管理もしていないので、送信流量制限などを行う（参考文献：2）も、効果なし。。。
何故このタイミングで・・・それこそ、今まで発生していなかった事象なのに・・・と途方に暮れていたが、やれることをやるしかないので、メールヘッダを心眼で見ることに。画像診断医が診断する時ってこんな気持ちなのかなと、くだらない妄想しつつ・・・
幸い、Gmailには引き続きメールが届いていたので、SBLCSSにブロックされた前後で比較すると・・・いきなり MessageID が違う。

ブラックリスト化以前：

ブラックリスト化後：

そして、一番古い（下の行に位置する）「Received: from」の内容を確認すると、ブラックリスト化後の方は、以下の行が。

Received: from 長ったらしいWebサーバー名 (localhost [127.0.0.1]) by 長ったらしいWebサーバー名.localdomain (Postfix) with ESMTP id ABCDEFG12345 for <アカウント名@gmail.com>; Sun, 1 Jul 2012 23:19:34 +0900 (JST)

何だか怪しいので調べてみると、どうやらPostfixの設定が適切にされていない＝SPAMと誤判定されるリスク高とのこと（参考文献：3）・・・これやんけ。
しかも、Postfix のサイトに標準構成例としてメッチャ記載されとるがな！（日本語版サイトの方は、更新が止まってるかの印象だったので本家参照）
Postfix 標準設定 : http://www.postfix.org/STANDARD_CONFIGURATION_README.html#null_client
myhostname を適切に設定してもらい、無事、届くように！！
これにてようやく、安心して眠れます。。。

Solution : Postfix configuration （メールサーバー設定）

まとめ

今回、実際に色々と対応してみて、メール送信周りは意外と奥が深いことが分かった。そりゃ、皆、Simple Email Solution (AWS)とか、Salesforce Marketing Cloudとか、バウンス管理までしてくれるソリューションの導入を検討するわな。まさか 2020年に、この規模のサービスで、生で Postfix の config 設定とか、少し泣けました。しかも、自分では環境や main.cf にすらアクセスできないという制約つきで・・・そして、こうして振り返ってみると、教科書的に地雷を踏んできた感が否めず、公開するのが少し恥ずかしい。いい勉強にはなったけど。

番外編

SPAM 判定ツール
https://www.mail-tester.com/
SBLCSS など、ブラックリストに載る理由が分からない時、スコアリングと各項目の説明をしてくれる便利なツールが世の中には存在した。
その他の送信ドメイン認証技術
SPF以外にも、DKIM や DMARC など、メール送信に際しては準拠した方がよい技術も散見されたのだが、実際のところは、それらの対応は不要だった。
Gmail のヘッダで確認すると面白いことが分かるかも。
kaggle は全てに準拠してたけど、coursera は DKIM までか。。。
社内ドメインに届かない
上の流れからは逸れるので書かなかったが、本事象の最中に幾度となく、社内ドメインに届かない事象が併発した。エラーの内容（Postfixのログ）は以下の通り。
Recipient address rejected: User unknown in local recipient table
まあ、以下のようなサイトを参考に、適切に設定しなさいよと。
https://www.denet.ad.jp/technology/2018/08/userunknown.html
http://www.postfix.org/LOCAL_RECIPIENT_README.html
Null MX record
https://heartbeats.jp/hbblog/2016/12/null-mx.html
送信専用アドレスなら、null MX レコードも設定しておいた方が親切

参考文献

基本事項 : https://salt.iajapan.org/wpmu/anti_spam/admin/tech/kiso/
Postfix 送信流量制限 : https://www.yuulinux.tokyo/9883/
ブラックリストに載る理由 : https://www.yuulinux.tokyo/10379/

追記

6年前に本家で説明されてました・・・orz
https://www.slideshare.net/AmazonWebServicesJapan/aws-30934799