メール送受信系サービスを構築する際に気をつける事

はじめに

イタンジの福崎です。 弊社で運用しているサービスで現在年間約1000万通ほどのメッセージを送受信しています。 チャットなども含みますがメールが大半を占めており、メール送受信周りでは障害含め色々ありました。 今回はメール送受信系に限って運用で得た失敗や経験を元に、気をつけることを自分用のメモも兼ねて残します。

前提

  • aws sesを利用

メールループ

①メール送る→②自動で返信が来る→③受信する→④自動で返信する→②に戻る

初歩的ですがやってしまうと大きな障害になる可能性があります。 メッセージをDBに保存したりしていると、処理能力によっては一瞬でdisk fullになり最悪の場合サービスを停止することになります。 一回処理が外に出ることもあり、ソースコードレベルではループにならないので見落としがちですが、レビューワー含め以下の点に問題がないことを確認する必要があります。

  • メールの宛先が同サービスになっても無限ループしないようになっているか
  • Mailer Daemonや休日自動返信等で送り先から自動でメールが返ってきても無限ループしないようになっているか

迷惑メール対策(送信側)

これはメール送信してるサービスは少なからずぶち当たるのではないでしょうか。 SPFDKIMが設定されてればokなんて甘い世界ではなく、容赦なく各ベンダーが独自仕様で迷惑メールフィルタを構築しています。 全く同じメールだけど、gmailには届いてyahooには届かない、またはauには届いたけどdocomoには届かないということが発生します。

根本対策はやはりユーザーに価値のあるメールを送り、必要なくなったらユーザー側で簡単に配信停止できるようにしておくことだと思います。 いくら技術的に対応を入れてもユーザーに無価値なものを配信してしまうと迷惑メールに入ってしまいます。

その上で迷惑メールに入らないように対応してきたことを以下に記載します。

SPFDKIMの設定

この辺りはRFCで定められているのでマストで入れておきます。 以下の記事がわかりやすいです。

sendgrid.kke.co.jp

キャリアによってはSPFの設定をエンベローブFromではなくヘッダFromを見るのでヘッダFromのドメインSPFの設定が必要です。

qiita.com

バウンス対応

バウンスメールとは不正なメールアドレスに送信した時、またはメールボックスが満杯で受信出来なかった等の配信エラーを送信元に通知するエラーメールの事です。 これを放置してエラーの送信先に送り続けたりするとバウンスレートが上がり、AWS SESを使っている場合は制限をかけられてしまう可能性もあります。 バウンスを適切にハンドリングする必要があります。

電子メールの仕組みにおいて、送信したメールメッセージが何等かの理由で目的の送信先に正常に配信されなかった場合に、メールサーバからその旨を送信元に通知されるメールメッセージのこと。エラーメールやリターンメールとも称される。(wiki)

ja.wikipedia.org

AWS SESを使っている場合はSNSで通知を受け取ることが可能です。 通知の受取先をアプリケーションエンドポイントにしてハンドリングすることも出来ます。 https://docs.aws.amazon.com/ja_jp/ses/latest/DeveloperGuide/notifications-via-sns.html

メール内容の改善

このサービスを使うとメール内容を解析し改善点をスコアリングして表示してくれます。 imgタグにaltつけろとか結構細かい所まで指摘してくれます。

http://www.mail-tester.com/

ドメインの変更

長年運用しているドメインがある場合はそのドメインからメールを送信するようにしたほうが良いです。 以前新規ドメインを取得してそちらからメールを送信するようにした所到達率が明らかに下がり元に戻したことがありました。

メール送信サービスの変更

特定のキャリアにどうしてもメールが届かないため、AWS SESからSendGridへの乗り換えを検討しましたが その時は検証段階で逆に到達率が下がったので結局乗り換えを行いませんでした。

踏み台対策

過去一度以下のような攻撃の踏み台に利用されたことがありました。

f:id:g_fukusaki:20200105163701p:plain

攻撃者は xx.com (xx.comというのは仮です)を攻撃対象に、不特定多数の問い合わせフォームに xx.com のメールアドレスへサンキューメールが行くように 自動postを行い、xx.com に一斉に不特定多数からサンキューメールが届いてパンクするというものです。 弊社のサービスはおそらく踏み台に使われたひとつで、同時にかなりの数のサービスが踏み台に使われていた可能性が高いです。

機械的にpostさせないためにformにキャプチャ認証を入れる等の対応や、メール送信側も短時間での大量送信にリミットをかけたり メトリクスを仕込んで監視しておくと良いと思います。(AWS SESを利用している場合はSES側でリミットがかかっています)

最後に

書いてみると迷惑メール対策が大半の記事になってしまいました。 他にもメール送受信系のサービスでこういうことあったとかありましたら、はてぶのコメント等で教えてもらえると嬉しいです。