「マルチメディア，分散，協調とモバイル(DICOMO2021)シンポジウム」 令和3年6月-7月

透過型 SMTP プロキシによるメール送信集約とキュー輻輳回避の検討
小田 知央1

廣川 優1

近藤 宇智朗1

嶋吉 隆夫2

笠原 義晃2

概要：電子メールは古くから用いられているメッセージ交換手段で，依然として世界的に広く利用されている．メールサービスを提供するメールホスティングでは，多数の利用者を同一システムに収容するマル
チテナント型によりリソース効率を高め，運用コストを低減している．メールホスティングでは利用可能なグローバル IP アドレス数やメール送信の集中管理のため送信サーバは集約されていることが多いが，大量メール送信や送信先の迷惑メール対策により送信キューの輻輳が発生することで，問題を起こしたテナ
ント以外にも影響が波及し，サービス品質の低下や管理コストの増大をまねいている．本研究では，テナ
ントごとの送信キューの分離と，メール送信の集中管理や送信用グローバル IP アドレスの管理を両立す
る，メール送信集約用の透過型 SMTP プロキシを提案する．また，送信キューの分離によってキュー輻輳
時の影響範囲が限定される効果を確認するための予備実験と，透過型 SMTP プロキシのプロトタイプ実装について述べる．

A Study on Aggregation of Email Transfer and Avoidance of Queue
Congestion using a Transparent SMTP Proxy
Tomohisa Oda1

Yuu Hirokawa1

Uchio Kondo1

Takao Shimayoshi2

Yoshiaki Kasahara2「テナント」とは，ホスティングサービスの利用者（組織）1. はじめにに割り当てられる仮想的な領域であり，メールサービスの電子メールは古くから用いられている電子的メッセージ

場合はメールドメインと，そのドメインで発行された多数交換手段である．近年は電子メールを代替する様々なメッのメールアカウントを含んでいる．メールホスティングにセージングツールが利用されているが，依然として電子

おいて，グローバル IPv4 アドレス数の制約や送信メールのメールは世界的に広く利用されている．その一方で，電子集中監視といった要請から，外部にメールを送信するサー

メールには迷惑メール対策 [1] やアカウント乗っ取りなど

バは集約し，単一または少数の MTA (Message Transferによる不正メール大量送信への対応 [2] など，セキュリティ

Agent) によりメール送信する構成が一般的である．

的に対応しなければならない課題が多い．メールサービス

一方で，外部送信用メールサーバを集約する構成には課には，これらの問題に対応しながらもメールが遅延しない

題がある．この構成では、送信サーバの送信メールキュー

ような安定性やセキュリティの担保が求められる．

がシステム全体で共有されることになるが，そのことに起利用者にメールサービスを提供するメールホスティング

因する問題が生じる．例えば正常に送信可能な範囲を超え

では，多数の利用者を同一システムに収容するマルチテナ

る大量のメールが利用者から外部に送信されるなどして，ント型により集積率を高めることで，リソース効率を高め

大量のメールが送信メールキューに滞留することがある．

て，低コストでのサービスを実現している．なお，ここで同じ事象は，送信先メールサーバにより，迷惑メール対策

1

2

GMO ペパボ株式会社
GMO Pepabo, Inc.
九州大学情報基盤研究開発センター
Research Institute for Information Technology, Kyushu University© 2021 Information Processing Society of Japanなどを理由に送信サーバからの受信レートが制限された場合にも発生する．メールホスティングにおいて，送信メー
ルキューの滞留は，システム全体でのメール送信の遅延に― 1479 ―つながる．この問題は，少数の送信サーバによる負荷分散インを担当するサーバを取得し，そのサーバに接続してだけでは，完全に解決することはできない．また，テナン

メールを送信する [3]．一般的に MTA には送信キューが用ト間での IP アドレスの共有に起因する課題もある．利用

意されていて，送信すべきメールは一旦キューに入って順者による不正メール送信などによって，メール送信サーバに送信処理される．DNS で宛先サーバの情報を取得できの IP アドレスが拒否リストなどに掲載され，宛先サーバ

たとしても，そのサーバに常時接続できるとは限らず，配により接続拒否や受信レート制限を受ける場合がある．そ送できなかったメールはキューに残して一定時間後に再送の場合，同じ送信サーバを利用する善良な利用者のメールを試みたり，長時間配送できなかったメールは破棄して送も受信拒否やレート制限の対象となる．もしホスティング

信元にエラーメッセージを返したりする．サーバが外部にのテナント別に送信サーバの IP アドレスを分離できれば配送するべきメールを受け付ける数が，実際に外部に配送

この問題は解決できるが，大規模なメールホスティングでできる数より多くなる状態が輻輳である．なんらかの理由

収容テナント数と同数のグローバル IPv4 アドレスを用意

により輻輳が発生すると，キュー長の増大によりメールがすることは一般的に不可能である．

キューに滞留し，その MTA による全てのメール送信が遅

本稿では，マルチテナント型メールホスティングにおい延する．

て，不正メール送信による他の利用者への影響を限定的と

メールホスティング環境において，メール配信の遅延はする，メール送信サーバの構成方法に関する検討について

サービス品質に関わる大きな問題である．ネットワークや述べる．提案する方法では，メール送信ゲートウェイとしサーバの能力がアカウント数やメール流量に対して不足すて透過型 SMTP プロキシを利用することで，メール送信

ることによる輻輳であれば，送信サーバを複数用意して負の集約による集中管理と，利用者間でキューの分離による荷分散することで，輻輳を軽減できる．しかし，アカウン

キュー輻輳の回避を両立する．テナント別送信サーバから

トの不正利用による迷惑メール送信では一時的に数万〜数インターネットへのメール送信は，透過型 SMTP プロキ

十万通のメールが投入されるような場合があり，通常の負シを経由して送信する．これにより，テナント別送信サー

荷分散で完全に輻輳を解決することは困難である．アカウ

バでは既存のメール送信ソフトウェアに変更を加えること

ントの不正利用については 1 アカウントが単位時間に送信

なく，送信サーバと宛先サーバ間での SMTP コマンド・応できるメール数を制限するといった入口対策も重要だが，答を，ホスティングシステム全体で網羅的に収集，制御で送信キューの輻輳は様々な理由で起こりうるため，出口側

きる．また，透過型 SMTP プロキシはキューを持たないの対策も必要である．

ことから，コンテナにより送信キューをテナント分離する

送信キュー輻輳によるメール遅延は，原理的にはテナン

ことで，他テナントの影響でメールがキューに滞留するこト毎に送信キューを分離する事で影響範囲を特定のテナンとがなく，ホスティングシステム全体でのメールキューのト内に限定できる．利用者の MUA (Mail User Agent) か輻輳を回避できる．

らの送信メールを受け付ける MSA (Message Submission

本論文の構成を述べる．2 章では，メールホスティング

Agent) については内部的にテナント分離される場合もあサービスにおけるメール送信の課題について述べる．3 章

る．しかし，不正メール送信への対策やメール送信状況のでは，この課題を解決するためメール送信集約用の透過型

集中管理などの要請などから，メールを外部に送信する

SMTP プロキシを提案する．4 章では，提案した機能の概

MTA を集約し，送信キューがテナント間で共有される構念実証のため，送信キュー分離の効果を確認する予備実験

成が一般的である．我々が過去に提案した高集積マルチアと，プロトタイプ実装ついて述べる．5 章でまとめとする．

カウント型メール基盤 [4] においても，MSA は軽量コンテ

2. メールホスティングにおけるメール送信機
能の課題

ナにより高集積とテナント分離を両立させる構成となっていたが，送信メールのウイルス検査や，ホスティング全体の送信メールについて網羅的・集中的に情報を収集して不本章では，メールサーバ，特に集積度の高いメールホス

正メール送信対策等を行う必要性から，送信メールはテナ

ティングが，他のメールサーバにメールを送信する際に考ント間で共有のメール送信ゲートウェイコンテナから外部

慮すべき課題について述べる．

に送信する設計を採用しており，送信キューは集約されていた．送信キューが集約されるメールホスティング環境において，送信キュー輻輳は，高集積であればあるほど，影

2.1 大量メール送信
電子メールは，各組織が自分のメールドメインを持ち，響範囲が拡大する．

自組織の利用者にメールアドレスを付与し，各ドメインのサーバ同士がメッセージを交換する分散運用が前提となっ2.2 IP アドレスによる配送制限ている．各メールサーバは DNS (Domain Name System)

電子メールはインターネット上の任意のホストから配信を利用して，MX レコードから宛先メールアドレスのドメされうることが前提であるため，外部からメールを受信す© 2021 Information Processing Society of Japan― 1480 ―るメールサーバはインターネット全体からの接続を受け付を送信したい場合には，最初に低レートでメールを送信ける必要がある．一方，電子メールはフィッシングやマル

し，だんだん流量を増やす（ウォームアップする）必要がウェアの配布など，悪意を持った目的での利用も多く，イある [8]．レート制御の詳細は，攻撃者によって回避され

ンターネット上には悪意を持ったサーバやクライアントもるとを防ぐため非公開となっており，メール受信を拒否さ多く存在する．そのようなホストからの迷惑メールや不正

れてはじめてスロットリング対象になっていることがわか利用を防ぐために，SMTP セッションの接続元 IP アドレる．筆者らの所属する九州大学では，全学のメールサービスに基づいてメール受信を制限する技術が多くのメール

スを Exchange Online に移行した直後，学内の他のサーバサーバで利用されている [5]．それらの技術は，メールを受からの転送メールや，安否確認のための一斉送信サービス

信する側のセキュリティ向上のために必要な一方で，メーからのメールがスロットリング対象となったことがある．

ルサービス自体には悪意がない場合でも不正利用や誤判定

このように，現状の電子メールシステムでは迷惑メーにより制限の対象となることで，正常なメールの配送に影ル対策などのセキュリティ対策として，送信元の IP アド

響を受けることがある．

レスに基づいて受信側でさまざまな制限が行われている．

悪質なホストが利用する IP アドレスを登録したリスト

メールホスティングでは，送信サーバの IP アドレスが制を用いて，登録 IP アドレスからの接続やメール受信を拒限対象になると，利用者に多大な影響がある．メール送信

否する方法は広く用いられている．サーバに静的な拒否リ側から見ると，受信側でどのような受信制限を行っている

ストを用意して手動で IP アドレスを登録する方法も用いかは一般的に分からない．また，実際に接続拒否や一時的られるが，手動での拒否リスト管理は煩雑でコストが高いなメール受信拒否をされるまでは，制限対象になったことことから，ログの出力を元に一定期間接続を拒否するようも分からない．管理者は，送信先で受信制限を受けているなソフトウェアを利用することもある．また，複数のサーかをエラーメールやログ，利用者からの問合せなどから抽バや監視システムで収集した情報に基づいて拒否すべき IP

出し，拒否リストからの除外依頼などの対応を行なう必要

アドレスの一覧を作成し，それを講読者に提供するサービがある．サービス品質に大きな影響を与えるため，速やかス [6] もあり，単一サーバでの情報収集には限界があることな検知と迅速な対応が必要である．もしテナントごとに別から，サービスとして提供されている拒否リストを購読し個のグローバル IP アドレスを割り当てることができれば，てメールサーバで利用する例は多い．拒否リストは IP ア

ある IP アドレスが制限対象になっても他のテナントにはドレスやネットワーク単位であるため，メールホスティン

影響しない．しかし，近年はグローバル IPv4 アドレスのグで送信に利用しているグローバル IP アドレスが特定の確保が困難で高コストであることから，高集積なメールホ

拒否リストに含まれると，そのリストを利用しているサー

スティングサービスでグローバル IPv4 アドレスをテナン

バにはメールを配送できなくなる．拒否リストでメール受

トと同数用意して完全なテナント分離を実現することは事信を拒否する場合には，リストから除外する方法を提供す

実上不可能である．現実的には，メール送信に利用する複ることが推奨されており，SMTP の応答メッセージなどに数のグローバル IP アドレスのプールを用意し，テナント

その情報を含めて返すのが一般的である [6]．

間で共有する方法がとられる．状況により特定 IP アドレ

また，許可・拒否の二択ではなく，レピュテーション（評スの利用を一時的に止めたり，新しい IP アドレスをプー

判）に基づいてメール受信を制御する方法も用いられる．

ルに追加する際に事前にウォームアップしたりするなど，

レピュテーションのしきい値を決めて拒否したり，レピュ

限られた IP アドレスをやりくりして運用する必要がある．

テーションの値に応じて単位時間に受け取るメールの流量

例えば Exchange Online では拒否リストに入ってもいい高を制限したりする．メールサーバに対するレピュテーショ

リスク配送プールを別に用意する運用をしている [9]．

ンを提供するサービスでは一般的に，長くインターネット
上に存在し正常なメールを送出している IP アドレスは評判

3. 透過型 SMTP プロキシ

がよく，悪意のあるメールの送信元としてセキュリティ対

メールホスティングにおいて，メール送信の集中管理や策機器で検知された IP アドレスが評判が悪くなっていく．

情報収集機能を維持しつつ 2 章で述べた問題に対処する方

また，あるメールサービスにとってなじみのない IP ア

法として，メール送信集約用の透過型 SMTP プロキシをドレスからのメールには受信レート制御をするという，IP提案する．

スロットリングという仕組みを導入しているサービスや透過型プロキシとは，クライアントとサーバ間のネットサーバ製品もある．例えば，Microsoft Exchange Online

ワーク経路に設置され，クライアントとサーバはお互い直では，今まで Exchange Online にメールを送信したことが接通信しているように見せつつ，セッションに対する付加ない IP アドレスからのメールには強い送信レート制限が処理を行うことができるプロキシである．クライアント・課せられる [7]．IP スロットリングを実装しているメール

サーバ間の通信内容を収集・改変したり，ウェブプロキシ

サービスに対し，新しい IP アドレスから継続的にメールであれば通常のウェブキャッシュのようにサーバコンテン© 2021 Information Processing Society of Japan― 1481 ―ンドによる TLS 暗号化が一般的になっている [11][12]．暗号化が送信サーバと宛先サーバで終端されている場合，経収集情報の出力

路上でセッションの内容を取得することができない．つまり，MSA が宛先 MX サーバに対して STARTTLS コマン

収集

コマンド

改変

応答

MSA

宛先サーバ
宛先MXサーバ

TLS 暗号化されることになり，透過型 SMTP プロキシでは透過型SMTPプロキシ

内容を確認できない．しかし，本提案では，TCP セッショ

メールホスティング

図 1

ドを発行すると，それ以降のコマンド・応答メッセージはン情報だけでなく，SMTP コマンド・応答メッセージの内透過型 SMTP プロキシによるメール送信部の構成

Fig. 1 Mail sending facility using a transparent SMTP proxy.

容も情報収集・検査の対象とすることを考えている．そこで，透過型プロキシにより TLS 暗号化を制御することとした．具体的には，宛先 MX サーバからの EHLO コマンド
応答に「TLS 暗号化通信可能」を意味する STARTTLS の提示があった場合，宛先 MX サーバとの TLS セッション

コマンド

MSA

送信キュー

宛先サーバ
宛先MXサーバ

応答

確立は透過型 SMTP プロキシが行い，TLS 通信を透過型

SMTP プロキシで終端する．これにより，インターネット

送信用MTA

上の SMTP 通信は暗号化で保護しつつ，MSA からの送信

メールホスティング

メール情報を一元的に収集できる．このとき，MSA と透過
図 2 従来のメールホスティング環境の一般的構成

型 SMTP プロキシとの間で暗号化が不要であれば，透過型

Fig. 2 Conventional mail hosting environment.

SMTP プロキシで EHLO コマンド応答から STARTTLSを削除して MSA に返すことで，透過型 SMTP プロキシツをキャッシュしたり，暗号通信をプロキシで終端すること MSA との間は平文で SMTP セッションを開始できる．

とによって平文に戻し，通信内容を検査したりすることがMSA と透過型 SMTP プロキシとの間も暗号化したい場合できる．SMTP 通信を検査する際に透過モードを利用可能

は，MSA において任意のホストに対して透過型 SMTP プ

なセキュリティ製品がある [10]．

ロキシのサーバ証明書を許可するように設定することで実現できる．

3.1 透過型 SMTP プロキシの動作
透過型 SMTP プロキシによるメール送信部の構成を図 1

3.2 透過型 SMTP プロキシの特徴に示す．「MSA」は，利用者が MUA から送信するメール

メールホスティングにおいて 2.1 節で述べた大量メールを受け付けるメールサーバである．従来の一般的なメール送信による影響を最小限に留めるには，キューをテナント

ホスティング環境の構成（図 2）では，外部への送信メーごとに分離し，そのキューから直接外部にメールを送信す

ルは，MSA から「送信用 MTA」に転送されてキューに格る必要がある．一方 2.2 節で述べたように，テナントごと納されたのち，送信用 MTA から「宛先 MX サーバ」に送に別の IP アドレスを付与するのは現実的でないため，送信される．一方，提案する構成では，MSA がメールを外信 IP アドレスは集約する必要がある．

部に送信する際に，通常通り DNS で宛先ドメインの MX

送信用 MTA ではなく透過型 SMTP プロキシを用いるこ

レコードから「宛先 MX サーバ」の IP アドレスを取得し，とで，キューを持つことなく，少ないグローバル IP アドレ

SMTP セッションを開始する．しかし，実際にはそのパスで集約してメールを送信可能である．送信 IP アドレスを

ケットは「透過型 SMTP プロキシ」で一旦受け取る．透過

集約するだけであれば，SNAT (Source Network Address

型 SMTP プロキシは，ここで SMTP のコマンドメッセー

Translation) でパケットの送信アドレスを付け替えることジの内容に対して検査や情報収集などの必要な処理を行う．

でも実現可能だが，送信メールの集中管理には別の仕組み

その後，MSA からのコマンドメッセージを，場合によっが必要となる．

ては改変を伴って，透過型 SMTP プロキシがバインドすさらに，送信キューは MSA ごとに持つ構成となるため，

る SMTP 送信用 IP アドレスから本来の宛先サーバへと送

先行研究のように MSA をテナントごとに分離すれば，あ信する．宛先サーバからの応答メッセージは透過型 SMTP

るテナントが大量にメールを送信したとしても，キュー長

プロキシの SMTP 送信用 IP アドレス宛に送られるので，の増大が他のテナントに影響を与えることがない．透過型

コマンドメッセージと同様に情報収集や改変などののちSMTP プロキシで収集する情報に基づいて，不正利用が疑に，本来の送信元である MSA に転送する．

われるテナントやアカウントからのメール送信には，透過

最近では，MTA 間の SMTP 通信についても，インター
ネット上での盗聴を防ぐ目的などから，STARTTLS コマ© 2021 Information Processing Society of Japan型 SMTP プロキシで通信レートを制御するなどの対応も可能である．

― 1482 ―外部サーバ(模擬)送信サーバ

送信集約サーバ(単一のPostfix)

tarpit(受信遅延サーバ)

ベンチマーク用
送信スクリプト
コンテナ群
Postfix

Postfix

受信サーバ

図 3 実験の構成

Fig. 3 Preliminary experimental system.

透過型 SMTP プロキシでは，送信に利用する IP アドレ
スを集中的に管理するだけでなく，宛先 MX サーバからの図 4 メール配信数の時間経過

SMTP 応答も集中管理できる．このことから，例えばある

Fig. 4 Time series of message delivery counts.

送信用 IP アドレスが拒否リストに登録されたり，スロッ
トリングの対象となったときに，応答メッセージや応答タ
イミングなどを分析することでこれを検知可能である．例
えば，複数の送信用 MTA を用意して別個の送信用 IP ア
ドレスを用いる構成においてある送信用 IP アドレスが拒否リストに登録された場合，当該 MTA のキューにメールが滞留することになり，キュー内のメールは送信用 IP ア
ドレスを付け替えるまで送信できず，アドレス付け替え
後に順次送信されるのを待つ必要がある．しかし，透過型

SMTP プロキシは自身がキューを持たないことから，透過型 SMTP プロキシでのメール送信遅延は発生しない．さらには，透過型 SMTP プロキシに複数の送信用 IP アドレスを設定しておけば，拒否リストに登録された IP アドレスの使用を停止するだけで，メール送信が継続できる．

4. 概念実証

サーバとして mxtarpit*1 を使用した．なお，本実装では標準で SMTP 応答を 1 文字につき 3 秒かけて返す設定となっていたが，実験にかかる時間を考慮し 0.25 秒に変更している．これにより，tarpit 宛のメール送信には通常以上に時間を要することとなり，結果的にメール送信レートが低下することでキューの輻輳が発生する．また，tarpit の影響を明確に可視化するため，実験開始 5 分後に受信遅延サー
バ宛メールを 80 通送信している．キュー分離構成では，あるテナントが不正メールを送信している状況を想定し，通常のメールと受信遅延サーバ宛メールはベンチマーク用送信スクリプトから別の MSA へと送信する．
本実験でのメール配信数のグラフを図 4 に示す．横軸は実験開始からの時間（分）であり，青がキュー分離の構成で配信完了した通常メールの積算通数，黄がキュー共有の構

4.1 予備実験
予備実験として，送信キューの分離によってキュー輻輳
時の影響範囲が限定される効果を確認するための実験を行った．実験の構成を図 3 に示す．実験は，Ubuntu 20.04

LTS 上で実施した．「ベンチマーク用送信スクリプト」は，多数の利用者からのメール送信を模擬するスクリプトである．従来法では送信用 MTA サーバでキューが共有されることから，ベンチマーク用送信スクリプトは単一の Postﬁx
経由でメールを送信する（キュー共有）．一方，提案手法の模擬構成（キュー分離）では，MSA 別にキューが分離されることになるので，コンテナを利用して複数の Postﬁx を

MSA として起動し，ベンチマーク用送信スクリプトは複数 MSA 経由でメールを送信する．
送信キューでの輻輳を発生させることを目的に，本実験
では送信先の 2 ドメインのうち 1 つを tarpit として動作させる．tarpit は迷惑メール対策の 1 つで，相手が悪意のあるサーバと判定した場合などにセッションは切断せずに応答の送出を極端に遅らせ，送信サーバによるメール送信の© 2021 Information Processing Society of Japan

完了を遅延させる仕組みである [13]．本実験では，tarpit

成で配信完了した通常メールの積算通数である．tapirt 宛
メールの送信開始時点を灰色縦線で示している．キュー分
離構成では，tarpit 宛メールの送信開始前後でレート変化
なくメールが受信できていることが分かる．一方，キュー共有構成では，tarpit 宛メールの送信開始後には配信レー
トが著しく低下しており，大きな配信遅延が生じていることが分かる．これは，tarpit へのメール送信に大きく時間が掛かることから，Postﬁx の送信キューにメールが滞留し，さらには Postﬁx でのメール受理が不能になり，送信ス
クリプトからのメール送信にも遅れが生じたことによる．
この結果から，送信キューを分離することで，メール送信
遅延の影響範囲が限定されることが確認できた．

4.2 プロトタイプ実装
提案する透過型 SMTP プロキシが実現可能であることを示すため，プロトタイプを開発した．実装言語は go 言*1

― 1483 ―https://github.com/martinh/mxtarpit/

この実験により，宛先 MX サーバとの間で TLS 暗号化通信を行う場合でも，透過型 SMTP プロキシで SMTP セッ

MSA(sender)

ションの情報を収集・検査可能であることが確認できた．

iptablesMX

宛先MXサーバ(receiver)

5. まとめ

透過型SMTPプロキシ本研究では，高集積マルチテナント型メールホスティン
グにおけるメール送信機能で解決すべき課題を述べ，その解決方法としてメール送信集約用の透過型 SMTP プロキ

収集情報の出力（ログ）シを提案し，キュー分離によるメール送信遅延の問題回避
図 5 プロトタイプ検証環境の構成を確認する予備実験，および，プロトタイプ実装と動作検

Fig. 5 Prototype test bed.

証を行った．これらの実験により，提案手法の概念が実証できた．

語である*2 ．なお，本実装では，TLS 対応を簡略化するた

今回実装した透過型 SMTP プロキシのプロトタイプはめに，MSA と透過型 SMTP プロキシを同一ホスト上で動機能が限られているが，今後，実装を改良していく予定

作させることを前提とし，3.1 節で述べた方法を用いて，宛である．例えば，透過型 SMTP プロキシでは，宛先 MX

先 MX サーバと透過型 SMTP プロキシとの間だけで TLS

サーバからの応答を収集できるだけでなく，各 SMTP コ

通信を行い，MSA と透過型 SMTP プロキシとの間は平文

マンド・応答メッセージの送受信に掛かった時間などの情で通信する実装とした．また，収集した情報はログとして報も出力できる．これにより，受信拒否や一時受信不能に出力する実装としている．

よる明示的な受信制限だけでなく，tarpit やそれに類する本プロトタイプの動作確認実験を行った模擬環境の構成

通信レートによる受信制限も検知可能だと予想している．

を図 5 に示す．MSA からのパケットを透過型 SMTP プロ

また，アカウント，テナントや宛先 MX サーバ，送信メー

キシプロセスにリダイレクトするために Linux の iptables

ルの疑わしさなどによって送信用 IP アドレスを使い分けを使用している．

ること，拒否リストの掲載を理由に受信拒否したという応

透過型 SMTP プロキシを起動し，MSA (sender) から宛

答メッセージを受け取った場合に当該 IP アドレスを自動

先 MX サーバ (receiver) にメールを送信した際のプロキシ的に利用停止するなどといった機能拡張が考えられる．

でのセッションログの例を図 6 に示す．図 6 で時刻情報に

さらに，本研究では送信用 MTA の代わりに透過型 SMTP

続く「<-」は sender に送信された応答（プロキシで改変さプロキシを用いる方法を提案しているが，透過型 SMTP

れたものを含む），「->」は receiver に送信されたメッセー

プロキシは既存のシステムにも容易に追加できることかジ（プロキシで改変されたものを含む），「|<」は receiver

ら，例えば，既存の送信用 MTA と同一ホスト上で透過型から送信されプロキシで終端された応答，「|>」はプロキ

SMTP プロキシを動作させて情報収集に利用することも可シから receiver に送信されたメッセージ，「>|」は sender能である．今後，ホスティングサービスの実運用に影響をから送信されプロキシで終端されたメッセージである．

与えない範囲で透過型 SMTP プロキシを導入し，実際の図 6 の 1，2 行目で平文での SMTP 接続を開始している．

SMTP コマンド・応答の情報を収集し，受信制限の自動検

5 行目で receiver からの応答には TLS による暗号通信の開知や不正メール送信の自動防止のために分析を進めていく

始が可能であることを示す「STARTTLS」が含まれていことを検討している．

るが，6 行目で sender に返す際にはその行を削除すること
で，sender は平文のまま SMTP 通信を続ける．7 行目で謝辞 本研究は JSPS 科研費 JP20K11791 の助成を受けたものです．

sender とは独立にプロキシから STARTTLS コマンドを発行し，TLS セッションを確立するとともに，10 行目で再参考文献

び EHLO コマンドを送る事で SMTP セッションを再開す[1]

る．その応答である 12 行目は sender に返す必要がないた
め破棄している．8 行目で sender から受け取ったメール送
信のためのコマンドは一旦プロキシで保持しておき，TLS
セッションが確立した後に 14 行目で receiver に送信して[2]いる．なお，実際にはこれらのメッセージは暗号化されて送信される．その後も，引き続き通常の SMTP セッションを継続することで，メール送信を完了している．
*2

https://github.com/linyows/warp/© 2021 Information Processing Society of Japan― 1484 ―松井一乃， 金高一，加来麻友美， 池部実，吉田和幸： milter の組合せによる低配送遅延を目指した spam 対策
メールサーバの設計と導入の効果について，情報処理学会
論文誌，Vol. 55, No. 12, pp. 2498–2510（オンライン），入
手先 ⟨https://ci.nii.ac.jp/naid/110009851536/⟩ (2014).
Tsuzaki, Y., Matsumoto, R., Kotani, D., Miyazaki,
S. and Okabe, Y.: A Mail Transfer System Selectively Restricting a Huge Amount of E-Mails, 2013
International Conference on Signal-Image Technology
Internet-Based Systems, pp. 896–900 (online), DOI:
10.1109/SITIS.2013.146 (2013).

1
2
3
4
5

6

7
8

9
10
11
12

13
14

15
16

17
18

2021/02/06 14:50:48 connected from 192.168.30.40:57493
2021/02/06 14:50:48 connected to 192.168.30.50:25
2021/02/06 14:50:48 <- 220 receiver ESMTP Postfix (Ubuntu)\r\n2021/02/06 14:50:48 -> EHLO sender\r\n2021/02/06 14:50:48 |< 250-receiver\r\n250-PIPELINING\r\n250-SIZE 10240000\r\n250-VRFY\r\n250-ETRN\r\n250-STAR
TTLS\r\n250-ENHANCEDSTATUSCODES\r\n250-8BITMIME\r\n250-DSN\r\n250-SMTPUTF8\r\n250 CHUNKING\r\n2021/02/06 14:50:48 <- 250-receiver\r\n250-PIPELINING\r\n250-SIZE 10240000\r\n250-VRFY\r\n250-ETRN\r\n250-ENHA
NCEDSTATUSCODES\r\n250-8BITMIME\r\n250-DSN\r\n250-SMTPUTF8\r\n250 CHUNKING\r\n2021/02/06 14:50:48 |> STARTTLS\r\n2021/02/06 14:50:48 >| MAIL FROM:<root@sender> SIZE=327\r\nRCPT TO:<root@receiver> ORCPT=rfc822;root@receiver\r\nDATA\r\n2021/02/06 14:50:48 |< 220 2.0.0 Ready to start TLS\r\n2021/02/06 14:50:48 |> EHLO sender\r\n2021/02/06 14:50:48 pipe locked for tls connection
2021/02/06 14:50:48 |< 250-receiver\r\n250-PIPELINING\r\n250-SIZE 10240000\r\n250-VRFY\r\n250-ETRN\r\n250-ENHA
NCEDSTATUSCODES\r\n250-8BITMIME\r\n250-DSN\r\n250-SMTPUTF8\r\n250 CHUNKING\r\n2021/02/06 14:50:48 tls connected, to pipe unlocked
2021/02/06 14:50:48 -> MAIL FROM:<root@sender> SIZE=327\r\nRCPT TO:<root@receiver> ORCPT=rfc822;root@receiver\r\nDATA\r\n2021/02/06 14:50:48 <- 250 2.1.0 Ok\r\n250 2.1.5 Ok\r\n354 End data with <CR><LF>.<CR><LF>\r\n2021/02/06 14:50:48 -> Received: from sender (localhost [127.0.0.1])\r\n
by sender (Postfix) with SMTP
id 45B113EA9B\r\n for <root@receiver>; Sat, 6 Feb 2021 14:50:48 +0000 (UTC)\r\nFrom: <root@sender>\r\nTo: <root@receiver>\r\nDate: Sat, 6 Feb 2021 14:50:48 +0000 (UTC)\r\nMessage-Id: <a77e.0003.0000@sender>\r\nSubject:
Hi, Receiver from Sender\r\n\r\nXXXXXXXXXX\r\n.\r\nQUIT\r\n2021/02/06 14:50:48 <- 250 2.0.0 Ok: queued as 76DAD4113D\r\n221 2.0.0 Bye\r\n2021/02/06 14:50:48 connections closed
図 6プロキシでのセッションログ

Fig. 6 A proxy session log.

[3]
[4]

[5]
[6]

[7]

[8]

[9]

[10]

[11]
[12]

Klensin, D. J. C.: Simple Mail Transfer Protocol, RFC
5321 (2008).
松本亮介，小田知央，笠原義晃，嶋吉隆夫，金子晃介，栗林健太郎，岡村耕二： 精緻に制御可能な恒常性のある高集積マルチアカウント型のメール基盤，マルチメ
ディア，分散協調とモバイルシンポジウム 2018 論文
集 ，Vol. 2018, pp. 1383–1389（ オ ン ラ イ ン ），入 手 先⟨http://id.nii.ac.jp/1001/00193543/⟩ (2018).
Lindberg, G.: Anti-Spam Recommendations for SMTP
MTAs, RFC 2505 (1999).
Sergeant, M. and Lewis, C.: Overview of Best EmailDNS-Based List (DNSBL) Operational Practices, RFC
6471 (2012).
Exchange Outlook サポートチーム： IP スロットリング
について，Microsoft（オンライン），入手先 ⟨https://social.msdn.microsoft.com/Forums/vstudio/ja-JP/27b2ffd7-66c9-4c07-b390-dfe59a52e3c4/ip-1247312525124831248
812522125311246412395123881235612390?forum=excha
ngeteamjp⟩ （参照 2021-04-30）.
: IP ウォームアップを行う，構造計画研究所（オンライン），入手先 ⟨https://sendgrid.kke.co.jp/docs/Tutori
als/D Improve Deliverability/ip warmup.html⟩ （参照2021-05-07）.
Microsoft 365: Outbound delivery pools, Microsoft (online), available from ⟨https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/high-risk-delivery-pool-for-outbound-messages?view=o365-worldwide⟩ (accessed 2021-04-30).
MailChannels: Transparent Filtering, (online), available from ⟨https://www.mailchannels.com/transparent/⟩ (accessed 2021-04-30).
Hoﬀman, P. E.: SMTP Service Extension for Secure
SMTP over Transport Layer Security, RFC 3207 (2002).
Melnikov, A.: Updated Transport Layer Security (TLS)
Server Identity Check Procedure for Email-Related Protocols, RFC 7817 (2016).

© 2021 Information Processing Society of Japan

[13]― 1485 ―Hunter, T., Terry, P. and Judge, A.: Distributed Tarpitting: Impeding Spam Across Multiple Servers, 17th
Large Installation Systems Administration Conference(LISA 03), San Diego, CA, USENIX Association, (online), available from ⟨https://www.usenix.org/conferen
ce/lisa-03/distributed-tarpitting-impeding-spam-acrossmultiple-servers⟩ (2003).