DEIM Forum 2016 B8-3

アーカイブ機能追加による RMX の拡張
金丸 恵美†

遠山元道 ††† 慶應義塾大学理工学部情報工学科 〒 223–8522 横浜市港北区日吉 3–14–1
E-mail: †maru@db.ics.keio.ac.jp, ††toyama@ics.keio.ac.jp
あらましRMX(Rule-based e-Mail eXchange system) とはあらかじめ設定された配送ルールと個人の情報が登録されたデータベースに基づき, 自動的にメールを転送するメール転送エージェントである. RMX の主な使用用途としてメーリングリストが考えられる. 配送機能に関しては既存のメーリングリストシステムと同等の能力を持つが, 配送以外に関してはアーカイブ機能が足りていない点がある. これを補いユーザーへのより便利なメーリングリスト運用を行うためには, 既存システムの導入が必要となる. しかし, 既存のシステムでは RMX で用いるメールアドレスの記述方法での運用に手間がかかる. このため, RMX に対応した独自のアーカイブシステムを構築する必要がある. よって,
本論文では RMX に対応したアーカイブシステムを作成し, メーリングリストとしての運用をより便利にした.
キーワード

電子メール, RMX, メーリングリスト, アーカイブ

1. は じ め に

2. RMXRMX (Rule-based e-Mail eXchange System) とは, メール

Rule-based e-Mail eXchange(RMX) は遠山研究室が提案しアドレスを始めとして個人の情報を登録したデータベースと,ている電子メールの配信方式である [1] [2] [3] [4] [5]. RMX では

あらかじめ設定した配送ルールに基づき, 自動的にメールを転メールアドレスを下記のように記述することによって, 複数の送するメール転送エージェントである. 従来のメールアドレス送信先を指定する. RMX ではアドレスの記述方法は関数形式

はアカウント名とドメイン名から構成される 2 次元的なものでと自然形式の 2 種類があり, これはそのうち関数形式の記述方あるのに対して, RMX では配送ルール, パラメータ, ドメイン式である.

名の 3 つから構成されている, 3 次元的なものである. これらの 3 種類の構成要素を組み合わせることによって, データベー< RM X のメール配信先指定 (関数形式) >:=スからアドレスの集合を得ることができ, 従来のメールと比べ,< 配送ルール名 > {< パラメータ >}@ < サブドメイン > . < ドメイ

広がりを持つ.

ン>

RMX の主な利用方法として, メーリングリストが考えられる. RMX を用いると, パラメータによって条件を満たした人にRMX はこのように, 配送範囲を記述するサブドメイン以前のみメールを配送するため, メーリングリストと同等の配送能の部分と, ドメイン移行が “.” によって組み合わされている. 配力を持つ. 一方, 配送以外の機能面に関しては, 既存のメーリン送範囲の中でも＠以後のサブドメインの部分は後述する設定

グリストシステムにはアーカイブやそれに伴うメールの検索なファイルの名前に相当する. また＠以前の部分は, “{}” の左側

どがあり, RMX ではこれらをサポートできていない. ユーザへに示される配送ルールと, その “{}” 中に記述されるパラメータのより便利なメーリングリスト運用のためにはこれらの機能をという 2 つの部分に区別される. その内, パラメータは 1 つ以サポートする必要があると考えた. この時, これらの機能を用上で構成される. サブドメインによって設定ファイル (後述) がいるために既存のシステムを用いて RMX を運用することが考選択され, 配送ルールの記述によって設定ファイル内のルールえられたが, 既存のシステムでの RMX を用いた運用には手間部分が参照される. その後パラメータを用いてデータベースにがかかる.

問い合わせを行い送信先のアドレスを取得する. 最終的に得らそこで, 本論文では RMX に組み込むことのできる独自のれたメールアドレスに基づき, 配送が行われる. (図 1)

アーカイブシステムを提案, 実装する.
本論文の構成は以下の通りである. まず, 2 章で RMX の概

以下, RMX の配送ルール (2.1), 複数の配送ルールの組み合要について述べる. 3 章では RMX の現状について, 4 章では提わせ (2.2), サブドメイン設定ファイル (2.3), 拡張プラグイン機

案するアーカイブシステムの概要ついて, 5 章では実際の使用

構 (2.4) について概説する.

例を述べ, 6 章では評価を行う. 最後に 7 章で結論を述べる.

2. 1 配送ルール
配送ルールとは, 配送範囲記述と, それに基づき送信先のメールアドレスを取得するクエリを関連付けるルールである. 配送詳細な配送範囲の指定を可能にする.

2. 2. 1 和 集 合Syntax: < name1 > {< par1 >} +... + < namen >{< parn >}@ < subdomain > . < domain >Semantics: name1 (par1 ) ∪ ... ∪ namen (parn )“+” を用いることで, 指定された複数の配送ルールの結果の和集合を取り, その和集合によって得られた結果に対して配送を行う. また, ルール間だけでなくパラメータ間でも和集合の
図 1 RMX におけるメール配信の流れ扱いとなる.
例：dept{business}+dept{law}@student.krmx.jp

ルールは 以下のように定義する.

dept{business+law}@student.krmx.jp

配送ルール名

上記の例では, 経済学部または法学部に所属している学生にType:パラメータの型メールを送信する.

query: 送信先メールアドレスを得るためのクエリ
query は SQL によって記述する. 配送ルール名に対応するク

2. 2. 2 積 集 合

エリにパラメータを挿入し, データベース問い合わせを行うこ

Syntax: < name1 > {< par1 >}. ... . < namen > {<とで送信先メールアドレスの集合を取得する. このような配送

parn >}@ < subdomain > . < domain >ルールを用いることで, ユーザは簡潔な記述で配送範囲を記述

Semantics: name1 (par1 ) ∩ ... ∩ namen (parn )することができる. 以下に配送ルールの定義の例を示す.

“.” を用いることで, 指定された複数の配送ルールの結果の積dept集合を取り, その積集合によって得られた結果に対して配送を

deptType= String

行う. パラメータ間で “.” を用いると, 次の節の多相と同じ扱

dept[1]= select s.address from student s where

いとなる.

s.dept = ’$1’ ;

例：dept{business}.grade{1}@student.krmx.jp
上記の例では, 経済学部に所属している 1 年の学生にメールを

上 記 の 例 は, 所 属 学 部 ご と に メ ー ル を 送 信 す る た め のdept ル ー ル で あ る.

所 属 学 部 を String 型 で 受 け 取 り, それ に 基 づ い て, メ ー ル の 送 信 を 行 う.

メールの宛先がdept{law}@student.krmx.jp の場合, 図 2 のように query の送信する.
また, 配送ルール間の積集合をとる “.” と和集合をとる “+”が同時に使用された場合, 積集合をとる “.” の方が優先順位が高いものとする.

部分で利用者のメールアドレスと所属学部が格納されているテーブル student を参照し, そこから, 学部が法学部の学生の,メールアドレスを取得するクエリを記述している.

例：name{mori}+grade{2}.club{soccer}@student.krmx.jp
上記のメールアドレスの場合, grade と club の積集合をとった後, その結果と name との和集合をとる. つまりこの例の場
合は, 学年が 2 年のサッカー部に所属する学生, または森という名前の学生にメールを送信するという結果になる.

2. 2. 3 多相 (ポリモルフィック)
Syntax: < name1 > {< par1 > −...− < parn >}@ <subdomain > . < domain >Semantics: name1 (par1 , ..., parn )図 2 dept ルールと配送例

2. 2 複数の配送ルールの組み合わせ (関数形式)
RMX では, 複数の配送ルールを組み合わせることが可能である. 複数の配送ルールを組み合わせてメールを送る際, RMXで使用可能な演算子について説明する. To フィールドの配送ルールに, 演算子を使用することによって, ユーザに対してより“-” は，ポリモルフィックな考え方を導入して, １つのルールに対して複数のパラメータを指定するための演算子である. また, パラメータ間に使用される “.” も同様の演算子である . “-”によって与えられたパラメータの数により配送ルールから呼び出すクエリが異なる．次の例ではルール grade に２つのパラメータ 1 と 3 を与えるため，2 引数の grade ルールを使用する．

例：grade{1-3}@student.krmx.jp
これによって 2 つの引数をもつクエリが実行される. 引数が2 つの grade ルールがメール配送機能から切り離された. この拡張プラグイン機構を利用することで, 新たに RMX 本体に機能を追加を行うことが可能である. 拡張プラグイン機能を利用するには, 所定の形式のアドレスを使用する. 形式を以下に示す.

grade
gradeType= integer
grade[2]= select s.address from student s wheres.grade >= $1 AND s.grade <= $2;となっていた場合, 先ほどのメールアドレスから学年が 1 年から, 3 年の学生にメールが送信される.

形式 : #<plugin>.<command>.<arg1 >.....<argn >#<targert><plugin> : プラグイン名<command> : 使用するコマンド名<arg> : コマンドで用いる引数<target> : RMX 形式のアドレス, またはドメインのみ

以上の３つの演算子は組み合わせて使用することもでき，ユーザが配送範囲を指定する際の手助けを行う．メールアドレ
スは以下の形式を取る．

3. 現状の RMX
RMX をメーリングリストとして活用するときの現状についListOpe := −て説明する.

U nionOpe := +RuleOpe := . | + | −Arg := string | integer

3. 1 メーリングリスト
現在, RMX の主な使用用途はメーリングリストとしてグルー

P ara := Arg | Arg ListOpe P ara

プ単位でのメール配送や, 任意の宛先に対してメールを配送すP araList := P ara | P ara U nionOpe P araList

ることが考えられる. 既存のメーリングリストシステムとの比Exp := rule { P araList }較を行った時, メール配送以外の機能に関してアーカイブ機能

ExpList := Exp | Exp RuleOpe ExpList

が足りていないことが挙げられる. ユーザへのより便利なメーAddress := ExpList @ subdomain . domain

リングリスト運用のために必要な機能だと考えられたため, 補うために既存システムを導入することを考える. この際, RMX

例：grade{1-3}.club{soccer}+name{suzuki}.

を用いた運用を行うと以下の問題が生じると考えられる.

club{baseball}@student.krmx.jp•
上記の例では, 1 年から 3 年のサッカー部に所属している学生

新規メーリングリスト登録の手間

新規メーリングリスト登録の手間とは, 従来メーリングリスと, 野球部に所属している鈴木という名前の学生にメールを送トとして運用するには特定のメーリングリストのアドレスを 1信する.

つ取得し, そのアドレスを使う. RMX では, 配送ルールの組み合わせにより自由にメーリングリストを作成することができる.

2. 3 サブドメイン設定ファイル

考えられるメーリングリストの個数はルールとパラメータの組

サブドメイン設定ファイルでは, データベースへの接続, 使み合わせにより大きく膨れ上がる. その多くをメーリングリス用するルールの設定を管理する. ファイル名をサブドメイントとして使用するとなると外部システムを用いた場合, その都名.properties とし, .properties の前をサブドメイン名として使度用いたいアドレスをメーリングリストのアドレスとして登録用する. 例えば, student.properties というファイルを作成し,する必要があり手間となる.

サブドメインが student となるメールアドレスを受信した場合,student.properties を参照し, 配送ルールを取得する. サブドメ•

イン設定ファイルでは以下の項目においてデータベース情報をRMX にはメンバーという概念がないため, 外部システムで設定する．

メンバーの概念

登録を求められる個別のアドレスを登録することができない.
よって実際使用するためには, RMX のアドレスを記述するこ•dbDriver = ＜データベースドライバ＞とになり, メーリングリストとしてのアドレスと個別のアドレ•

dbUrl = ＜接続するデータベースの URL ＞

スとで重複してしまう.

•dbId = ＜データベース上のユーザ ID ＞

•dbPassword = ＜ユーザ ID に対応するパスワード＞•RMX で用いる配送ルール

こうした現状を踏まえ, 本論文では, RMX に対応した独自のアーカイブシステムを提案し実装する. これにより既存のシステムを使うよりも容易に, かつ RMX でのメーリングリスト運2. 4 拡張プラグイン機構用が便利になると考えられる. さらに, アーカイブの設定方法

先行研究において, メール配送以外の機能を RMX 本体のも RMX に沿ったものとすることでより管理が容易にできるようにする.

4. アーカイブシステムの概要•multipara

ルール 1 つにパラメータを複数指定する場合

4. 1 アーキテクチャ

記述の型 : multipara = <rule>{<para>\\W<para>...<para>}

本論文での提案手法の概要を図 3 に示し, 細かい流れを以下<rule> : 配送ルールに示す.

<para> : パラメータ(任意のパラメータの際にはこのまま使用可)\\W : 演算子
(任意の演算子の際にはこのまま使用可)•rule

ルール単体を指定する場合記述の型 : rule = <rule>（ 2 ） <subdomain> <domain> detail.properties
アーカイブした際にメールに加える文章のテンプレートを指定する設定ファイル. 設定できる種類は subject と body の 2
図3

提案手法の概要つである.

（ 1 ） RMX 内でメールの情報を Archive.jar に渡す•（ 2 ） アーカイブシステム内でアーカイブ処理の対象判別

タイトル文頭に追加する文章

subject（ 3 ） アーカイブシステム内でアーカイブ処理（ 4 ） RMX 内でのメール処理•（ 5 ） アーカイブされたメールの確認

本文末尾に追加する文章

各項目についての詳細は後述.

設定するテンプレートに, 特定の文字列を記述することでメーbody

ルの通し番号や, メーリングリストアドレスを埋め込むことが4. 1. 1 アーカイブ処理の対象判別可能. 各文字列を以下に示す.

メール受信時, RMX からメールの情報が引数としてアーカ
イブシステムに渡される. その際, プロパティファイルを参照– 通し番号 = %cしアーカイブの対象であるか判断を行う.

– メールアドレス = %a

このためにあらかじめ, システム内にある 2 つのプロパティファイルに, アーカイブをするメールに関して設定をする. 1 つ目のファイルではアーカイブ処理を行うメールアドレス, 2 つこれらを文章中に記述しておくことで, アーカイブ時に実際の数値, 文字列が埋め込まれる.

目のファイルではアーカイブした際にメールに加える文章のテンプレートを設定する. それぞれの記述形式を以下に示す.

これらの設定をした上でメールが送信されると, アーカイブシステムがメールアドレスを解析し, 該当するプロパティファ（ 1 ） <subdomain> <domain>.properties

イルとの比較を行いアーカイブの有無を判別する.

<subdomain> : サブドメイン<domain> : ドメインの先頭部分

4. 1. 2 アーカイブ処理
アーカイブの判定が有りだった場合に, メインプロセスに入アーカイブするメールアドレスを記述する設定ファイル. 設
定には正規表現を用いて又は直接記述して指定する. 定義でき

りアーカイブの処理を行う. メインプロセスで行う処理を以下に示す.

るアーカイブの種類は 3 つである.

••rulepara

アーカイブ用フォルダの作成

アーカイブするメールアドレスのサブドメイン, ドメインや,ルールとパラメータをそれぞれ 1 つ指定する場合

アーカイブする種類をフォルダ名としてメーリングリストごと

記述の型 : rulepara = <rule>{<para>}のフォルダを作成する.

<rule> : 配送ルール<para> : パラメータ•

メールの情報をデータベースに格納-1

メーリングリストが使用された回数を記録するため, メールアドレスと回数を記録用データベースに登録. 回数の記録は, 新4. 1. 4 アーカイブメールの確認

規登録時には 1 とし, 既に登録がされている場合には値の更新

アーカイブされたメールを確認する方法は, アーカイブフォを行う. 記録用データベースのスキーマを以下に示す.

ルダを参照する方法と, RMX のプラグイン機構を用いる方法との 2 種類.

archive count(id, subdomain, domain, type ,address, count)– id : 主キーとしての id•アーカイブフォルダ

アーカイブ初回時に作成されたフォルダ内にある, 個別メー– subdomain : サブドメイン

ルのファイルを参照する. しかしこの方法では, 限られた人し– domain : ドメインの先頭部分か利用できない可能性がある.

– type : rulepara, multipara, rule のいずれか– address : メールアドレスの@以前– count : アーカイブ回数•RMX におけるプラグイン機構プラグイン機構を利用し,閲覧したいアーカイブメールの情報を取得, 閲覧する. その際に用いるプラグインは 3 種類で, 以下に示す.

•プロパティファイルをもとにメール編集

2 つ目のプロパティファイルを参照し, メールのタイトル, 本（ 1 ） #archive.list#文への追加文章を生成. 設定した文章中に回数を意味する文字

アーカイブがされているメールアドレスのリストを返す.

列が存在する場合には, データベースから回数を取得し埋め込（ 2 ） #archive.list.<引数 1>#
引数 1 を id にもつメーリングリストアドレスのメール一覧

む.

を返す.

•

メールの情報をデータベースに格納-2

タイトル, 本文への追加情報を加えたメールの詳細情報を詳細用データベースに登録する. 詳細用データベースのスキーマ（ 3 ） #archive.list.<引数 1>.<引数 2>#
引数 1 を id にもつメーリングリストアドレスのメールのなかで, 引数 2 を id に持つメールの詳細浄業を返す.

を以下に示す.

3 つのプラグインを順に用いれば特定のメール情報を取得すarchive detail(id, list id, sender, subject ,body, date)

ることができるが, この方法には手間がかかり, またメール検索ができないためユーザは限られた情報から自分が得たいメール– id : 主キーとしての idを特定しなければならない. よってユーザへのより良いメール– list id : 回数用テーブルの id

情報取得を支援するために Web アプリを作成した.

– sender : 送信者アドレス– subject : メールタイトル– body : メール本文– date : 送信日時•

作成フォルダにメールのテキストを出力最初に作成したアーカイブ用フォルダ中に, メーリングリス•Web アプリ

上記 2 つの閲覧方法では足りない機能を補う. この Web ア
プリで行える機能を以下に示す.

– メール検索– メールのダウンロード

トの回数をタイトルとしてメールの詳細情報をテキストファイル形式で出力, 蓄積する.

•実行結果を返す

実際のメール生成を行う RMX 内のプログラムに, アーカイブシステムで編集したメールタイトル, 本文を返り値として渡5. アーカイブシステムの実装
5. 1 プロパティファイルの記述例
プロパティファイルの設定例を挙げる. 例に用いるサンプル
テーブルを図 4, 図 5 に示す.

す. 配送ルールが組み合わせられていて複数のアーカイブに該当する場合は, 該当するアーカイブごとに実行結果を返す.

4. 1. 3 RMX 内でのメール処理
アーカイブシステムから返される値を元に、送信メールのタイトル, 本文の編集を行う. 複数のアーカイブに該当している
場合は返り値がその分だけ存在する. 返り値がない場合には通常通りのメール作成を行う.

図 4 サンプルテーブル

ルとなっているため, ユーザーが求めるメールがどれなのかがすぐにわからず 1 件 1 件ファイルをチェックする必要がある.
よってユーザーを支援する要素を増やす必要がある.

•図5•サンプルテーブル 2

アーカイブ設定プロパティー

例 1 : dept が law の人へのメール

rulepara = dept{law}
例 2 : dept が law と business の人へのメール

multipara = dept{law+business}

プラグイン機構を用いる（ 1 ） メールアドレスのリストを取得する
プラグイン#archive.list#を用いて, アーカイブされているメールアドレスのリストを取得する.
使用例 : #archive.list#@student.krmx.jp（ 2 ） メール一覧を取得するプラグイン#archive.list.<引数1>#を用いて, メールアドレス id が 2 であるメールアドレスのメールリストを取得する.

例 2’ : dept が law とそれ以外の学部の人へのメール

使用例 : #archive.list.2#@student.krmx.jp

multipara = dept{law+<para>}（ 3 ） メールアドレス id が 2 であり、メール id が 5 である
例 2” : dept に law とそれ以外の学部が含まれているメール

multipara = dept{law\\W<para>}

メールの内容を取得するプラグイン#archive.list.<引数 1>.<引数 2>#を用いて, メールのリストを取得する.
使用例 : #archive.list.2.5#@student.krmx.jp

例 3 : dept 単位でのメール

rule = dept•

Web アプリ Web アプリを用いたアーカイブメール閲覧の例を図 7, 8 に示す.

•文章テンプレート設定プロパティー

例 1 : dept{law} に対しメールを送信する
タイトルの記述例 : [No.%c]
実際の表示 : [No.5] <タイトル>
例 2 : dept{law}+grade{2} に対しメールを送信する(該当アーカイブが複数)タイトルの記述例 : [%c mail]
実際の表示 : [5 mail][3 mail] <タイトル>

5. 2 アーカイブメールの確認例
•

図7

メール一覧

アーカイブフォルダから読む

生成したアーカイブフォルダ中にあるメール毎のテキストファイルを読む方法. 生成されたメールのテキストファイルの様子を以下の図 6 に示す.

図 8 メール検索例

図 6 アーカイブされたメール毎のファイル

6. 評

価

6. 1 外部システムとの比較
ただし現時点ではメールの番号がテキストファイルのタイト

本論文で提案するアーカイブシステムによる RMX のメーリ

ングリスト運用の向上を評価するため, 既存のメーリングリス•トシステムとの比較を行う [6] [7] [8]. 比較対象とした既存のシメーリングリストの管理者が行える操作.

ステムは以下の 3 つ.

既存システムでは, ユーザ使用するためだけでなく管理者がWeb 操作 (管理者)•Mailmanメーリングリストの設定を行うことができるようになっている.

•fml

今回の実装では, ユーザへの利便性に対しての設計となったた•

Majordomo

め本システムでは管理者に対しての実装ができていない. この

評価項目として, メール配送以外の機能を主に取り上げた. 各
項目と評価結果を以下の表 1 にまとめた.

アーカイブシステム内にある設定ファイルを直接編集する必要がある. このままでは, ファイルの編集ミスや予期せぬエラー

表 1 既存システムとの比較
項目

Mailman

ML 配信◯

fml

ため, 現在管理者がメーリングリストの設定管理を行うには,Majordomo 本システムが起こる可能性があるため, より安全に管理を行うための管理者に向けたツールの開発が必要だと感じた.

配信機能
◯◯◯

メール (コマンド) 操作•

その他

既存システムでは全て, RMX のメールアドレスに含まれるメール一覧取得

××◯◯

記号を使用することができない. この点では本システムの有用

メール記事取得

×◯◯◯

性が高い.

Web 操作 (ユーザ)メンバー管理の項目で本システムに×がついているが, これメール一覧, 検索

△×

◯

◯

はメーリングリストメンバーの管理が本システム上で行うこと

メール記事取得◯×◯◯ではなく, 管理者がデータベースの値を更新することで行われることより, 本システム上での機能として実装していないといWeb 操作 (管理者)
各設定事項

◯◯

△×

導入の複雑さでは, 既存システムでは全て公開されているパッ

その他
記号の使用

×××◯

メンバー管理◯◯◯×

導入の複雑さ

•

大きい

大きい

大きい

小さい

ケージをインストールし, 各種環境設定を行う必要がある. 一方で本システムは, RMX 本体に組み込まれているため, RMX を導入しコードを少量書き換えるだけで使用が可能となる. また,既に RMX を用いている場合への組み込みもコードとプログラムを配置するだけで良い. よって複雑さが小さいと考えられる.

配信機能

従来の RMX でも可能であり, 既存システムと同等の機能.

•うことである.

6. 2 今後の課題比較結果より, 本システムの導入からメーリングリストとしメール (コマンド) 操作ての配送以外の機能について, ほぼ既存システムと同等の機能メーリングリストへの操作をメールの送信により行う機能.

を持つようになった. 今後の改善点として, 先ほどあげた管理比較した既存システム全てにおいてメール操作が可能. その者に対する支援ツールの開発があげられる. また, 既存システ中で行える操作の種類について比較を行うと, Mailman では

ムが持つ, 比較評価とした項目以外の機能についても順次実装

メーリングリストへの参加, 退会, メール配信の開始/停止などし, さらに既存システムとの差異を減らしていくことが必要には行えたが, メール一覧, 記事の取得は行えなかった. 一方, fmlなると感じた.

でも同じく参加, 退会ができる他, get コマンドによる記事の指定取得が可能であった. しかし, 記事一覧の取得は行えなかった. Majordomo, 本システムでは一覧, 記事取得が行えた.

•本研究では RMX にアーカイブ機能を組み込むことで, 既存Web 操作 (ユーザ)メーリングリストのメンバーが行える操作.

fml には, メーリングリストメンバーが使える CGI がなく,メールの記事取得はコマンド操作から行う. Mailman には CGIがあり, メールを zip 形式でダウンロードすることが可能. ただし記事の検索はできない. Majordomo にも CGI があった. 本システムでもこれらの操作が行えるような Web アプリを用意した.

7. お わ り にのメーリングリストシステムを導入する必要をなくし, RMXのメーリングリストとしての運用をより便利に. また, 既存のアーカイブシステムとの比較を行うことで, 独自アーカイブシステムの有用性を示した.

文

献[1] 高畑理, 藤沼健太郎, 石橋玲, 遠山元道. “Magic Mirror Mailing：
個人情報データベースを利用する柔軟なメイル配送システム”,
情報処理学会データベースシステム研究報告 pp123-128 July
2001[2] Kim Hanki, Sang-Gyu Shin, Motomichi Toyama. “A RuleBased Mailing System for an Organization”, International
Workshop on INformation Processing over Evolving Networks, IEEE, June 2006
[3] 青山陽亮, 遠山元道. “RMX におけるポリモルフィックルールとメール本文編集機能の導入”, DEIM2010 IEICE, 2010
[4] 北囿達也, 青山陽亮, 遠山元道. “RMX における関数形式アドレスおよびデバッグ支援機能の実装”, DEIM2011 IEICE, 2011[5] 松本 洋平, 北 和人, 遠山 元道. “RMX における拡張プラグイン機構の導入及び各種プラグインの開発”, DEIM2014, 2014[6] Mailman. http://docs.python.jp/contrib/mailman/[7] fml. http://www.fml.org/[8] Majordomo. http://www.greatcircle.com/majordomo/