%#!pLaTeX
\documentclass[twocolumn,a4j,10pt]{jarticle}
\usepackage{graphicx}
\usepackage{alltt}
\usepackage{ascmac}
\usepackage{multicol}	% required for `\multicols' (yatex added)
%\documentstyle[a4j,twocolumn]{jarticle}
\title{spam対策に特化したSMTP wrapperの実装と検証}
\author{\shortstack{広瀬雄二\\yuuji@koeki-u.ac.jp}~ ~ ~ ~ 
\shortstack{大駒誠一\\okoma@ae.keio.ac.jp}\\
東北公益文科大学}
\date {2004年9月24日}
\setlength{\textwidth}{16cm}		% A4幅約21cmから両マージン5cm減算
\setlength{\oddsidemargin}{0cm}		% 紙端1インチからのマージン
\setlength{\evensidemargin}{0cm}	% 紙端2.5cm要求なので0cmでOK
\setlength{\topmargin}{-1cm}		% 紙上端1インチからのマージン
%\setlength{\itemsep}{-40pt}
%\setlength{\textheight}{22.7cm}
\newcommand{\keyboard}[1]{{\sf #1}}
\newcommand{\filename}[1]{{\tt #1}}
\setlength{\itemsep}{0.5ex}
\renewcommand{\baselinestretch}{0.96}
\begin{document}
%\onecolumn
\twocolumn[\maketitle

% \begin{abstract}
 \input{jabst.txt}
% \end{abstract}


 \begin{center}
 {\Large Implementation and Verification of\\
  SMTP Wrapper for Spam Rejection \\ 
 }
 \ \\
 \ \\
 {\large \shortstack{HIROSE Yuuji\\yuuji@koeki-u.ac.jp}~ ~ ~ 
	\shortstack{OKOMA Seiichi\\okoma@ae.keio.ac.jp}\\
 \ \\
 Tohoku University of Community Service and Science
 }
 \end{center}

 \renewcommand{\abstractname}{\textbf{Abstract}}
% \begin{abstract}
 \input{eabst.txt}
% \end{abstract}
	\vspace*{2em}
]

%次ページ
\twocolumn
 
 \section{背景}

	電子メイルがゴミまみれになって久しい．UBE (Unsolicited Bulk
	Email)，いわゆるspamはもはや社会問題に発展している．メイルサーバ
	レベル，あるいはメイル受信者レベルにおいて，受け取ったメッセージ
	の本文をフィルタプログラムに通し，「クロ」つまり受け取りたくない
	ものであると判定されたものを除外したりすることも一般的になってい
	る．このような，本文を走査する「コンテンツフィルタ」は統計学的手
	法を用いることで高い認識成功率が得られるようになってきた．そのいっ
	ぽう，その機能が高度であればあるほど，メッセージ1通に対する計算
	機負荷は高くなる．全体のメイルに対するspamの割合が過半数を超えた
	とも言われる中，将来的にspamフィルタを動かす負荷は全世界のサーバ
	の資源を圧迫して行くことは想像に難くない．

	また，コンテンツフィルタでは，MTA的に見ていったんメッセージ全体
	を受け取ってSMTP接続を終了してしまうため，送られたものがspamと分
	かってももはや送信者にそのことを伝える術がない\footnote{ほとんど
	のspamはFROMアドレスが詐称されているのでメッセージのヘッダにある
	差し出し人情報は信用できない．Receivedヘッダには送信したホストの
	IPアドレスが記されているが，そのホストがSMTP接続を受ける保証はな
	い．}．このことは，ウィルスを排除するメイルスキャナにも当てはま
	る．とくにメイルスキャナでは，ウィルスを発見するとそのメッセージ
	ヘッダに書かれた差出人アドレスを信用してそこにバウンスを返すもの
	が多い．もちろんそれは詐称されたものがほとんどなので，身に覚えの
	ないエラーを送られた側は迷惑であるし，それが存在しないアドレスな
	らダブルバウンスを生み，ネットワーク負荷を無駄に浪費することにつ
	ながる．

	以上のことから，電子メイル送受信時に関して，
	\begin{itemize}
	 \item SMTPセッション時にspamと分かるならその場で直ちにエラーを
	       返すべき
	 \item 一度受信を完了したら下手にバウンスを返してはならない
	\end{itemize}
	という事が重要であると言える．

	そこで本稿では，SMTPセッション時に可能な限りspamを排除して直ちに
	エラーを返す手法を提案し，ならびにその機能をMTAの種類を問わずに
	導入するのに有効な SMTP wrapper の `antibadmail' を実装し実運用
	環境に適用した結果を報告する．

 \section{SMTPセッションフィルタ}

  \subsection{古来のセッションフィルタ}
	spamが問題化し始めた1990年代後半には，第三者不正中継 を許可する
	設定(Open Relay)に陥っているメイルサーバを介してspamがばらまかれ
	た．そのため，Open Relay になっているメイルサーバのIPアドレスを
	全世界的に集めてそこに登録されたIPアドレスからの受信を拒否するよ
	うな動きが見られた．現在でもそうしたデータベースは数多く公開され
	ていて，MAPS\cite{maps}やSORBS\cite{sorbs}などはその代表的なもの
	である．しかし，それらは運営されている国(主に欧米)の価値基準によっ
	てデータの登録が行なわれているため，アジア圏のIPアドレスブロック
	が無用に大きなレンジで登録されることもあり，日本のメイルサーバ管
	理者が使うには不都合が多い．実際，筆者の契約しているプロバイダの
	固定アドレスブロックもSORBSの「動的割り当てアドレスデータベース」
	に登録されているので，送信に支障を来たしている事実がある．

	国民同士の交流のあまり無い国どうしならともかく，日本人にとってア
	ジア圏のIPアドレスが簡単に登録されるデータベースは利用しづらい．
	日本人の利用するメイルサーバであれば，日本人の判断基準で作成され
	るデータベースの方が望ましい．一般化すれば，当該国の地理交流特性
	を加味したデータベースをその国の人間が管理するものであるのが望ま
	しい．

  \subsection{求められるセッションフィルタ}

	クライアントからのSMTP接続時には，最低でもサーバ側に以下の3パラ
	メータが送られる\cite{RFC 2821}．
	\begin{itemize}
	 \item HELO(EHLO) \\クライアントの識別名．通常クライアントのFQDN
		    だが必須ではない
	 \item MAIL FROM \\実際の送信者のメイルアドレス\footnotemark[2]
	 \item RCPT TO \\実際の受信者のメイルアドレス\footnotemark
	\end{itemize}
	\footnotetext{メッセージの本体に現れる From: ヘッダ，To: ヘッダ
	とは異なり，転送された場合などの最終的な宛先を示すSMTPのパラメー
	タである．}
	これらに加えて，サーバ側では，接続してきたクライアントの
	\begin{itemize}
	 \item IPアドレス
	 \item そのIPアドレスの逆引き(PTR)レコード
	\end{itemize}
	も送信側に関する情報として利用できる．これらのうちRCPT TO以外の
	情報は送信者側の身元，あるいはその一部を示す値であるから，spam送
	信者は{\bfseries 隠したり偽造したりしたがる}傾向がある\footnote
	{悪事を働くのに正しい身分証明書を見せる可能性が低いのと同様．}．
	この性質を利用すると，SMTPセッションの本文を受け取る前の段階で多
	くのspamが拒否できることが予想される．

	この予想に基づき筆者は2002年12月から qmail\cite{qmail}のSMTPデー
	モンプログラム(\filename{qmail-smtpd.c})にパッチを当てる形で上記
	の5要素をもとにメッセージの受信/拒否を決定するシステムを構築・改
	良してきた．また，それを運用しその有効性を確認することができた
	(qmpatch\cite{qmpatch, anti-badmail-akita})．今回は，qmailだけで
	なくSMTPデーモンの外側に被せる形で，qmpatchと同等以上のspam拒否
	機能を持つ SMTP wrapper ``antibadmail'' を新規に実装し，qmail以
	外の全てのMTAでも統一的なspam拒否が可能となることを目指した．

 \section{システム構成}
 \label{system}

	本研究で構築したMTAをとりまくシステム構成を図\ref{abm}に示す．
	\begin{figure}[btp]
	 \begin{center}
	  \includegraphics[scale=0.6]{system.eps} 
	 \end{center}	 
\caption{antibadmailシステム構成}
	 \label{abm}
	\end{figure}
	外部からのSMTP接続をいったん
	tcpserver\footnote{UCSPI-TCP\cite{DJB 1986}に含まれるTCP接続専用
	のスーパーデーモン．アクセス制御やデーモンプロセス起動時の環境変
	数設定機能を持つ．}で受け，クライアントのアドレスに応じた環境変
	数を設定した上でantibadmailに制御を渡す．antibadmailは，SMTPクラ
	イアントとのチャネル，Local MTAとのチャネル両方を開いたまま，ク
	ライアントからのリクエストをMTAに送り，それに対するMTAからの応答
	コードをクライアントに返す．このとき，antibadmail はtcpserverか
	ら与えられたクライアントアドレスに関する情報と，SMTPの3パラメー
	タ HELO(EHLO), MAIL FROM, RCPT TO に着目し，以下の基準でクライア
	ントからのメッセージ送信を許可するか拒否するか決定する．

	\begin{enumerate}
	 \item tcpserverのルールデータベースにより「ブラックリスト」のマー
	       ク(環境変数BADHOST)が設定されているか
	 \item DNSの逆引きレコードが偽造になっているか
	 \item HELO で指定された文字列が
	       \label{helo}
	       \begin{enumerate}
		\item HELO文字列ブラックリスト(badhelo)中の特定のパター
		      ンにマッチするか
	
		      (``yahoo.com'', ``hotmail.com'' をHELO文字列に指定
		      するものはspamである)
		      \label{helo-hotmail}

		\item ドットを含むFQDNらしき文字列になっているか
	
		      (``pc123''など個人PCに適当につけた名前からのものは
		      ウィルスの可能性が高い)
		\item IPアドレスの場合，
		      \begin{itemize}
		       \item knownホスト\footnote{正しくPTRレコードが登録さ
			     れているホスト}であれば，実際のIPアドレスと
			     一致するか
		       \item unknownホスト\footnote{PTRレコードが未定義
			     またはAレコードと一致しない不正な名前が登録
			     されているIPアドレスであるホスト}であれば常
			     に不許可
		      \end{itemize}
		\item 受信サーバのIPアドレスやFQDN，メイルドメインになっ
		      ているか\\
		      (HELOで相手のアドレスを指定するのは不正な
		      クライアント)
		\item 受信者(RCPT TO)アドレスと一部または全体がマッチす
		      るか
		\item 虚偽に使われやすくなおかつ交流の可能性の低い国別トッ
		      プレベルドメインを名乗っているか(unknownホスト
		      にのみ適用)
		\item HELOで名乗ったホストが実在するドメインか(unknownホ
		      ストにのみ適用)
	       \end{enumerate}
	 \item MAIL FROM が特定の送信者ブラックリスト(badmailfrom)
	       に含まれるパターンにマッチするか
	       \label{badmailfrom}
	 \item MAIL FROM がドメイン部(@記号以降)を含む正しい形式か
	 \item MAIL FROM のドメイン部が実在するドメイン名か
	       \label{mfcheck}
	 \item RCPT TO が宛先ブラックリスト(badrcptto)に含ま
	       れるパターンにマッチするか\label{badrcptto}
	\end{enumerate}
 %	ここでいう{\bfseries ブラックリスト}とは，SPAMを頻繁に送って来た
 %	実績のあるホストや送信者アドレス(群)などをあらかじめ登録したリス
 %	トである．それとは逆に信頼できるホストを登録したものを{\bfseries 
 %	ホワイトリスト}という．

	上記\ref{helo-hotmail}および，\ref{badmailfrom}には
	\filename{hotmail.com}などの詐称されやすい著名なドメインも含め
	ることになる．ただし，そのままでは本当に\filename{hotmail.com}の
	サーバから送られた正しい \filename{@hotmail.com}ドメインのメイル
	が届かなくなるため，正しい逆引き名が\filename{*.hotmail.com}とな
	るサーバからは\filename{@hotmail.com}をMAIL FROMにもつメイルは受
	信するようにする．これは，tcpserverのルールファイルで
	GOODMAILFROM変数を以下のように設定することで効果が得られる(実際
	には1行で記述)．
	\begin{quote}
\begin{alltt}
=.hotmail.com:allow,
GOODMAILFROM="@hotmail.com"
\end{alltt}
	\end{quote}
	HELO文字列に関しても，本物のサーバに対してだけ許可するための変数 
	GOODHELO を設定することで同様の効果が得られる．

	特殊なケースとして，利用者のうち誰かが以前利用していたメイルアド
	レスを，現在利用しているアドレスに転送するような場合がある．この
	とき以前利用していたサーバで十分なspam対策を施していない場合，数
	多くのspamが転送されて届くことになる．かといって，転送元の組織に
	あるメイルサーバを「IPアドレスのブラックリスト」に追加するわけに
	はいかない．そこで，典型的な転送元メイルサーバに関して，「転送を
	受理する送信者メイルアドレス(のワイルドカード)」を指定できるよう
	にした(PASSONLY変数)．

	以上の検査を経て，antibadmail が「クロ」と判定したものに関しては，
	MTAに本文(DATA)を渡す前に，クライアントにSMTP応答コード
	5xx\footnote{恒久的エラーを意味する．つまり，受信しない．}を返し
	受信拒否する．このとき，MTAにはQUITを送信してセッションを終了す
	る．

	その他，「spamでも何でもいいから全て受け取りたい」というケースも
	あるため，特定の宛先アドレスにはフィルタなしで全て通過させること
	もできる．さらに，信頼できる別のサーバから転送されて来たメイルの
	経路(Receivedヘッダ)による拒否判定を目的として，メッセージのヘッ
	ダ部分を先に吟味してからMTAに受け渡すかどうかを決定することも可
	能であるが，本稿の主眼から外れるためここでは触れない．

 \section{ブラックリストの構築}

  \subsection{構築時のポリシー}
	本来電子メイルは，国境を超え全ての人とやりとりできる可能性を持つ
	ものである．しかしそれは性善説が全域に通用した時代のことで現在は
	異なる．本研究でとりあげている運用環境では，以下のポリシーにより
	ブラックリストを登録している．

	\begin{enumerate}
	 \item 著名なメイルサービス(とくに無料のもの)のドメイン部は詐称
	       されたものがほとんどなので badmailfrom データベースに登録
	       すると同時に，本物のサーバから受け取れるようにtcpserverの
	       データベースにGOODMAILFROM変数を登録する
	 \item 通過したspamを送って来たホストを調べ
	       \begin{itemize}
		\item 自サイト利用者の交友が無さそうな国のISPなら
		      アドレスブロック全て
		\item 交友がありそうな国(主に日本)なら，動的割り当てブロッ
		      クのみを一時的に(適宜判断)
	       \end{itemize}
	       それぞれブラックリスト(BADHOST)に登録
	 \item 既存の badhelo/badmailfrom データベースに一致するパラメー
	       タを送って来たものは「前科者」として，以降の送信を拒否す
	       るようにtcpserverのルールデータベースのBADHOSTとして自動
	       登録する．
	\end{enumerate}

	本稿の運用環境のブラックリストは，qmailにいくつかのspam拒否パッ
	チを当てて運用し始めた2000年頃からの蓄積物である．作成開始時から
	qmpatch導入後しばらくまでの間は，典型的な詐称アドレスや異常HELO 
	の登録作業が大半を占めたが，それらの多くが拒否できるようになった
	のちは，大量発信の拠点となるBADHOST を登録する作業が大半を占める
	ようになった．

	筆者らの構築するブラックリストは「国内のプロバイダのアドレスは慎
	重に，国外のものは大胆に」というポリシーで登録が行なわれている．
	第三者となるサイトの管理者がこれを利用する場合，そのサイトの利用
	者にとって身近な国外ドメインが含まれてしまう危険性もあるが，その
	場合でもtcpserverのルールデータベースにそのドメインを信頼する変
	数定義を付加することで簡単に回避できる．

  \subsection{データベースの構成}

	IPアドレスに基づくブラックリストデータベースはtcpserver用のルー
	ルファイルとして登録する．いっぽう，SMTPの3パラメータと照合する
	ブラックリストデータベースは「datadir形式」で登録する．datadir形
	式とは，そのエントリ名がUnixファイルシステムの1ファイルとして存
	在する形式である．たとえば，MAIL FROM アドレスとして 
	\verb|foo@bar.baz, *@foo.bar, *@*.foo.bar| (\verb|*|は任意の文字
	列)を拒否したいときは，所定のディレクトリにそれぞれ
	\begin{quote}
\begin{alltt}
foo@bar.baz
@foo.bar
.foo.bar
\end{alltt}
	\end{quote}
	という名前の空ファイルを作成する．1つのエントリの追加と削除が，
	他のエントリの存在性に影響しないためantibadmail走行中に更新作業
	を行なっても良い．

	実運用環境では，複数管理者によるデータベースの共有を効率化するた
	め，1行1エントリで記述したテキストファイルをCVSのレポジトリに入
	れて管理している．そしてテキストファイルをdatadir形式に変換する
	ユーティリティを利用してantibadmailに与えている．

	

 \section{適用結果}

	2004年8月17日から21日の5日間，筆者が運営するサイト(利用者38名)で
	主メイルサーバに外部から届いたメイルを受信許可/拒否した結果を表
	\ref{result}に示す．
	\begin{table}[tb]
	 \caption{受信許可/拒否の実数}
	 \label{result}
	 \begin{center}
 	 \begin{tabular}{|c|c|c|}
	  \hline
	  接続総数	& 受信許可	& 受信拒否\\ \hline
	  8635		& 3498(40.5\%)	& 5137(59.5\%) \\\hline
	 \end{tabular}
	 \end{center}
	\end{table}
	また受信拒否したものについて，それらがどのような根拠により拒否さ
	れたかの概要を表\ref{reason}に示す．ただし
%	HELO(S) HELO_noDOT HELO=wildcard HELO_unknownIP,
%	HELO_IPnomatch, HELO_ngTLD, HELO_unknownbad, HELO_DNS_SOFT,
%	HELO_nxDOMAIN
%	
	\begin{table}[tbp]
	 \begin{center}
	  \caption{受信拒否根拠}\label{reason}
	  \begin{tabular}{|c|l|r|}
	   \hline
	   \multicolumn{2}{|l}{MAILFROM による拒否} & 2142 \\ \hline
	   内 & 存在しないドメイン & 228 \\ \cline{2-3} %MAILFROM_nx
	      & 不正な文字を使用 & 224\\ \cline{2-3} %UNSAFE
	   訳 & badmailfrom にマッチ& 1710\\\hline\hline
		% egrep 'MAILFROM(\(S|_[@.])'
	   \multicolumn{2}{|l}{RCPT TOによる拒否} & 1546\\ \hline
	   内   & 存在しないユーザ & 1055\\\cline{2-3} % RCPTTO_NONEXIST
	   訳   & badrcpttoにマッチ& 491\\\hline\hline % -v RCPTTO_NONEXIST
	   \multicolumn{2}{|l}{HELOによる拒否} & 1866\\ \hline
	      & badheloにマッチ& 1110\\\cline{2-3}  %HELO(S) + HELO/
	   内 & 上記以外のドットなし	& 145\\\cline{2-3} %HELO_noDOT
	      & 相手のドメインと一致	& 585\\\cline{2-3} %HELO=RCPT
	      & unknownホストからのbadhelo& 147 \\\cline{2-3}
			% HELO_unknownbad
	   訳 & 不在ドメイン(unknownホスト)& 71 \\\cline{2-3}
	   		% HELO_nx|HELO_DNS
	      & その他不正なHELO & 11 \\ \hline \hline %HELO_IP+HELO_ngTLD
	  \multicolumn{2}{|l}{IPアドレスに基づく拒否(BADHOST)} & 1552\\ \hline
	  \end{tabular}
	 \end{center}	
	\end{table}
	%\footnotetext{Top Level Domain: DNSのドット区切りの最も右側に来
	%るドメイン部．``.com'' など．}
	1通の拒否事例が複数の拒否根拠を持つことが多数あるため，各項目の
	合計が全体の拒否総数とは一致しない．

  \subsection{第一種の誤り}

	ブラックリストに登録してあるものは，利用者にとって受け取っても価
	値のないものとの実績を持つものであるので，ブラックリストにマッチ
	した拒否事例は捨てられるべくして捨てられたものといえる(静的根拠)．
	いっぽう，IPアドレスやDNS登録状況に基づく拒否は動的に決まるもの
	であるため，その中には本来拒否すべきでないものが含まれる可能性が
	ある．これについて動的根拠のみに基づく拒否事例を全数調査したとこ
	ろ5件あった．ただし，そのうち受け取るべきものであろうと推測でき
	るものは{\bfseries 2件}であった\footnote{通常spamは送信者アドレ
	スがランダム文字列であったりするので中味を見ずともホワイトリスト
	に登録すべきかどうかの判断は容易に下せることがほとんどである．}．
	これらはホワイトリストに登録することで以後の受信が可能となる．

  \subsection{第二種の誤り}

	spamであるにもかかわらず通り抜けて受信してしまったものについて，
	全利用者の協力を得てその件数を調査したところ，47件の報告が得られ
	た．報告もれも考慮する必要があるが，これらが受け取ったものの総数
	に近いと仮定すると，試験期間内に拒否した5137通と合わせて，
	\begin{eqnarray*}
	 \frac{5137}{5137+47} \cong 0.99
	\end{eqnarray*}
	約99\%のspamが拒否できたことになる．たとえこの成功率が幾分落ちた
	としても，すり抜けた先で高度なコンテンツフィルタを稼動させるため
	の負荷を軽減できる有効性は失われない．

 \section{結論}
 \renewcommand{\thepage}{\arabic{page}-E}

	SMTP接続クライアントの，IPアドレス，そのDNS登録状況，ならびに
	SMTPセッションパラメータを検査することでほとんど(約99\%)のspamを
	撃退することが可能だと確認できた．この手法がspam撃退に効果的であ
	る反面，現状では悪意のないサーバが，信頼できない不適切な設定になっ
	ていてこれを拒否してしまう可能性が残る．全ての(善意の)メイルサー
	バ管理者が正しい設定に修正し，なおかつSMTPレベルでの拒否機能を導
	入することでspam送信者側の効率を著しく落とすことが期待できる．

	また，今回実装した antibadmail の成果より，Sendmail, Postfix,
	qmail など，MTAに依らず統一的な手法を用いたSMTPセッションでの
	spam拒否が実現できることと，その有効性が確認できた．現状ではMTA
	ごとに異なるspam対策技法が追加実装され，その種ごとに違う設定法が
	要求されている．本稿での手法はSMTPセッションでのspam拒否手法を任
	意にカスタマイズできるフレームワークとして全てのメイルサーバに有
	効な切り口といえる．

 \begin{thebibliography}{2001}
 \bibitem{qmail}
	 D. J. Bernstein;
	 qmail; \\
	 \verb|http://cr.yp.to/qmail.html|

 \bibitem{RFC 2821}
	 Network Working Group, J. Klensin, Editor, AT\&T Laboratories,
	 April 2001;
	 Simple Mail Transfer Protocol;
	 Request for Comments(RFC) 2821

 \bibitem{maps}
	 MAPS; Stopping spam at its source;
	 \verb|http://mail-abuse.com/|
 \bibitem{sorbs}
	 SORBS;
	 Fighting spam by finding and listing Exploitable Servers.;\\
	 {\small \verb|http://www.dnsbl.au.sorbs.net/|}

 \bibitem{DJB 1986}
	 D. J. Bernstein;
	 A conform to UNIX Client-Server Program Interface, UCSPI-1996;
	 \verb|http://cr.yp.to/ucspi-tcp.html|

 \bibitem{spamcontrol}
	 Erwin Hoffmann, et al.; SPAMCONTROL;\\
	 {\scriptsize \verb|http://www.fehcom.de/qmail/spamcontrol.html|}
 \bibitem{qmpatch}
	 HIROSE, Yuuji;
	 qmail patches;\\
	 {\scriptsize \verb$http://www.gentei.org/~yuuji/software/qmpatch/$}

 \bibitem{anti-badmail-akita}
	 広瀬雄二, 大駒誠一;
	 SPAM門前払い・SMTPレベルでの受信拒否方策の検証;
	 平成15年度第2回 情報処理学会東北支部研究会 資料番号14

 \bibitem{antibadmail}
	 HIROSE, Yuuji;
	 Anti bad-mail SMTP wrapper;\\
	 {\scriptsize \verb|http://www.gentei.org/~yuuji/software/antibadmail/|}
 \end{thebibliography}

\end{document}
