Vol.2018-IOT-40 No.17
2018/3/5

情報処理学会研究報告
IPSJ SIG Technical Report

精緻に解析可能な恒常性のあるメール基盤の設計
松本 亮介1,a)

小田 知央1

笠原 義晃2

嶋吉 隆夫2

金子 晃介3

栗林 健太郎1

岡村 耕二2

概要：様々なコミュニケーションサービスが普及する中，今もなおメールは広く利用されている．メール
サービスを提供する事業者では，大量のメールアカウントを管理するために，サーバに高集積にメールア
カウントを収容することでリソース効率を高めている．一方で，特定のアカウントによるリソース占有により他のアカウントが影響を受け，サービスのサポート・運用コストの増大やメール遅延などの問題が後を絶たない．本論文では，高集積マルチアカウント型メールシステムを安定化するための，精緻に解析可能な恒常性のあるメール基盤の設計について述べる．

A Design of Elaborately Analyzable Homeostatic E-mail System
Ryosuke Matsumoto1,a) Tomohisa Oda1 Yoshiaki Kasahara2 Takao Shimayoshi2
Kosuke Kaneko3 Kentaro Kuribayashi1 Koji Okamura2

1. はじめにアカウント型のメールシステムでは，アカウント単位のリソース使用量を効率化できるが，特定のアカウントの高負SNS やチャットサービスといったコミュニケーション

荷によって，同一サーバに収容している他のメールアカウ

サービスが普及する中，今もなおメールは広く利用されてントが影響を受けやすい課題がある．その結果，特定のアいる．メールは，広く世界に普及したことと，送信側と受カウントの乗っ取りや大量送受信に伴うリソース占有が信側双方向での利用が前提となるため，両者の同意なくサーバの高負荷を引き起こし，サービスのサポート・運用

メールによるコミュニケーションを別のサービスに変更す

コストの増大やメール遅延などの問題に繋がる．

ることは難しい．そのような背景の中，メールサービスにこれらの問題を解決するために，一般的には予めメール

は，spam メール対策 [14] や大量送受信の問題 [8] 等に対応

アカウント単位でメールの同時送受信数や時間単位での送しながらも，メールが遅延しないような安定性やセキュリ

信数制限等を静的に設定しておく手法 [9] がとられる．しティの担保が求めらている.

かし，そのような手法を採用した場合，予め負荷を制限す

メールサービスを提供するホスティングサービスや ISP

ることはできるが，サーバに収容されている全てのメール

事業者では，大量のメールアカウントを管理しつつハード

アカウントがサーバリソースを適切に使いきるための制

ウェアコストや運用管理コストを低減し，安価にサービス限値を決定することが難しい．また，一般的なメールサーを提供するために，単一のサーバに高集積にメールアカウ

バソフトウェアの制限手法は限定的で，現代の予測困難なントを収容してリソース効率を高めている．高集積マルチ

メールの流量を状況に応じてリソースを制御することは困
難である．

1

2

3

a)

GMO ペパボ株式会社 ペパボ研究所
Pepabo Research and Development Institute, GMO Pepabo,Inc., Tenjin, Chuo ku, Fukuoka 810-0001 Japan
九州大学 情報基盤研究開発センター
Research Institute for Information Technology, Kyushu University
九州大学 サイバーセキュリティセンター
Cybersecurity Center, Kyushu University
matsumotory@pepabo.com

c 2018 Information Processing Society of Japan⃝

本論文では，高集積マルチアカウント型のメール送受信システムを安定化するために，精緻にセッション情報を解析でき，適応的にメールの流量制御やリソース制御を行えるメール基盤の設計について述べる．メールアドレスのドメイン単位でメールの流量を制限するために，メールに関するセッションを受信した時点で，リアクティブにドメイ

1Vol.2018-IOT-40 No.17
2018/3/5

情報処理学会研究報告
IPSJ SIG Technical Report

ン単位でメールサーバプロセスを起動した Linux コンテナあったとしても，ハードウェアリソースが余っている場合を起動させる．このアーキテクチャにより，予測の難しいにおいては，ドメイン間のリソース利用量の違いを許容でメール流量やリソース使用量の変化に素早くシステムを変きる．ハードウェアリソースを共有することによって複数更できる．同時にセッション情報をセッション管理データ

ドメインでのリソース使用量を効率化し，各ドメインのリベースに保存し，メールの送受信時にセッション情報を解

ソース使用量の違いに対する運用・管理コストを低減でき析できるようにする．

るというメリットがある．状況によっては，一般的にサー

メール送受信の流量を制御したい場合には，セッション

ビス利用者の専用のサーバや VM よりも複数ユーザの共有

情報の統計値を活用したり，システム管理者がセッショサーバの方がハードウェアスペックが高いため，価格以上

ンデータに基づいて判断したりすることにより，メールの性能を得られることがある．

サーバソフトウェアの制限設定と Linux コンテナのリソー

一方で，多数のドメインを高集積に収容することにより，ス制御手法を組み合わせて実現する．また，Sendmail の

ひとつのドメインがメールを大量に送受信したりするこ

メールフィルタープラグイン機能である Milter プロトコとによりリソースを占有し，他のドメインがメールを正常

ル [1] を活用して既存の SMTP サーバソフトウェアであるに送受信できなくなる課題がある．そういった問題によっ

Postfix[4] の制限手法を拡張したり，IMAP サーバソフトて，サービスプロバイダのサポートや運用・管理コストがウェアの Dovecot[3] の拡張プラグインを実装することで，増加し，コストを低減するための高集積マルチアカウント

SMTP/IMAP コマンド単位やメールアドレス単位でメー

型のメールシステムが，かえってコストを増大させること

ル流量やリソース使用量を精緻に制限できるようにする．

につながる．

これらのシステム設計には，我々が研究開発している，

そこで，高集積マルチアカウント型のメールシステムに実行環境の変化に素早く適応できる恒常性を持つシステムおける採用のメリットとデメリットを比較しながら，流量アーキテクチャの FastContainer[13] を応用する．メール

制御の課題を整理する．

の流量が増加した場合には，FastContainer によって，メー
ルサーバプロセスが起動しているコンテナをオートスケー

2.1 送信流量制御手法の課題

リングによるスケールアウト，またはスケールアップ型の高集積マルチアカウント型のメールシステムでは，シス

リソース増加により対応する．実行環境の状態変化を素早

テムを介してメールを送信する場合に，メールサーバに接く実現できるアーキテクチャを利用して，リソースを効続している特定のクライアントの過剰な接続による影響を率化するために，FastContainer の方式により，メールの与えないようにするために様々なリソース制限手法 [9] がセッションが生じていない場合はコンテナを自動的に停止ある．広く利用されている SMTP サーバソフトウェアでさせる．

ある Postfix では，接続クライアント単位で以下の制限が本稿の構成を述べる．2 章では，従来の高集積マルチア

可能である．

カウント型のメールシステムの課題について整理する．3• 接続クライアント単位での同時接続数

章では，提案手法の設計と FastContainer アーキテクチャ• 接続クライアント単位での単位時間あたりの接続数の概要ついて述べ，4 章で提案するメールシステムの実装• 接続クライアント単位での単位時間あたりのメッセーの進捗について述べる．5 章でまとめとする．

2. 高集積マルチアカウント型のメールシステ
ムの流量制御の課題

ジ配送要求数• 接続クライアント単位での単位時間あたりの送信可能な受信者アドレス数
上記のように，クライアント単位での柔軟な制限は可能

メールサービスを提供する企業や大学では，大量のメーであるが，メールアカウント単位やドメイン単位での制限

ルアカウントを管理しつつも，ハードウェアコストやシスはできないという課題がある．そのため，多数のクライア

テムの管理・運用コストを低減するために，高集積マルチントから接続があった場合には，メールアカウントあるいアカウント型のメールシステムを採用している．ここで，はドメイン単位といった細かい粒度でのリソース使用量を高集積マルチアカウント型のメールシステムは，CPU の論

適切に制限できない．

理コア 24，メモリサイズ 32GB の昨今の一般的な PC サー

筆者が所属する GMO ペパボ株式会社では，一般的なバにおいて，メールのドメイン数を数万程度収容するシス

SMTP サーバソフトウェアを利用した高集積マルチアカウ

テムを想定している．

ント型のメールシステムにおいて，メールアドレスやドメ

高集積マルチアカウント型のメールシステムでは，単一イン単位での同時送信数を個別に制限できる機能を独自にのサーバのハードウェアリソースを，複数のメールアカウ

実装している [5]．この制限によって，特定のメールアドレ

ントのドメインで共有できることはメリットにもなる．各スが大量にメールを外部に送信したとしても，同時送信数

ドメインのメール処理におけるリソース使用量に差異が制限内でしか送信できない．そのため，特定のメールアド

c 2018 Information Processing Society of Japan⃝2

Vol.2018-IOT-40 No.17
2018/3/5

情報処理学会研究報告
IPSJ SIG Technical Report

レスが大量送信によってリソースを占有することを防止でdefer は (1) の段階でキューに入れることなくエラーを返す

きる．

べきである．

一方で，同時送信数を静的に設定しており，全てのメー(3) においては，MUA から IMAP や POP3 によってメー

ルアドレスやドメインの制限が固定であるため，サーバリ

ルを受信する際に，高集積マルチアカウント型メールシス

ソースが余っていたとしてもそのリソースを適切に利用

テムでは大量にアクセス集中が生じる場合がある．そのたできない．また，サーバ収容設計時に事前にハードウェア

め，例えば IMAP/POP サーバソフトウェアとして広く使やソフトウェアから適切に制限値を決定することは，メーわれている dovecot では，クライアント IP アドレスの同ルの流量を予測できないことと相まって困難である．経験時接続数を制限する設定はあるが，メールアカウントやド的に制限値を決定すると，ハードウェアリソースを必要以

メイン単位で個別に設定することはできない．また，特定上に余らせてしまったり，高負荷状態になってから改めてのアカウントによる IMAP の検索や大量メールの操作処

制限値を決定するなど，流量の管理コストが増大しがちで理によってリソースを占有することがある．この場合，特ある．

定のアカウント単位や，IMAP コマンド単位でのリソース

特定のドメインのメール送信処理に対するリソース使用量が平常時よりも超過している状況で，平易にオートス
ケーリングのようなリソース追加を部分的に実施することも困難である．

使用量の制限をする必要があるが，そのような制限手法はない．
特定のドメインのメール受信処理に対するリソース使用量が平常時よりも超過している状況で，平易にオートス
ケーリングのようなリソース追加を部分的に実施すること

2.2 受信流量制御手法の課題
メールシステムにおける受信処理を以下の 3 つの処理にも困難である．サービス利用者によっては，追加料金を支払うことによって，サービスの快適性を求める状況もあり分類する．

得るが，2 節で言及した高集積マルチアカウント型メール( 1 ) 外部の MTA(Mail Transfer Agent) から管理対象のシステムのプロセスモデルのように，大量のアカウントを

MTA がメールを受信する処理( 2 ) 管理対象の MTA にキューとして溜まったデータを
メールサーバのメールボックスに配送する処理( 3 ) MUA(Mail User Agent) によってメールボックスから
メールデータを受信する処理

単一のサーバプロセスで管理している場合には，そういった要求に答えることが難しい．

3. 提案手法の設計
3.1 設計概要(1) については，高集積マルチアカウント型メールシス

2 節の課題から，高集積マルチアカウント型メールシス

テムの場合，多数のドメインに対するメールを受信するたテムにおいて，メール流量をドメイン単位で個別に制御可

め，2.1 節で言及したことと同様に，メールアドレスやドメ

能であり，流量制御のきっかけとなる調査を精緻に収集しイン単位で個別に受信数を制限できるが，静的な設定になたデータから精緻に解析可能な基盤が必要である．さらり，制限値を経験的に決定することは困難である．また，に，出来る限り高集積マルチアカウント型のリソース効率

外部からのメール受信は，送信する場合と比較して，メーのメリットを両立する必要もある．

ルシステムのサービス利用者が外部からメールが送られて本研究では，高集積マルチアカウント型メール送受信シくることを制御できないため，サービスとしてはできるだ

ステムを安定化するために，精緻にセッション情報を保けメールを受信できるようにすべきである．そのため，送存・解析でき，適応的にメールの流量制御やリソース制御

信処理の制限と比較して，メールシステムのゲートウェイを行うためのメール基盤の提案とその設計について述べに位置する MTA の受信処理は，制限が必要な時だけ制限

る．メールアカウントのドメイン単位でメールの流量を制するといったことが求められる．

御するために，メールセッションを受信した時点で，ドメ

一方で，外部からの spam メールを受信や，利用者のイン単位でリアクティブにメールサーバプロセスをコン

Gmail 向けへの転送設定によって spam メールが大量に転テナ上に起動させる．同時にメールの送信，受信共にセッ送されてしまうことにより，Gmail 側から拒否メールが大ション情報をセッション管理データベースに保存し，メー量に送り返されることもある．そのような現象によって，ルの送受信時にセッション情報やその解析結果に基いて流(2) の処理過程においてサーバに defer キューが大量に溜量制御できるようにする．セッション情報の統計値を活用

まり，システム管理者に通知が届くが，対応すべきこともしたり，サーバ管理者が判断したりすることにより，メーないため，システム管理者の疲弊を招くことになる．本

ルサーバプロセスの制限設定とコンテナのリソース制御手

来メールキューの監視は，転送先 MTA から返信されたエ法を組み合わせて流量制御を実現する．

ラーメールが適切であるかどうかをシステム管理者が認

これらの設計には，我々が研究開発している，実行環境

識する場合に必要であり，明らかな spam メールに基づくの変化に素早く適応できる恒常性を持つシステムアーキテ

c 2018 Information Processing Society of Japan⃝3

Vol.2018-IOT-40 No.17
2018/3/5

情報処理学会研究報告
IPSJ SIG Technical Report

図 1 FastContainer アーキテクチャ概要図

図 2 HTTP FastContainer のアーキテクチャ

Fig. 1 Concept Design of FastContainer Architecture

Fig. 2 HTTP FastContainer Architecture

3.3 恒常性に基づくリソース効率化と精緻な流量制御の両立

FastContainer アーキテクチャによる恒常性により，メー
クチャの FastContainer アーキテクチャ [13] を応用する．

ルセッションが生じない状況においてはプロセスを絶えず

メールの流量の増加を検知した場合には，FastContainer

起動させておく必要はない．そのため，メールの処理が行アーキテクチャによって，メールサーバプロセスが起動しわれていないコンテナは一定期間で停止させることによているコンテナを自動的にスケールアウト，またはスケー

り，リソース使用量を節約し，集積率を高める．

ルアップ型のリソース増加を行う．

一方で，メールの送受信のゲートウェイ用途のコンテナと，ウィルスや spam メールのフィルタ用途のコンテナは3.2 FastContainer アーキテクチャの概要

大量のセッションが予想されるため，FastContainer の拡

FastContaier アーキテクチャとは，実行環境の変化に素張として，常に 1 以上の数のコンテナが循環しながらも早く適応できる恒常性を持つシステムアーキテクチャであ起動している状態を担保する ResidentContainer として動る．従来の Web ホスティングサービスを利用できる程度作させる．ResidentContainer は，FastContainer と違い，の知識を持った個人が Web コンテンツを配信することをSMTP セッションにリアクティブにコンテナを起動せず，前提に，サービス利用者が負荷分散のシステム構築やライシステムのスケジューラによって新しいコンテナの起動とブラリの運用・管理を必要とせず，迅速にユーザ領域を複

振り分け先登録を行う．これは，全く起動していない状態

数のサーバに展開可能にするアーキテクチャである．

があり得る FastContaier と違い，最低 1 つ以上のコンテナ

図 1 に示すように，Linux コンテナの起動を HTTP リ
クエスト単位でリアクティブに決定し，実行環境の変化にが起動していることが保証されるため，リアクティブ性がそれほど要求されないと判断したためである．

素早く適応できる恒常性を持つことを特徴としている．こ恒常性に基づくリソース効率化と精緻な流量制御と両立

こで述べる「リアクティブな決定」とは，HTTP リクエス

するために，ドメイン単位でメール送信コンテナ (SMTP)

ト単位で状況に応じたコンテナの構成，例えば，起動，停とメール受信コンテナ (IMAP) をそれぞれ起動させる．

止，起動数，リソース割り当て，起動継続時間 (ライフタドメイン単位でコンテナを起動することにより，Postfixイム)，といった状態を迅速に決定することを意味する．そのような SMTP サーバソフトウェアや Dovecot のようなの特性から，コンテナの起動後は，リクエストを処理を行

IMAP サーバソフトウェアの制御設定を特定のドメインにいながらライフタイム経過後に破棄され，プロセスがリク

対して活用できるようになる．また，IMAP のコマンド単

エストを処理していないアイドル状態のまま起動している

位での CPU 使用率の制限や，ドメインよりもより粒度の時間を短縮することも可能であり，マルチテナント方式の

細かいメールアカウント単位での制御も，SMTP コンテナ

リソース効率を高めている．

は Milter とセッションデータベースとの連携，IMAP コ

FastContainer アーキテクチャは，現時点では，図 2 にンテナはサーバソフトウェアを拡張してセッションデー

示すように，HTTP リクエストに基いてリアクティブに

タベースと連携して行えるようにする．セッションデータ

コンテナを起動させることが前提になっている．本研究でベースについては 3.4 節で言及する．

は，FastContainer を SMTP セッションでコンテナを立ちさらに，コンテナは cgroup[10] の機能により，プロセス上げられるように拡張する．SMTP や IMAP も HTTP とレベルでのリソース制御機構が組み込まれいてる．サーバ

同様に，メールアドレスのドメインに基いて通信対象のコ

ソフトウェアのプロトコル前提の設定で対処が難しい場合

ンテナを区別することができる．

は，コンテナのリソース制御により，特定のドメインの処

c 2018 Information Processing Society of Japan⃝4

Vol.2018-IOT-40 No.17
2018/3/5

情報処理学会研究報告
IPSJ SIG Technical Report

ResidentContainer アーキテクチャ共に，近藤が中心となって我々が開発しているコンテナランタイムの Haconiwa[11]を利用することにより，SMTP や IMAP セッションに応じてリアクティブに状態を変化させられるようにする．
メールシステムにキューとして受信したくないメールについては，CMDB API と連携してセッション情報の解析
結果を取得し，ゲートウェイの時点でエラーを返すようにする．セッション情報の保存と取得，及びエラーの判定は，SMTP の各セッションで Milter プロトコルを介して事前にフックされた Ruby スクリプトを実行できる Milter サー
提案するメールシステムのフロー

バソフトウェアの pmilter*1 として実装した．この Ruby ス

Fig. 3 Proposed E-mail System Flow

クリプトファイルはセッション毎に都度実行されるため，

図 3

SMTP コンテナ起動中であっても，再起動させることなく理に使われる CPU 使用率やメモリ使用量の割り当てのみ

Ruby の実装を変更させることができる．pmilter により，を部分的にリアルタイムで変更できる．

ResidentContainer であっても即時流量制御の振る舞いや設定を反映させることができる．
次に，ゲートウェイコンテナからウィルスや spam メー

3.4 精緻にセッション情報を保存
各ゲートウェイやフィルタコンテナ，および，ドメイン

ルフィルタコンテナ (virusgw) に配送する．フィルタコン

単位での SMTP コンテナや IMAP コンテナのセッション

テナを通過できるメールは，ドメイン単位で LMTP プロ

処理時に，Milter やサーバソフトウェアの拡張機能によトコル [6] で起動する IMAP コンテナ群にプロキシするたり，セッション情報をデータベースに精緻に保存できるよ

めに，まず SMTP ルーティングコンテナ (Postfix mruby)うにする．SMTP の場合は，Milter プロトコルを介してプに配送される．このルーティングコンテナは，次に配送さロトコルのセッション処理に関わる情報を都度収集する．

れるべきドメイン単位での LMTP コンテナが数万個以上

IMAP の場合は，Milter プロトコルのような連携プロトコ

存在し，かつ，そのコンテナの構成情報は高頻度で更新さルがないため，IMAP サーバソフトウェアに個別にセッれる状況を想定して配置している．LMTP コンテナはセッ

ション情報を収集できる拡張機能を実装する．これらの拡ションに応じて起動するため，同時に数万個以上起動する

張機能はセッション情報の保存だけでなく，セッション

わけではない．
配送するメールアドレスのドメイン名に対応した LMTP

データに基いて流量制御を行える程度の柔軟性を持たせる．
収集したセッション情報は，送信，受信共にデータベー

コンテナを起動させるために，Postfix を mruby で拡張でス化することにより，送信と受信の関連性やセッション

きる Postfix-mruby*2 を利用し，SMTP ルーティングコン

情報の遷移などを非同期に解析できるようにする．今後，

テナ上でドメイン名から CMDB API を通じて配送すべき

ルールベースの解析から，統計処理によって分類を行うこコンテナ情報を動的に取得する Ruby スクリプトを実行すとにより，大量のセッション情報と流量に基づいて，大量る．その結果に基づいて，さらに配送すべき LMTP コン

送信や spam メールの振る舞い等を検知できないかについテナが収容されているホストサーバで，同様に起動してても検討していく．

いるローカル SMTP ルーティングコンテナに対してメー4. 実装の進捗
4.1 提案するメールシステムの受信フロー

ルを配送する．ローカル SMTP ルーティングコンテナはドメインに対応する LMTP コンテナの構成情報を CMDBAPI から取得し，該当コンテナが起動されていなければ

図 3 に提案するメールシステムの構成とメールのフロー

起動し，メールを配送してメールボックスに保存される．

を示す．外部からメールを受信した場合の本メールシス

メールボックス自体は NFS 上で共有されており，複数のテムのフローとその実装について説明する．まず，外部

LMTP コンテナ (Dovecot LMTP A user) や IMAP コンテ

MTA から配送されたメールは，ロードバランサ (LB) で受ナ (Dovecot mruby A user) で共有できるようにファイル

けた後，SMTP のゲートウェイコンテナ (Postfix+Pmilter

ベースの dot lock を利用する．

IN) に配送される．その際に，ゲートウェイコンテナは最外部 MUA からのメール参照時には，MUA が IMAP コ

低 1 つ以上のコンテナが起動している ResidentContainer

ンテナに IMAP セッションを接続した際に，CMDB API

であるため，3.3 節で述べたように，動的に配送先を決定

からドメインに対応するコンテナ構成情報を動的に取得することなく，システムのスケジューラによって決定されたコンテナにメールを配送する．また，FastContaier と

c 2018 Information Processing Society of Japan
⃝

*1
*2

https://github.com/matsumotory/pmilter
https://github.com/tmtm/postfix-mruby

5Vol.2018-IOT-40 No.17
2018/3/5

情報処理学会研究報告
IPSJ SIG Technical Report

し，IMAP コンテナに接続する．実装には，筆者が開発し習を使ってコンピュータが適応的に流量制御するための研ている ngx mruby[12]*3 に IMAP プロキシ機能を追加する究も行っていく．

方法を検討している．この実装によって，IMAP コンテナ

本研究は，提案するメールシステムの必要なソフトウェが起動していなければ，起動させてから IMAP セッション

アを実装し，NII クラウド上にシステムを構築して実証実接続をしたり，起動済みであれば起動処理を省略して接続験を行う予定である．

するといった処理が可能となる．

謝辞

本研究で使用したクラウド資源は，平成 29 年度

IMAP コマンド単位での制限や，セッションデータの

国立情報学研究所クラウド利活用実証実験において提供さ保存と取得のために，Dovecot を mruby で拡張できるプれた．また，本研究は，以下の研究助成を受けている．

ラグイン，dovecot-mruby-plugin*4 を開発した．dovecot-

松本亮介, 小田知央, 近藤宇智朗, 笠原義晃, 岡村耕二, 嶋

mruby-plugin は，IMAP コマンドの実行前後で Ruby ス

吉隆夫, 金子晃介, mruby を利用した軽量コンテナクラウ

クリプトをフックして実行することが可能である．また，ド基盤の研究開発を介した mruby の大規模・高負荷テス

IMAP セッション情報を Ruby のメソッドで取得し，外部ト, 2017 年度 Ruby Association 開発助成, 2017 年 10 月.

のデータベースに保存したり，データベースのデータに基いて Dovecot の振る舞いを拡張できる．

参考文献
[1]

4.2 提案するメールシステムの送信フロー
メールを送信する際には，4.1 節で述べた IMAP プロキ[2]シと同様に，ngx mruby に SMTP プロキシを実装し，ドメインに基いて動的にドメイン単位の SMTP コンテナに接続する．この場合も，FastContainer の特性により，SMTP
プロキシによってコンテナが起動されていなければ起動させてから処理を行う．
ドメイン単位での SMTP コンテナでは，pmilter と連

[3]
[4]
[5]

携して SMTP セッション情報を保存しておく．保存したセッション情報に基いてドメインやメールアカウント単位[6]での同時送信数を制御することにより流量制限を行う．ま[7]

た，IMAP セッションデータと SMTP セッションデータ
を組み合わせつつ，統計的な解析を行うことにより，異常[8]なセッション状態を検知できるようにする仕組みも検討中
である．

SMTP コンテナでメールを送信処理した後は，受信の[9]フローと同様にウィルスや spam メールのフィルタコン
テナを介して，メール送信ゲートウェイコンテナ (Post-[10]

fix+Pmilter OUT) に配送され，外部の MX サーバに送信

[11]

される．

5. まとめ[12]

本研究では，高集積マルチアカウント型のメール送受信システムを安定化するために，精緻にセッション情報を解[13]

析でき，適応的にメールの流量制御やリソース制御を行えるメール基盤の設計と本論文執筆時点での実装と検討項目の進捗を述べた．
今後，引き続き必要機能の実装を行いながら，メールの[14]

流量変化に想定通り耐えられるかの検証，リソース利用
効率の定量的評価などを進めていく．また，保存したセッ
ションデータを活用することにより，統計的手法や機械学*3*4

https://github.com/matsumotory/ngx mruby
https://github.com/matsumotory/dovecot-mruby-pluginc 2018 Information Processing Society of Japan⃝[15]

Costales, Bryan and Flynt, Marcia, Sendmail milters: a
guide for fighting spam, Addison-Wesley. 2005.
Darya Gudkova, Maria Vergelis, Nadezhda Demidova,
Tatyana Shcherbakova, Spam and phishing in 2016,
https://securelist.com/kaspersky-securitybulletin-spam-and-phishing-in-2016/77483/.
Dovecot: Secure IMAP server, https://www.dovecot.
org/.
Dent, K. D, Postfix: The Definitive Guide: A Secure andEasy-to-Use MTA for UNIX, O’Reilly Media, Inc., 2003.
Hiroya Ito, Yapc Asia 2009 ペ パ ボ で の Perl の使 い 方, https://www.slideshare.net/hiboma/yapcasia-2009-perl.
John Myers, RFC2033: Local mail transfer protocol, The
Internet Society, Oct 1996.
Nazario, José, Using xinetd, Linux Journal, Vol.2001,
No.83es, pp8, 2001.
Yoshiharu Tsuzaki, Ryosuke Matsumoto, Daisuke
Kotani, Shuichi Miyazaki, Yasuo Okabe, A Mail Transfer System Selectively Restricting a Huge Amoount ofE-mails, Workshop on Resilient Internet based Systems(REIS 2013), pp. 896-900, Dec. 2013.
Postfix Performance Tuning, http://www.postfix.
org/TUNING_README.html.
Rosen R, Resource Management: Linux Kernel Namespaces and cgroups, Haifux, May 2013.
近藤宇智朗，松本亮介，栗林健太郎, Haconiwa: プログラムによる，組み立て可能性と拡張性を持つ Linux コンテ
ナ, 情報処理学会第 80 回全国大会, 2D-04, 2018 年 3 月.
松本亮介, 岡部 寿男, mod mruby: スクリプト言語で高速かつ省メモリに拡張可能な Web サーバの機能拡張支援機構, 情報処理学会論文誌，Vol.55, No.11, pp.2451-2460,
Nov 2014.
松本亮介, 近藤宇智朗, 三宅悠介, 力武健次, 栗林健太郎,
FastContainer: 実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャ, インターネットと運用
技術シンポジウム 2017 論文集，No.2017，pp.89-97, 2017年 12 月.
松井一乃, 金高一, 加来麻友美, 池部実, 吉田和幸, milterの組合せによる低配送遅延を目指した spam 対策メール
サーバの設計と導入の効果について, 情報処理学会論文
誌, Vol.55, No.12, pp.2498-2510, 2014 年 12 月.
山井成良, 岡山聖彦, 中村素典, 清家巧, 漣一平, 河野圭太,
宮下卓也, SMTP セッションの強制切断による spam メー
ル対策, 情報処理学会論文誌, Vol.50, No.3. pp.940-949,
2009 年 3 月.

6