Internet Infrastructure Review（IIR）Vol.59
2023年6月23日

1. 定期観測レポート

メッセージング

1.1 電子メールと30周年

昨年30周年を迎えたIIJは、これまでにたくさんのサービスを作り、世に送り出してきました。とりわけ電子メールはインターネットにおけるインフラサービスの中でも、かなり古参の部類です。今も数々の新しいサービスが生まれていますが、始まりがあれば終わりもあり、新規サービスを作るよりも、今運用されているサービスをお客様への影響を最小限にしつつ、いかに安全に終了させるかの方が遥かに大変であることは、あまり知られていません。

本章の前半ではIIJが24年間提供し、昨年サービスを終了した「IIJポストオフィスサービス」を振り返ります。また、後半は送信ドメイン認証技術「DMARC」について、現在進行中の新たな議論と、IIJのメールサービスで観測している電子メールの経路暗号化について報告します。

1.2 IIJポストオフィスサービス

IIJポストオフィスサービスとは、お客様の独自ドメイン名を用いてメールの送受信が行える法人向けメールホスティングサービスです。

利用を開始するにはお客様のDNSサーバでMXレコードをIIJに向けていただくのみ、今やどのホスティング事業者も備えている機能ですが、記録によれば1998年7月にサービスを開始しています（注1）（注2）。メールの保存容量は無制限、受信メールは14日間保存できる機能仕様でした。

IIJの高品質なバックボーンに直結し、安定したサービス提供をしており、お客様にご好評いただいていたのはもちろん、電子メールが企業における必須のビジネスツールであることから、担当営業からも「売りやすいサービス」として社内の知名度を上げていました。

その後も、次々と機能追加・関連サービスのリリースをしています（表-1）。

年月	項目
2001年7月	ウイルスプロテクション（ウイルス対策）機能追加（注3）
2002年12月	「IIJメールゲートウエイサービス」開始。メール監査オプションを追加（注4）
2003年3月	MailViewer（Webメール機能）を標準提供（注5）（注6）
2004年10月	迷惑メールフィルタオプション追加（注7）
2006年10月	「IIJセキュアMXサービス」開始（注8）
2010年1月	送信ドメイン認証技術DKIM標準対応（注9）
2010年6月	IPv6に標準対応

表-1 IIJポストオフィスサービスの変遷

1.2.1 長寿命サービスの課題

どのような企業も、新たに生み出したサービスは、なるべく大きく売り上げ、利益を生むサービスに育て、それを長期間に渡って提供したいと思うのが自然です。IIJポストオフィスサービスは、まさにそのようなサイクルを生み、IIJの成長に大きく貢献したサービスの1つでした。

しかし、息の長いサービスを運用していると、遅かれ早かれ、次のような3つの課題に直面します。

⑴ソフトウエアが最新の技術に対応できない

ソフトウエアの技術革新は日進月歩で変化しています。読者がソフトウエア技術者であれば、日々肌で感じていることでしょう。開発当初は最新の技術だったものも、数年後にはまた新しい技術が生まれ、より良い仕組みが開発されています。

そのような中で古いコードに修正を加えながら、最新のトレンドにキャッチアップしていくのは大変難易度の高い業務であり、スキルもさることながら、高いモチベーションも必要です。

歴史の長いサービスは、刻々と変化するインターネットのセキュリティ要件や、お客様から頂戴する新機能の要望や改善にお応えするのが難しくなってきてしまいます。

⑵脆弱性対応に限界が見えてくる

ソフトウエアは開発したら終わりではありません。毎日のように報告されている脆弱性対応や、いずれ訪れるミドルウエアのEoLに対応する継続的な保守開発が必要であり、一般的にサービスのリリースサイクルは、新規開発よりも保守開発の方が圧倒的に長いことも重要なポイントです。

例えば、IIJポストオフィスサービスは、OSのサポート終了に伴って、6世代、7種類のOSを入れ替えながらサービスの提供を継続していました。こうした保守開発はサービス品質を維持する上で極めて重要で欠かせないものです。しかし、新機能開発と比べて目に見える変化が少なく、現行で動いているものに手を加えるため、新たな不具合を混入してしまうリスクもあり、お客様や担当営業、経営層にも伝わりづらい、地味な開発であることも事実です。

⑶開発当時の背景や経緯が分からない

古いIIJのサービスは「開発したメンバーが運用する」、というケースが少なくありませんでした。これには「最もサービスに精通したメンバーが運用しているので、障害が発生しても復旧が早い」といった良い点がある一方で、そのような「運用でカバー」されてしまった結果、ドキュメント化や新メンバーへのスキルの継承が進みづらいという課題もあります。IIJポストオフィスサービスもその1つでした。

従って、時間の経過とともに開発当初のメンバーは減少していき、サービスの立ち上げや企画に携わった人物ではないメンバーで開発・運用することになります。こうなるとドキュメント化されていない部分は、当時の状況を推し量ることしかできません。「なぜこうなっているのだろう?」という部分が増えていった結果、保守開発や、メンテナンスのハードルが極めて高いものになります。

1.2.2 サービス終了の決断とロードマップ

以上のような背景を抱えながら運用していましたが、ついに延命できない技術的な課題に直面してしまいました。

この状況をステアリングコミッティで共有し、2018年の運用・開発・サポート部門が一同する社内会議にて、「4年後にIIJポストオフィスサービスを終了する」ことを決断しました。このときのアクションプランは次のとおりです。

• サービス終了日の設定
• 後継サービス（IIJセキュアMXサービス）への移行支援体制確立
• IIJセキュアMXサービスに移行支援機能の開発・実装
• 社内アナウンス
• お客様アナウンス
• 担当営業への個別進捗確認

サービスの終了によってお客様が受けるビジネス影響を最小限にするため、今回はすべての担当営業に漏れなく連絡を取り、進捗を確認しました。大変泥臭い業務ですが、IIJの都合でサービスを終了することになりますので、入念な事前調査をしたのちに、サービス終了日の約1年前から営業部門への呼びかけを開始し、全社横断で取り組みました。

1.2.3 24年間の歴史に幕を閉じる

そして2022年9月30日、「IIJポストオフィスサービス」は静かに提供を終了しました。本サービスの終了によって、お客様には大変ご迷惑をお掛けしたことをお詫び申し上げます。

また、普段私のような技術部門から、直接感謝の気持ちをお伝えする機会がございませんが、IIJポストオフィスサービスをご利用くださったすべてのお客様に、この場を借りて厚く御礼申し上げます。

長年のご愛顧をいただきまして、誠にありがとうございました。

なお、IIJポストオフィスサービスの後継サービスとして、IIJセキュアMXサービスをご用意しております。今後とも、IIJのサービスをよろしくお願いいたします。

1.2.4 IIJポストオフィスサービスをご利用だったお客様へのお願い

IIJポストオフィスサービスをご利用いただいたお客様に、最後のお願いがございます。

もし、お客様ドメインのTXTレコードに
include:spf.po.2iij.net
が記述されている場合は、忘れずに削除してください。

サービス終了後の整理を進めており、まもなく、このSPFレコードを削除いたします。

万が一、お客様が電子メールで利用しているドメインにIIJポストオフィスサービス専用のSPFレコード"include:spf.po.2iij.net"が記載されたままですと、このレコードを削除したタイミングから、宛先で送信ドメイン認証の検証が失敗（permerror）することが予想されます。その結果、お客様ドメインでのなりすまし対策に不備が出る可能性があります。

連絡の取れるお客様には、担当営業を通じてご連絡を差し上げていますが、今一度ご確認をお願いいたします。

1.3 DMARC2.0について（M³AAWG topic）

2023年2月、サンフランシスコにて3年ぶりにM³AAWGが現地開催されました。M³AAWG（Messaging, Malware and Mobile Anti-Abuse Working Group）は、2004年に設立され、メールをはじめとするメッセージング技術を中心とした分野に関する議論をする団体であり、世界各国から様々なメンバが参加をしています。IIJのようなMSP（Mailbox Service Provider：メールボックス事業者）や、ESP（Email Service Provider：メール送信事業者）、サーバホスティング事業者、アカデミアの分野からの参加、DNS Federation、アンチスパム/アンチウィルスエンジンなどを提供するセキュリティベンダ等々、近年はメールだけでなくSMSやSNSメッセージングなどの分野に関わる様々な企業や学術機関が参加しています。

M³AAWGの国際会議は年に3回行われており、通例として毎年2月頃にはサンフランシスコ、6月頃にはヨーロッパ地域のどこか、10月頃には北アメリカ大陸の都市で実施されています。

今回のM³AAWGでも様々なテーマについての議論が行われましたが、特に多くの意見が飛び交ったのがDMARC 2.0についてのセッションでした。本稿では、2023年4月時点でのDMARC 2.0（注10）についての情報をまとめたいと思います。

なお、M³AAWGはプライベートミーティングであり、その場での議論の詳細についての公開は禁止されているため、あくまでも公開情報に基づいた内容となります。また、IETFのドキュメント内ではDMARC-bisという表現が使われていますが、本稿ではすべて統一して"DMARC 2.0"と記載します。

現在、送信ドメイン認証技術としてインターネット上で利用されているDMARCは、RFC 7489（注11）にて国際規格として定義されています。DMARC 2.0では、いくつかの変更が現在検討されており、主な変更点は以下です。

• RFC 7489はInformational Categoryだったのに対して、DMARC 2.0は標準化を目指す
• DMARCポリシーの取得にPublic Suffix Listを使わずにDNS Tree Walkを利用するように変更
• 一部タグの廃止、並びに新しいタグの追加

1.3.1 Public Suffix ListとDNS Walk Tree

Public Suffix List（注12）とは、eTLD（Effective TLD）と呼ばれるドメインを管理する有志のリストです。FirefoxやThunderbirdなどの製品で知られているMozillaが管理していたものが、現在はボランティアによって更新の運用がされています。

日本国内でよく見かけるドメインとしては、co.jpやne.jp、更には地方自治体で利用されているドメインなどが登録されています。

RFC 7489の記述では、Public Suffix Listに登録されていないドメインに対して組織ドメインの探索や決定ができないことが問題視されていました。DMARC 2.0では、DMARC評価時の組織ドメインの決定とDMARCポリシーの探索に、DNS Tree Walkを利用することでその問題を解決したとのことです。

DMARCレコードを登録、公開するドメイン所有者視点では特に変更をする箇所はありません。それに対して、メールを受信してDMARCレコードを評価するIIJセキュアMXサービスのようなサービスを提供するIIJを含めたメールボックス事業者にとっては、ドメイン評価時のプログラムを改修する必要があると思われます。

1.3.2 タグの廃止、並びに新しいタグの追加

DMARC 2.0では表-2に示すタグの削除と追加が予定されています。ここで、IIJのようにDMARCレポートを受信していたり、DMARCレコードによるフィルタリングを実装している事業者が気になる点は、DMARC 2.0が導入された際に、新しいタグ並びに削除されるタグに対する対応をどのタイミングで開始・終了するべきなのか、という点です。DMARCレコードは、そのドメインを管理している組織によって実施されており、そのレコードの更新も各組織が任意のタイミングで実施します。そのため、削除予定であるタグへの処理対応をいつ止めるのか、追加予定であるタグへの対応をいつから開始するのかを見極める必要があると考えています。

拡大する

表-2 DMARC 2.0にて追加/削除予定のタグ

1.4 送信ドメイン認証とSTARTTLS普及状況の報告

1.4.1 送信ドメイン認証統計

IIR Vol.55でも掲載をしたIIJセキュアMXサービスで受信したメールについての送信ドメイン認証対応の割合をグラフにしています（図-1）。

SPF検証結果については、前回とほぼ同じ比率となっていますが、DKIM pass並びにDMARC passの比率はそれぞれ8ポイント程度増加しています。昨今のなりすましメール対策として、徐々にではありますが日本でもDKIM署名の実装やDMARCポリシーの指定を行う企業が増えていることが分かります。2023年2月には、総務省よりクレジットカード会社各社に対して、DMARC導入によるフィッシングメール対策強化が要請されています（注13）。

拡大する

図-1 IIJセキュアMXサービスで受信したメールにおける送信ドメイン認証対応の割合

1.4.2 受信/送信STARTTLS統計

数年前から、メールを取り巻くセキュリティ問題のトピックの1つとして、PPAP（パスワード付き暗号化ZIPファイルを添付したメールのやりとりの俗称）の廃止が挙げられることがよくあります。

以前のIIRでもトピックに挙げたEmotetと呼ばれるウイルスの流行を受けて、PPAP廃止の施策を進めている企業を取り上げた報道もありましたが、依然として日本のインターネットセキュリティを取り巻く問題として度々話題に上がっています。

1年前に発行したIIR Vol.55に、IIJもPPAPを廃止したというトピックがありましたが、今回は、添付ファイル暗号化ではなく通信経路の暗号化という観点から考察をしていきたいと思います。

企業においてPPAPは、実際にメールを送信される従業員の方並びにメール送信システムで人間が認識しやすい形で添付ファイルを暗号化するプロトコルですが、そもそもファイルを添付したメールの通信そのものが暗号化できれば、情報漏えいのリスクが軽減できるのではないか、ということで、今回は2022年4月から2023年4月のおよそ1年間、IIJセキュアMXサービスにおいてインターネットからのメール受信並びにインターネットへのメール送信の際に、どれくらいの割合のメールがTLS通信にてやりとりをされたのかを可視化しました。

IIJセキュアMXサービスでは、メールの送受信の際の経路暗号化に対応しています（注14）。

メールの送信プロトコルであるSMTPではTLS通信をする際にSTARTTLSという拡張プロトコルが使われます。対向のサーバに対して接続が確立したのちにTLS通信を施行し、対応しているTLSバージョン並びに暗号化方式でEnvelope From、Envelope To、DATA（メールのヘッダと本文データ）の通信を行います。対向サーバがTLSに対応していない場合は、そのまま平文でやりとりをしてメールを送信します（注15）。

まず、IIJセキュアMXサービスで2022年4月から2023年4月の約1年間で受信したメールについて、どれくらいの割合でSTARTTLSが利用されていたかを図-2に示します。

IIJセキュアMXサービスは、様々な企業のお客様に利用されているため、インターネット上の多様なサーバからの接続を観測しています。

日によっては、特定のお客様宛に送信される標的型攻撃や、ばらまき型と呼ばれるフィッシングメールが観測されることもあります。

それらのメールは、インターネット上の様々なサーバから送られてきますので、STARTTLSを用いたSMTP通信の暗号化をせずにメールを送信するサーバも多くあると考えられます。

また、2022年4月から2022年5月の時期にSTARTTLSの割合が大きな幅で上下しているのは、おそらく当時流行していたEmotetがインターネット上の多くのサーバから送信されてきていたのではないかと推測できます。

次に、IIJセキュアMXサービス設備からインターネットへ送信したメールについてのSTARTTLS利用状況を図-3に示します。

IIJセキュアMXサービスからの送信メールについては、送信先サーバがSTARTTLSに対応していない場合を除いて経路暗号化が実施されるために、受信メールの状況と比べて高い比率で通信の暗号化がされている様子が窺えます。

IIJでも長年、添付ファイル自動暗号化機能を提供してきましたが、昨今のEmotetをはじめとする暗号化ZIPファイルを用いたウイルスへの対策として、数年のうちに機能提供の終了を予定しています。

通信経路の暗号化とメールに添付されているコンテンツの暗号化は一概に比較はできないと思いますが、このデータがPPAP脱却のお役に立てれば幸いです。

拡大する

図-2 IIJセキュアMXサービスでの受信メールにおけるSTARTTLS利用の割合（2022年4月〜2023年4月）

拡大する

図-3 IIJセキュアMXサービスでの送信メールにおけるSTARTTLS利用の割合

1. （注1）IIJ、「IIJポストオフィスサービス開始」（https://www.iij.ad.jp/news/pressrelease/1998/pdf/postoffice.pdf）。
2. （注2）マイクロソフト社から Windows 98 がリリースされたのが、同月の1998年7月でした。
3. （注3）IIJ、「IIJ、ウイルス対策サービスを7月1日より開始」（https://www.iij.ad.jp/news/pressrelease/2001/pdf/po-virusprotection.pdf）。
4. （注4）IIJ、「IIJ、中堅企業向けの情報漏洩対策サービス『IIJ Mailゲートウェイサービス』を開始」（https://www.iij.ad.jp/news/pressrelease/2002/pdf/iij-mgw.pdf）。
5. （注5）IIJ、「IIJ、『IIJポストオフィスサービス』に新機能『MailViewer』を追加」（https://www.iij.ad.jp/news/pressrelease/2003/pdf/0327.pdf）。
6. （注6） Webメールの代表格であるGmailが招待制で公開されたのが2004年です。
7. （注7）IIJ、「IIJ、企業向け電子メールアウトソースサービスに迷惑メール対策機能を拡充」（https://www.iij.ad.jp/news/pressrelease/2004/pdf/0928.pdf）。
8. （注8）IIJ、「IIJ、メールのあらゆるリスク管理を実現する『IIJセキュアMXサービス』を開始」（https://www.iij.ad.jp/news/pressrelease/2006/pdf/0905.pdf）。
9. （注9）IIJ、「IIJ、『IIJポストオフィスサービス』において送信ドメイン認証技術『DKIM』に対応」（https://www.iij.ad.jp/news/pressrelease/2010/pdf/po_dkim_2.pdf）。
10. （注10）IETF、Datatracker（https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/）。
11. （注11）IETF、Datatracker（https://datatracker.ietf.org/doc/html/rfc7489）。
12. （注12）github、「publicsuffix/list」（https://github.com/publicsuffix/list）。
13. （注13）総務省、「クレジットカード会社等に対するフィッシング対策強化の要請」（https://www.soumu.go.jp/menu_news/s-news/01kiban18_01000184.html）。
14. （注14）IIJ、「経路暗号化」（https://www.iij.ad.jp/biz/smx/other.html#anc02）。
15. （注15）ietf.org、「SMTP Service Extension for Secure SMTP over Transport Layer Security」（https://www.ietf.org/rfc/rfc3207.txt）。

1. 定期観測レポート メッセージング

• 1.1 電子メールと30周年
• 1.2 IIJポストオフィスサービス
• 1.3 DMARC2.0について（M³AAWG topic）
• 1.4 送信ドメイン認証とSTARTTLS普及状況の報告