FFR Yarai vs 自作マルウェアもどきウェア

FFRのYarai。評価版を入手した。従来のウィルススキャンとは一線を画すらしい。シグニチャパターンではなくそのマルウェアの挙動で「悪意を見抜く」とのこと。パターンファイルに依存しない「ヒューリスティック検出技術」を追及した次世代セキュリティソリューションという触れ込みだ。

http://www.fourteenforty.jp/products/yarai/

パターンマッチングによるウィルス検知には限界がある。マルウェアの挙動で判定するという手法はいままでも、いろいろなところで考えられてきたし、実際に仮想的なサンドボックスでマルウェアを実行して判定するようなウィルス対策アプリケーションもあったようななかったような.....。でも、その「悪意ある挙動」とはいったい何なのか定義が難しそうだ。

そこで、かつて色々あって（別に悪さをしようと思ったわけではなく）マルウェアもどきみたいなのをつくったことがある。これを使ってYaraiがどの挙動を悪意と判定するのかみてみようと思った。で、まずこの自作マルウェアの概要から。一応以下のような機能を有している。

(1)ドロッパ(親プログラム)　A.exe
 -B.exe(ウィルス本体)を「C:\Windows\」に配置。
 -B.exeのファイルスタンプを2003/07/01 13:12:09に変更。
 -Windowsファイアウォールに「Windows Update Tools」の名前で除外設定をする。
 -B.exeを実行。
 -レジストリを編集しB.exeを自動起動設定する。

(2)ウィルス本体 B.exe
 -UPXにて圧縮済み。
 -レジストリに自身を再起動登録する。
 -起動直後、公開用ディレクトリ(C:\Program Files\temp)を生成する。
 -自身がHTTPサーバとなり常駐起動する（ポート10890）。
 -一定時間後、リモートサイトよりキーロガー（C.dll）をダウンロードする。
 -キーロガーのダウンロードが完了したらdllをロードする。
 -定期的に画面キャプチャを取得する。
 -画面キャプチャファイルをPNG形式で生成し、ファイルの末尾にキーログを追加して公開ディレクトリに配置する。
 -My Documents配下のファイルを公開ディレクトリにコピーする。

(3)キーロガー C.dll
 -Windowsグローバルフックを使いキーパンチストロークをB.exeに通知する。

あくまで技術検証用につくったので決してバラまいたりとかしてません！さて、これらの動作の中でyaraiは何を悪意ある動作とするかを検証してみた。yaraiのインストール自体は簡単だった。で、さっそくA.exeを実行してみたところ、しばらくして以下のようなメッセージが出た。

「隠しプロセスがWindowsフックをインストールしようとしました。スパイウェアに利用される可能性が.....(snip)」とのこと。どうもキーロガーについて言っているようだ。では、 C.dll を修正してWindowsフックの部分をコメントアウトして再度実行してみた。

実行したところ、yaraiは何も反応しなくなった....つまり、キーロガー以外の機能、たとえば画面キャプチャをとったり、ポートを勝手に開けたり、WindowsFireWallの例外設定をしたり、外部からファイルをダウンロードしたり、パックされたファイルをドロップしたり、自身を再起動登録することについては悪意がないと判定されたわけだ....俺も悪人になれないな.....。

一応、スタティックスキャンを試してみた。B.exe のプロセスを殺し、C.dll のWindowsフック処理を再度実装し B.exe がロードできる場所に配置して、スタティックスキャンを実行した。そうすると、B.exe がマルウェアと検知された。

おそらく、Windowsフックを実装している C.dll をロードする処理が入っているためだろう。C.dll を削除した状態でスタティックスキャンを実行したら B.exe は検知されなかった。

一言で「悪意ある処理」っていっても切り分け難しいよね。たった、これだけの評価で yarai の検知精度についてどうこう言うつもりは全くないんだけど、これだけは言いたい！画面のリサイズくらいはできるようにしてほしい！中のリストボックスに表示されている長いメッセージが見ずらくてしょうがない。

WORM_DOWNAD (Conficker) の対処の話

いつぞやのWORM_DOWNAD感染の話。例のMS08-067のやつだね。ちゃんとパッチあててね。毎月のパッチ運用がめんどいのは分かるけど、感染後の事態収集のほうがよほどコストかかるだろうにと思うんだが....どうなんだろう。

ウィルス感染したら業務回らんだろうし、下手したら何週間も業務が止まってしまうことだってある。あくまでパッチが優先でウィルススキャンソフトは保険。
で、本題なんだけれども技術的なお話。TrendMicroから駆除ツールが公開されていて、それを片っ端から実行していく。そしてパッチあて。

http://jp.trendmicro.com/jp/threat/extermination_tool/downad/

それで、一安心と思いきや、いまだに対象のマシンからオンライン検知で、定期的に「WORM_DOWNAD」が見つかるというメッセージが出るのでどういうことかというお話。

でまあ、ServerProtectのログを見てみるととある一定時間おきに発生しているようだ。推測として、

・駆除ツールでクリーンできずに内部にある別のプロセスがワームを定期的に作り出しているのか
・感染している別のマシンから定期的に本サーバにアクセスしワームを設置しているのか

まぁ、後者だろうな。DOWNADの詳細をTrendMicroのページにて確認してみた。

・ワーム活動（ネットワーク共有フォルダの利用）：
ワームは、感染したコンピュータの環境設定に関する情報を収集します。ワームは、ドメイン内に表示された特定のタイプのサーバを全てリストアップします。このようなサーバが確認されると、ワームは、ローカルおよびサーバのコンピュータのユーザをリストダウンします。
ワームはまず、サーバ内のユーザアカウントを収集するため、"NetUserEnum" API の機能を利用します。そしてワームは、以下のパスワードを用いて、強引にネットワークへの侵入を試みます。　

ほう、パッチがあたっていても、他に感染しているものがあれば管理共有経由でファイルを置かれるらしい。たぶん、これだな。じゃあ、どうやって感染源をつきとめるか。Windowsの監査ポリシーのログオン成功のイベントログを見てみた。ログオン成功のイベントログを見ればログイン元も確認できる。

このログインイベントの発生時間とオンラインスキャンでの検知時間が重なる部分を見てみたところ、あった。あった。おそらく、これが感染源だろう。そこでこの感染源を調べてみたところ案の定感染していたので駆除ツールを実行し駆除した。結果、見事にオンラインスキャンの検知がなくなった。

共有経由で入ってくるワームについては、Windowsのログイン監査ポリシーが使えそうだな。デフォルトではログインの失敗の監査は有効にされていないが、ログインの失敗も有効にしておくほうがエビデンス上いいね。

でもまずは、管理共有はOFFる、強固なパスワード設定するくらいの基本的なことが大事だね。

GENOウィルス解析記（Episode 2）

前回の続き。まぁ、とりあえず、ネットワークには繋がずに例の「インフルエンザ病人の路線.pdf」を開いてみた。動作させるには、Acrobat Reader 8.0が必要のようだ。8.1.3でも7.1でも7.0.5でもだめ。全部のバージョンで調べたわけではないけど、8.0では少なくも動作する。

実行してみると、見た目にはこんな感じのファイルになるが、このとき実は細工された（バッファオーバーフローを起こす）「インフルエンザ病人の路線.pdf」は無害化される。「C:\Documents and Settings\ユーザ\Local Settings\Temp」にも同じファイルができるが、こちらももともとのファイルとはまったく別のファイルになってしまう。すごいね。役目が終了したら自分自身をクリーンにする。このPDFが怪しいと思って、たとえばCSIRTみたいの専門部署に検体を送付しようとしても、もう実行してしまったらそのPDFを送っても意味がないということだ。

実行前の「インフルエンザ病人の路線.pdf」（MD5：9137fec2f6a1b020cd877cebce8b8f67）
実行後の「インフルエンザ病人の路線.pdf」（MD5：4803792069d86d265feb45ba76308e0a）

また、実行後「C:\Documents and Settings\ユーザ\Local Settings\Temp」に「svchost.exe」ができたと思ったら、すぐに消滅し「C:\Wiondows\System32」に 「nseb.exe」 ができる。この「svchost.exe」 と 「nseb.exe」 のファイルの中身はまったく一緒だ。VIRUSTOTALにかけてみたところ。以下のような結果に。

さて、この「nseb.exe」が何をするかだが。中国サイトに接続するという話がある。このファイルを覗いてみたところ、暗号化はされていないように見える。確かにこのあたりの記述、怪しいね。

デバッグしてみようかな。

GENOウィルス解析記（Episode 1）

いまちょっと話題になっているGENOウィルス。Adobe ReaderやAdobe Flash Playerの脆弱性を突いたものなんだんけれども、最初の感染が通販サイトのGENOであるが故にこのように呼ばれている。GENOにとってはハタ迷惑かもしれないが、GENOの対応の悪さも手伝ってこの通称が一般化しているようだ。

Adobeの脆弱性をつくなんてのは別に珍しいわけではなく、メールでばらまいたりWebサイトを改ざんしてダウンロードさせるといった感染手法も、とりたてて真新しいものではない。でも、聞いた話によるとWebサイトを改ざんされた場合の痕跡が一切みつからず、どのように改ざんされたのかが不明らしい。このウィルスそのものよりもウィルスをダウンロードさせるためのWebサイト改ざん方法のほうが実際には注目されているとかいないとか。

先日、このGENOウィルスの検体を入手した。ファイル名は「インフルエンザ病人の路線.pdf」(MD5:9137fec2f6a1b020cd877cebce8b8f67)というもの。ありがちな便乗系の名前。新型インフルエンザが猛威をふるって日本でも若干過剰なくらいに反応していたけれでも、だからといって、こんな怪しいファイル開いてしまうんだろうか。無頓着な人は開いてしまうんだろうなぁ。

さて、対象はPDFファイルだ。動的で調べてもいいんだけれど例によってまずここは静的で。なぜ静的かって、ひとつは手前に適当なサンドボックス環境がないことと、あとは、まぁ趣味みたいなもの。100%完璧に検体を丸裸にするのは無理かもしれないけど、静的でできるところまでやってみて、あとは動的で補完する。このほうが自分の腹に落ちるし説得力もありそうだ。

ちょっと前にwmvファイルの解析をしたことがあったが、pdfファイルの仕様もAdobeから公開されている。

[Adobe PDF Reference, Sixth Edition, version 1.7]
http://www.adobe.com/devnet/pdf/

この仕様を参考に「インフルエンザ病人の路線.pdf」を見てみよう。仕様書を隅々まで読んだわけではないが、pdfファイルはオブジェクトの羅列でメタデータ的な可読な部分(ASCII)とstreamであるバイナリ部分に分かれているようだ。ひとつのオブジェクトは「CR-LF」で区切られるので、pdfファイルは意外とバイナリエディタよりもテキストエディタで覗くほうが見やすかったりする。

でよく見てみると、JavaScriptが埋め込まれていることが分かる。

11656行目の「 24 0 obj<>」。「24」はオブジェクトナンバー「25 0 R」はオブジェクトナンバー「25」を参照ということ。で、同様にオブジェクトナンバー「25」（参照）→「26」（参照）→「27」で、オブジェクトナンバー「27」がJavaScriptの実体のように見える。オブジェクトナンバー「27」には「27 0 obj<>stream」というヘッダがついている。これは 「Flate」 でエンコードされていることをあらわしている。「Flate」はZipなどで使われている圧縮アルゴリズム。pdf内ではこの「Flate」と「LZW」がエンコード方法としてよく使われるらしい。この「Flate」は「ziplib」や「zlib」などを使用することでデコードできる。

「.NET用ライブラリ（SharpZipLib）」
http://www.icsharpcode.net/OpenSource/SharpZipLib/
「ネイティブ用ライブラリ（zlib）」
http://zlib.net/

以下は SharpZipLib を使用した場合のデコードコード（VB.NET）。

Private Function FlateDecode(ByRef fsOutFile As FileStream, ByRef fsSourceFile As FileStream, ByVal lOffSet As Long, ByVal lLength As Long) As Boolean

        Dim i As Long
        Dim stream As MemoryStream
        Dim zip As InflaterInputStream
        Dim writeData(4096) As Byte
        Dim iNumRead As Integer
        Try
            stream = New MemoryStream(lLength)
            fsSourceFile.Position = lOffSet
            While (i < lLength)
                stream.WriteByte(CByte(fsSourceFile.ReadByte()))
                i += 1
            End While
            stream.Position = 0
            zip = New InflaterInputStream(stream)
            While (True)
                iNumRead = zip.Read(writeData, 0, writeData.Length)
                If iNumRead > 0 Then
                    fsOutFile.Write(writeData, 0, iNumRead)
                Else
                    Exit While
                End If
            End While
        Catch ex As Exception
            Throw ex
        Finally
            zip.Close()
            fsSourceFile.Close()
            fsOutFile.Close()
        End Try
    End Function

これを使って、FlateエンコードされているさきほどのJavaScriptの実体があると思われる部分をデコードしてみた。その結果が以下。

どうも、バッファオーバーフローを狙っているようだ。「sc」がシェルコードだろう。38行目をデコードしてみると以下のようになる。

Collab["\x67\x65\x74\x49\x63\x6f\x6e"](of+a[0x0]);
↓
Collab["getIcon"](of+a[0x0]);

実はCollab.GetIcon()にはバッファオーバーフローの脆弱性が指摘されている。

http://www.securityfocus.com/bid/34169
http://www.ca.com/us/securityadvisor/vulninfo/vuln.aspx?id=37210

これだね。このバッファオーバーフローをついている。シェルコード部分を一応デコードしてみると以下のようになる。このシェルコードはいったいなにをしようとしているのか。なんか9割がたアスキーコードが並んでいて怪しいが.......

LACの岩井さんのブログ（↓）によると、中国のサイトに飛ばされるらしいのだが。
http://trackback.blogsys.jp/livedoor/fsecure_blog/50244449

（続く）

IIS WebDAV 脆弱性を回避するISAPIフィルタを作成しました

本脆弱性の詳細情報は下記のURLを参照してください。

[マイクロソフト セキュリティ アドバイザリ（971492）]
http://www.microsoft.com/japan/technet/security/advisory/971492.mspx

ちょっとこのアドバイザリ、記述が曖昧で分かりにくいですね。なんか、通常のACL設定では書き込みはできないから大丈夫よ的な印象を受けるけど、こちらで動作を確認してみると、IISで該当フォルダに書き込み権を設定していれば新規ファイルの作成も出来てしまっているようで。

そこで、WebDAVの脆弱性を回避するためのISAPIフィルタを作成してみました。理想的にはMSからパッチが出るまでの間はWebDAVを無効にすることが一番なのですが、運用上、どうしても、どうしても、WebDAVを使いたいという方は本フィルタを導入することで問題を回避することができます。

本フィルタはWebDAVリクエスト中に存在する不正エンコード部分を除去後、WebDAVへ処理を継続させることにより、WebDAVにおける認証処理のバイパスを回避します。現在、以下の環境にて動作を確認しています。

Microsoft Windows Server 2003 Enterprise Edition Service Pack 2
Internet Information Service (IIS) 6.0

たぶんIIS5でも動作すると思います。

ダウンロードはこちらから。
（※）zipファイルの直リンクができないようので、お手数ですがブラウザにURLをコピペしてダウンロードしてください。

http://www.geocities.jp/digisecdog/WDZDFilter.zip

ダウンロード後ZIP解凍して、含まれているREADMEを参考にしてIISにこのISAPIフィルタを設定してください。なお、いわずもがなですが、一切の保証はいたしません。まぁ、とりあえず評価してみてください。指摘された問題については可能な限りがんばってアップデートしていきます。まぁ、MSのパッチが出るまでですが。

IIS6のWebDAVに脆弱性が発見された（ヤバイよ、ヤバイよ）

NTTデータセキュリティからIIS6でWebDAV認証回避の脆弱性にレポートが公開された。IISで認証付きのページの認証がバイパスされてしまう危険性があるとのこと。以下がレポート。

http://www.nttdata-sec.co.jp/article/vulner/pdf/report20090518.pdf

一応、実証してみたところ超簡単に再現できた。その再現プロセスは後述するとして、この脆弱性は攻撃の容易性と攻撃された場合のインパクトのデカさからかなり要注意だと思われる。WebDAV使ってWebコンテンツの更新をやっているところ（しかも、公開WEB上で）がどの程度存在するのかわからないけど、もし、そのような運用をしているサーバがあったら、即刻、対処すべし。また、WebDAVを使っていないにも関わらず有効にしているサーバがあったら一刻も早く対処すべし。

対処方法はIISマネージャでWebDAVを無効にするだけ。基本、デフォルトでは無効になっているはず。

以前、Windows2000＋IIS5の環境において、コンテンツが改ざんされるというインシデントに対応したことがあったが、このときも、WebDAV経由でのコンテンツの改ざんだった。このときの侵害された要因としては使用していないにも関わらず、Front Page Server Extensionsがインストールされており、かつwwwrootに対する認証機構を設定していなかったため起きた。IISの脆弱性をつかれたわけではなく構築側の設定ミスであり認証設定さえしてあれば問題はなかった。今回はIIS自体に脆弱性があるわけで、当然ながらキチンと認証設定されていてもまったく意味をなさなくなる。

結局のところWebDAVの文字コード処理に問題があるのだが、ほんとにこの文字コードってやつは厄介だよ。ほんとになんとかならんもんか。

では、今回の脆弱性を再現してみよう。海外のサイトとか見てみると詳しく書いてあるんだけどね。まず、適当に仮想ディレクトリをつくる。ウィザード中のアクセス許可は、とりあえず「読み取り」「書き込み」「参照」にチェック。

次にこの仮想ディレクトリに認証を設定する。

あとはWebDAVを有効にする。

これだけで準備は完了。では、WebDAVリクエストを送信してみよう。まずはGETで先ほどの仮想フォルダの下にあるコンテンツを取得してみよう。以下のようなリクエストを投げてみる。GETはHTTPメソッドではなくWebDAVのGETメソッドであることを示すために「Translate:f」ヘッダを付加する。これは非標準でMS独自の拡張ヘッダ。MSのWebDAVサーバにはこのヘッダを付けて送るらしい。

GET/TEST/test/test.html HTTP/1.1
Translate: f
Connection: close
Host: 192.168.11.180

結果は以下の通り401が返ってきた。認証エラーだ。ちゃんと認証が利いていることを示している。

続いて、以下のようなリクエストを投げてみる。「%c0%af」を要求するコンテンツのパス内の仮想ディレクトリ名の適当な位置に挟む。

GET/TE%c0%afST/test/test.html HTTP/1.1
Translate: f
Connection: close
Host: 192.168.11.180

結果は以下の通り。200で返ってきてコンテンツをGETできてしまった。

同様に「%c0%af」を挟み、PROPFINDメソッドでフォルダ/ファイル構成を見ることもできる。以下がそのリクエストとレスポンスの結果。

PROPFIND /TE%c0%afST/test HTTP/1.1
Host: 192.168.11.180
User-Agent: hogehoge
Connection: TE
TE: trailers
Depth: 1
Content-Length: 298
Content-Type: application/xml

おー。関心している場合ではない。これはやばい。この「%c0%af」問題。確か以前のバージョンのIISでも同じような問題があったと思った。パストラバーサルが可能になってしまうというやつ。「%c0%af」は「/」とデコードされるので、たとえば、「..%c0%af..%c0%af」なんてリクエストを投げると非公開のファイルが覗けてしまうやつ。これに似ている。

ここで、なぜ「%c0%af」が「/」になるかが難しいよね。ここでちょっと簡単に説明してみる。簡単に説明するので正確ではない部分もあるかもしれない。

まず第一に文字コードのお話。コンピュータで扱える文字って、英語圏の人ならアルファベットと記号だけでいいのでそんな数いらない。でも世界中には無数に文字が存在する。んで、どの文字をコンピュータで扱うのかを決めようということで「符号化文字集合」というコンピュータで使う文字を集めた。つまり、一文字一文字にIDを割り振ったようなもんだね。この規定が ASCII とか UNICODE とか。

で、実際にコンピュータに実装するときにどのようなビットパターンにするかは別の話で、これらを「文字符号化方式」という。これらの規定が UTF-8 とか UTF-16 とか SHIFT−JISとかになる。で、UTF-8のビットパターンは以下のようになっている。

0xxxxxxx
110xxxxx 10xxxxxx
1110xxxx 10xxxxxx 10xxxxxx
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

この「x」の部分に Unicode で規定されている符号を右詰に格納するというルール。で、問題になっている「%c0%af」はURLエンコードだ。これをビットにしてみると。

11000000 10101111

これを上のルールにあてはめてみると（上から2つ目のやつ）。Unicode で規定されている符号部分は、

0010 1111

つまり 「%2f」。これは「/」を表す。というわけ。 ということは、だ。ルールに則ると「/」を UTF-8 で書くと何も「%c0%af」だけではないということになる。つまり、以下もすべて「/」になる。

%e0 %80 %af
%f0 %80 %80 %af
%f8 %80 %80 %80 %af
%fc %80 %80 %80 %80 %af

実際に、上の攻撃リクエストで「%c0%af」の部分を「%e0%80%af」にしても攻撃は成功した。なぜか、それよりも長いパターンの場合はBadRequestとして扱われてしまった。では、なぜこのようにUTF-8の「/」を挿入すると、認証機構をバイパスできてしまうのかについてなんだけれども。

とあるサイトによると、WebDAVでは認証チェックの段階でデコードするからだということらしい。つまり、たとえば /TE%c0%afST/test/ へのリクエストがあった場合、まず、デコードするので /TE/ST/test/ となる。そして、このようなフォルダは存在しないので、認証不要と判断され処理が先に進む。そして、コンテンツにアクセスする前にこのUnicode部分が除去されるということらしい。

ソースルーティングを利用したメールの第三者不正中継

とあるメールサーバで第三者不正中継が可能になっているとの指摘を受けた。よくある話。とりあえず、おなじみのOpen Relay Checker (http://check.jippg.org/)と、RBL.JP(http://www.rbl.jp/)でチェック。何種類かある不正中継試行リクエストの中でひとつだけ通過した（不正中継を受け付けた）結果が出た。両ツールの結果は同じことを指摘している。

１．OpenRelayChecker

２．RBL.JP

Toに指定しているアドレスに何やら「%」が含まれている。これは見たことがない。いったい何なのか。（職業病なのか）不正エンコードと疑ってみたが、そうではないらしい。実はこれはRFCに規定されているれっきとした正規のリクエスト。正規というと誤解を受けるかもしれない。送信意図は不正でもプロトコル上はこういう書き方が許されているらしい。

ソースルーティングというものらしい。RFC1123（http://www.isi.edu/in-notes/rfc1123.txt）に規定されている（5.2.16項あたり）。普通ネットワーク上のルーティングはルータがやるんだが、ソースルーティングは送信の起点であるクライアントがルーティングを指定するもの。RFC1123が策定された当初ではインターネット上のホストはこれをサポートすべき的なことが書かれて、メールサーバもこのRFCに厳密に則って実装すると機能として搭載されることになる。

たとえば「aaa%bbb.com@ccc.com」というリクエストは、「ccc.comを経由してbbb.comのaaaというユーザにメールを送る」ということになる。実はほかにも記法があって、「@ccc.com:aaa@bbb.com」という「:」を使った書き方もある。

そもそもこのソースルーティングはメールの配信遅延を防ぐためにインターネット黎明期に策定されたもの。実際に、RFC1123は1989年に最初に規定されたものだ。現在ではRFC1123においても[DESCUSSION]で使用すべきではない的なことが書かれている（以下、日本語訳より抜粋）。

送信元ルーティングは不要であり、単純なターゲットアドレスである "user@domain" で常に十分なはずである。これは、メールにおいて送信元ルーティングではなく共通的な名前を使うという、明確で体系立てられた決定の結果である。従って、SMTP はエンドツーエンドの接続性を提供し、DNS は世界共通で位置に依存しない名前を提供する。MX レコードは、それが無ければ送信元ルーティングが必要な主要なケースを扱っている。

ほう、機能的には実装されてもいいような気がする。インターネット環境では無効にすべきだが、テスト環境とかローカルな環境では有用な機能かもしれない。巷のメールサーバにおいては、

１．sendmail
　実装されている。sendmail.cfで以下を設定すると無効にできる。
　REJECT_SOURCE_ROUTE_RELAY=yes

２．postfix
　実装されている。main.cfで以下の行をコメントアウトすると無効にできる
　＃allow_percent_hack　=　no

３．qmail
　実装されている。デフォルトで無効にされていてソースルーティングを使用する場合はqmail-send の percenthack に適用するドメイン名を記述する。

ざっと調べただけなので実際の構築場面で設定する場合はちゃんとマニュアル見てほしいのだけれど、調べてみた感じではメールサーバいじる人にとって、このソースルテーティングは当たり前の知識だったみたいだ.......知らなかったよ......