メールを中心としたメッセージングセキュリティの対策を検討・実施する国内の業界団体JPAAWG（Japan Anti-Abuse Working Group）は、11月11日～12日に年次カンファレンスイベント「第4回 JPAAWG General Meeting」を開催した。
この記事では、各社のメール運用者がノウハウや苦労話を持ち寄る毎回恒例のパネルセッション「現場発！メールサービスを支える運用者の集い 2021 秋」の模様をレポートする。
パネリストには、ヤフー株式会社の中村成陽氏、フリービット株式会社の三浦敏孝氏、株式会社QTnetの三小田仁氏、株式会社インターネットイニシアティブ（IIJ）の衣笠茂浩氏が登壇した。
Yahoo!メールのDMARC対応とブランドアイコンのその後
ヤフーの中村氏は、前年の「JPAAWG 3rd General Meeting」でも登壇した内容のおさらいと、その後について語った。
前年で話したのは、Yahoo!メールについて、DMARC（Domain-based Message Authentication, Reporting, and Conformance）を導入したことと、本物のメールを視認できるようにするためのブランドアイコンの仕組みを開発したことだ。
DMARCでは、ポリシーの「reject」指定（DMARCで認証が失敗したメールは受信拒否すべしというドメイン所有者側の指定）で「かなりの数」のメールをブロックした。一方でユーザーから必要なメールが届かないという報告は想定より少ないという。
DMARC導入後については、まず、ポリシーのreject指定によってブロックした通数は増加傾向にあり、2020年の同じ時期との比較で約1.6倍だという。これは、DMARCを「pass」したメールも増加傾向にあることから、DMARCを宣言したドメイン数が増えたことが要因だろうと中村氏は推測した。
また、ユーザーからの問い合わせは少ない状況が継続しており、Yahoo!メール自身のポリシーは「quarantine」（DMARCで認証が失敗したメールは隔離）と弱めだったが少し強くすることもできているという。
ブランドアイコンのその後については、導入企業・団体が16社から33社に増えた。また、当初はDKIM（Domain Keys Identified Mail）認証に対してのものだったが、SPF（Sender Policy Framework）認証に対してもブランドアイコンを開始した。さらに、ブランドアイコンの申し込みがなくても、Yahoo!メールが送信ドメイン認証を確認した一部ドメインから受信したメールの送信者アイコンに色が付く「ブランドカラー」機能の提供も開始した。
今後の展望については、ヤフーの送信ドメイン（mail.yahoo.co.jp）におけるDMARCポリシーのrejectへの引き上げを検討中だという。さらに、Yahoo!メールの受信側と送信側で、BIMI（DMARC認証済みのメールにログを表示する規格）の導入も検討中であることも語られた。
メール配送系の実装上で頭が痛い点
フリービットの三浦氏は、スパマー対策についての技術的な苦労話を語った。
まずは積年の課題という、OEM提供のメールサービスにおける、乗っ取り系のスパマー対策について。スパム送信によって最初にインパクトを受けるメール送信サーバーを中心に対策するが、元のID窃取や、送られた結果ブロックリストに登録されたことの対処など、ワークフロー全体への対策が必要だと三浦氏は語った。
その進捗として、パスワード変更画面での強度チェックに対応したことや、ブロックリストのチェックの機械化などを紹介した。
そして次の対策として、IDごとの送信流量制限を順次展開することや、パスワードレス認証は仕組み的に入れにくいことから、ほかの緩和策を検討している点などを説明した。
次はメール配送系の実装上での悩みについて語った。メール配送は、処理が1カ所に閉じれば本質的な難しさはないが、2カ所以上（2段以上）で情報を渡そうとすると面倒なことになるという。
例としては送信ドメイン認証の受信側チェックがある。スパムチェックの後段のメールサーバーでスパムチェックの結果を利用しようとすると、Authentication-Resultsヘッダーをチェックすることになる。ここにはいろいろな情報が盛り込まれているので、sendmail.cfのルールでは行内パターンマッチで簡単に解釈できないという。また、すでにヘッダーが入っていたらどうするかという問題もある。
似た例として、過去に自動応答のループ防止があったが、このときは処理が1カ所だったので難しくはなかったという。
次に、送信サーバの出口分離を試作したものの失敗したという経験について説明した。スパム判定milterの結果をsendmail.cfのルールで取り込むのが無理だったという。
こうした開発がもう少しすっきりできないかというのが三浦氏の悩みだ。sendmailは開発が呪術的（バッドノウハウの塊）で、sendmail.cf開発に若手を引き込みづらいという。また、milterも呪術的かつ融通が効かないと三浦氏。最後に「すっきりしたMTA（Mail Transfer Agent）が欲しい」という心情を語った。
メールサービスをオンプレミスからクラウドに移行した経緯
QTnetの三小田氏は、同社で提供しているメールサービスのシステムを、オンプレミスからクラウド（IIJ xSP/Mail）へ移行した経緯を紹介した。
オンプレミスのメールシステムは、老朽化の一方で、重要性の低下や限られた人的経営資源から、メールサービスの継続性の確保が課題となっていたという。
これをクラウド化することによって、業務負荷をオフロードする「単純化」、クラウドサービスに則った仕様でガバナンスを向上する「標準化」、メールの専門家に任せる「専門化」の3つのメリットがあると説明した。
それでも移行には苦労したと三小田氏。移行にあたっては、想定外の使われ方や野良SMTPサーバーなどのオンプレミス環境の現状を調査し、対策した。また、各部門の幹部や顧客に向けた調整にも時間をかけた。
さらにコロナ禍があったことで、こうした調整のためのコミュニケーションや作業に苦労が増えたが、こうした苦労のかいがあって、大きなトラブルがなく移行ができたという。
メールセキュリティ面については、これまで対応したものとして、OP25B（Outbound Port25 Blocking）、SPF、DKIMなどを三小田氏は挙げた。一方、これからの対応としては、DMARCレポートの蓄積と分析や、DMARCのポリシーを「none」からquarantineやrejectへ移行すること、コーポレイトドメインへの水平展開などを挙げ、「送信ドメイン認証の強化はこれからも図っていきたい」と語った。
最近のメールセキュリティ動向と、Kubernetesでのメールサーバー自動化チャレンジ
IIJの衣笠氏は最近の動向として、IIJでは着信でのアンチウイルスの処理が今年夏ごろから激増しており、中身を見るとフィッシングが大半だと報告した。
また、メール着信におけるSTARTTLS（暗号化プロトコル）の割合が徐々に増加しており、現在で平均45％ぐらいだが、なにがあったのかまだ分析できていないという。
そのほか、TLS 1.0/1.1廃止を推進中であることも報告された。TLS 1.0/1.1の廃止は、ウェブでは進んでいるが、メールにおいては古いAndroidで使えなくなったりするといった問題があってまだ止められないとのことだった。ただし、サービス影響が出やすいPOP/IMAP/WebメールでのTLS 1.0/1.1利用率は1％未満であり、「意外と大丈夫かもしれない」という。
最近のチャレンジとしては、Kubernetesによるクラウドネイティブ化を検討中であることを語った。
現在とあるサービスで、ロードバランサーから切り離し、プログラムや設定を入れ替えてテストし、問題なければそれを数百VMに適用する自動化の仕組みをAnsibleで作り上げた。これをさらに、Kubernetesによってクラウドネイティブ化することを検討しているという。
衣笠氏はKubernetesを試してすごいと思った点について、スケールアウトしたらロードバランサー配下に勝手に組み込んでくれることや、開発環境と本番環境がほぼ同じYAMLからスピーディに作れること、VSCodeでPODに入って開発できることなどを挙げた。
一方で苦労した点としては、まず、ネットワークで考慮すべき点が多いことが挙げられた。POD間の連携において、IPアドレスは変わってしまうことがあるため名前解決が大前提となっており、アプリの工夫が必要だという。さらにメール送信では、NATにより出口IPアドレスの指定に作り込みが必要になる。
このようにKubernetesでのメールメールアプリ作り込みは手間がかかると衣笠氏。ただし、既存の著名アプリケーションのコンテナ化は揃ってきており、コンテナに作るところまでは以前より容易になっているという。
あとは運用を回すところまで仕上げられるかという点については「まだ頑張るべきところが多い」との感想を述べた。特に動的に増やす・減らすといったところでは「想定していないところで手を打つ必要があり、なかなか大変」だという。
最後に衣笠氏は「メールはクラウドネイティブで最新化できると思う。そういったところにチャレンジしていきたい」と締めくくった。