メールと fml

(株)インターネットイニシアティブ
札幌支店インターネット技術部
深町賢一
<fukachan@sapporo.iij.ad.jp>

Copyright (C) 2001 Ken'ichi Fukamachi
All rights reserved.

http://www.fml.org/home/fukachan/

(page 1)

Table of Contents

SMTP の仕組み

配送の高速化

MTA の構造とセキュリティ

運用

fml の日々の運用

(page 2)

Overview

(page 3)

電子メール(1)

基本アプリケーション

最古のアプリケーションのひとつ

正しく動いて当然と期待されている

(page 4)

電子メール(2)

しかし、正しい運用とは？例:
- データ(メール)を失いたくない
- 二重化
- バックアップ
  - 時間スケール依存
- 速やかな復旧が可能 (設定の保守)

サービスのクオリティ例:
- 配送速度

(page 5)

メールシステムの運用 (Operation)

ネットワーク管理者は片手間ではできない

Political Layer
雑用
最新情報を追いかける
ログの解析
設定の保守・管理・更新・変更
- セキュリティ対策
  - 例: SPAM やウィルスのフィルタ
機器メインテナンス
ユーザ教育
苦情処理 (abuse@domain)

(page 6)

電子メールのサービスとしての応用

ＭＬ
- 閉じているもの
- 公開されているもの
- モデレータありのもの
- メールマガジン

ＭＬの spin off

Net News
- 誰でも読み書きできるＭＬと思えば親戚筋

BBS
- 見かけはＭＬと酷似、実装はかなり異なる

Instant Message

？

(page 7)

電子メールのプロトコル的な応用

SMTP 風のプロトコル体系は広く使われている
- POP3
- IMAP4
- NNTP
- IRC

実装も簡単
- 開発者サイドからの見方としては重要
- 新しいものを考える際のお手本

(page 8)

メールサーバ

メールサーバ == MTA + MSA + MDA ?

メールを受けとる
- 組織外部から
- 組織内部から

メールを配送する
- 組織外部へ
- 組織内部へ
- 宛先が自分自身であることもある
  - ディスクに書く

(page 9)

メールサーバの構造

用語: MTA MSA MDA(LDA) MUA

(page 10)

UNIX でのメールサーバ

歴史

Free Software
- ソースコードが公開されている
- セキュリティ上の問題への対処が早いことが"多い"

製品もある
- 例: sendmail, netscape messaging server
- 商用サポートが必要か否かが論点だろう
- Free Software のメインテナンス問題

(page 11)

UNIX

テキストベースの設定ファイル
- /etc/

パイプライン指向
- 特定の働きをするツールの集合 ( toolbox 指向 )
- 小さなプログラムを組合せて使う
- 熟知していれば非常に便利

例: エラーをリアルタイムに見張る
% tail -F /var/log/messages | egrep -i 'error|critical'

(page 12)

ML (fml) と MTA の関係

(page 13)

ML ドライバ

配送は MTA に依存

メンバーリストの管理
- 自動 / 手動

ユーザにとって便利な環境を提供すること
- どうすれば使いやすいＭＬになるか？
  - ヘッダの書き換え
- 様々な設定の自由度
  - 設定インターフェイス

(page 14)

ML (fml) の構造

(page 15)

SMTP の仕組み

(page 16)

SMTP の仕組み

RFC 821 ( RFC 2821)

文字ベースでコマンドを送り合うプロトコル

送り先(ドメイン)は DNS で調べる

(page 17)

メール送信の概念図

rudo@nuinui.net -> elena@fml.org

(page 18)

メールの送信

図の手順を各受信者について行なう。
つまり受信者の数だけ繰り返す。

DNS で相手先を調べる (図中 1～4)
- Q: fml.org の情報を知っているホストは誰？(図中 1～2)
- Q: fml.org の MX (Mail eXchanger)は誰？(図中 3～4)

SMTP (図中 5)
- TCP で MX へ接続 ( 25/tcp )
- SMTP のやりとりを行なう (後述)

HELO
MAIL FROM:
RCPT TO:
DATA
.
QUIT

(page 19)

ケーススタディ: SMTP (1)

S 220 ahodori.fml.org ESMTP Postfix
C EHLO katri.nuinui.net
S 250-ahodori.fml.org
S 250-PIPELINING
S 250-SIZE 10240000
S 250-ETRN
S 250 8BITMIME
C MAIL FROM:
S 250 Ok
C RCPT TO:
S 250 Ok

... snip ...

S = サーバからのメッセージ
C = クライアントが送るメッセージ

(page 20)

ケーススタディ: SMTP (2)

rudo@nuinui.net -> katri.nuinui.net -> ahodori.fml.org -> elena@fml.org

220 ahodori.fml.org ESMTP Postfix
EHLO katri.nuinui.net
250-ahodori.fml.org
250-PIPELINING
250-SIZE 10240000
250-ETRN
250 8BITMIME
MAIL FROM:
250 Ok
RCPT TO:
250 Ok
DATA
354 End data with .
From: rudo@nuinui.net
To: elena@fml.org
Subject: Todays's meeting

今日のミーティングは 15:00 からだ

るど隊長＠ぬいぬい
.
250 Ok: queued as 9BB9F86640
QUIT
221 Bye
Connection closed by foreign host.

(page 21)

ケーススタディ: POP3

S +OK QPOP at hikari.fml.org starting. <27773.1001664805@hikari.fml.org>
C USER fukachan
S +OK Password required for fukachan.
C PASS パスワード
S +OK fukachan has 98 messages (259935 octets).
C LIST
S +OK 98 messages (259935 octets)
S 1 1661
S 2 2255

... snip ...

C RETR 1
S 一番目のメールが表示される
S .
C QUIT
S +OK Pop server at hikari.fml.org signing off.

S = サーバからのメッセージ
C = クライアントが送るメッセージ

(page 22)

配送の高速化

(page 23)

高速化技術の要素

相手のサーバまでの問題
- 帯域
- IP フォワーディングの性能
- レスポンス

MTA の構造からくる制限
- sendmail
- qmail
- postfix

(page 24)

DNS の問い合わせ

rudo@nuinui.net -> elena@fml.org

(page 25)

帯域の問題

(page 26)

MTA の構造

Q: 現代的なメールサーバとは?

monolithic vs distributed/modular

monolithic MTA (all in one)
- sendmail

distributed MTA's
- qmail
- postfix

(page 27)

MTA: Monolithic

(page 28)

MTA: Distributed

Postfix の例

(page 29)

配送方法 (1)

(page 30)

配送方法 (2)

(page 31)

配送効率

一般にメールのサイズは小さい

命令のやりとりは多い

ネットワークが遊んでいる時間を減らす
- 並列度による重ね合わせ

(page 32)

ML ドライバと配送性能

配送速度とはほとんど無関係 (図を参照)

そもそもＭＬドライバとは何か？
- 管理者の管理コストの削減
- コミュニケーションの便宜をはかる

(page 33)

MTA の構造とセキュリティ

(page 34)

いつ/どこが危ない？

(page 35)

90 年代のサーバ paradigm

ネットワーク的な境界線で行なうことは最小限にする

最小限の権限
- root 権限は絶対に必要
- root 権限は最小限に
- setuid/setgid はできるだけ使わない

プロセスと権限の分離
- 大量のプロセス生成
  - 環境: プロセスを大量に生成可能なマシンパワー

paradigm: T.S. Kuhn, 『科学革命の構造』 (みすず書房)

(page 36)

ケーススタディ: sendmail

BSD 標準
- 歴史がある
- 今でも多くの人が使っている
- sendmail.cf のノウハウが一杯

root で走る all in one program
- 8.11.x まで

規格もののチャレンジャー(?)

(page 37)

ケーススタディ: FWTK

sendmail を使いつつ、よりセキュアにする試み
http://www.fwtk.org/
http://www.tis.com/

(page 38)

ケーススタディ: qmail

Author: "D. J. Bernstein"

http://cr.yp.to/qmail.html

http://pobox.com/~djb/qmail.html

http://www.qmail.org/

(page 39)

qmail の内部構造

(page 40)

qmail 利点(1)

official release はゆっくり

1.03 で終り? ( 1.00 ～ 1.03 は年に一度くらい )
今までsecurity絡みの緊急リリースはない

小さいプログラムの集合体

(qmail 用の)一般ユーザ権限のプロセス群からなる
- qmail-lspawnだけが root プロセス

注: 外部から接続は受けないprogram
注: 25/tcp を listen(2) するのは inetd など

(page 41)

qmail 利点(2)

配送
- 配送の立ち上がりが速い
- 配送時の相乗りをしない
- 少数の配送先なら圧倒的に速い
- VERPs (Variable Envelope Return Paths)
- 特殊な拡張アドレス

stubなネットワークなら簡単インストール

UNIXの伝統にはこだわらない
- 安全? e.g. ~/.forward => ~/.qmail*
- 設定ファイルがちまちまと一杯ある
- DO NOT PARSE
- MailDir 他…

(page 42)

qmail 問題(1)

ソースが読み難い

UNIXの期待/慣習と異なる
小さいファイルが平面的に広がってて読みにくい;_;
(大型機のファイルシステムみたい…)

配送速度を上げるためにはプロセス数で勝負

マシンの負荷はそれなりにかかる
(一つ一つが小さいので思ったほど重くない?)
受けとる方も負担が大きい

配送先が多い場合に早いかどうかは?

宛先が多いと宛先の重なり効果が効き始める

(page 43)

qmail 問題(2)

ちょっと複雑な設定は難しい
- ソースを変更、多くのパッチがある(そういう文化)
- もしくは program (wrapper) の組み合わせ方を変更
- http://www.qmail.org/
- 相互に矛盾しないのか？などは不明

設定ファイルがちまちまと一杯ある

UNIXの伝統には拘らない
- 直感が働かず困る

qmail の特殊な拡張アドレス体系

qmail-smtpdは一度吸込んでみないと
user unknownなどの判定ができない
利点 => VERPs

(page 44)

VERPs

netbsd-bugs-owner@netbsd.org -> fukachan@sapporo.iij.ad.jp

受信者
- fukachan@sapporo.iij.ad.jp

送信者
- エラーの返る先
- エラーを起こした人を一意に特定
- netbsd-bugs-owner-fukachan=sapporo.iij.ad.jp@netbsd.org

なぜこんなことができるのか？
- 相乗りをしないから
  - × DSN
- qmail の拡張アドレス

(page 45)

ケーススタディ: Postfix

http://www.postfix.org/

Author: Wietse Venema
- TCP Wrapper (tcpd, libwrap.a) の作者
- SATAN (共作) の作者

(page 46)

Postfix Overview (1)

sendmail を置き換えることを目指している

α バージョンでは vmailer と呼ばれていた

official と experimental がある
- major version up はゆっくり
- minor bug fixes が2、3カ月に一回くらいずつ出る

(page 47)

Postfix の内部構造

(page 48)

Postfix Overview (2)

設定ファイルが UNIX 風
- UNIX な人には保守しやすい

分散システム / モデュラシステム
- 現代的アーキテクチャア
- セキュア

sendmail との互換性
- 実用的な面での互換性は申し分ない
- sendmail.cf は理解しない
- uucp なども簡単に設定できる
- db dbm nis などのデータベース互換
  - mysql, ldap ...
  - regexp, pcre

(page 49)

Postfix Overview (3)

set-uid は使わない
- world writable maildrop vs setuid() か
- set-gid bit を選択する

slow start

resource limit

rate limit

VERPs はない
- stable にはない (VERPs パッチはあるようだ)
- current にはある

(page 50)

運用

(page 51)

運用における基本方針

できるだけ人手をかけたくない
- routine work はコンピュータにさせる

設定の把握
- 変更の差分を把握したい
- 過去の変更点も追跡したい

deny all + permit ...
- 初期設定は deny all であるべき
- 注意: 良い OS の見分け方 (?)

(page 52)

設定の保守

設定ファイル vs プログラムの入れ換え
- プラモデル？

(UNIX かつ)テキストファイルなら
- バージョンコントロールシステム
  - CVS
  - RCS
- 変更点のみを簡潔に把握する
  - ツールがあることもある

例: postconf -n (postfix)

壊れた時は同じ設定のホストを速やかに復旧させたい
- 例: テキストのファイルをコピーするだけで終了

データの永続化
- RDBMS
- LDAP

(page 53)

ケーススタディ: RBL を使う

sendmail
- m4 のルールを定義し sendmail.cf を作りなおした後
- リスタート

postfix
- /etc/postfix/main.cf を編集後
- postfix reload

smtpd_recipient_restrictions = permit_mynetworks
reject_maps_rbl
check_relay_domains

qmail
- まず rblsmtpd と入れ換えろ ;)

(page 54)

例: cvs による管理

% cd /etc/postfix
% ... main.cf を編集
% cvs diff -ub
cvs diff: Diffing .
Index: main.cf
===================================================================
RCS file: /cvsroot/conetc/postfix/main.cf,v
retrieving revision 1.1.1.1
diff -u -u -b -r1.1.1.1 main.cf
--- main.cf 2001/10/01 11:29:10 1.1.1.1
+++ main.cf 2001/10/01 11:30:48
@@ -393,3 +393,11 @@

+
+#
+# use RBL to reject spam
+#
+smtpd_recipient_restrictions = permit_mynetworks
+ reject_maps_rbl
+ check_relay_domains

(page 55)

例: 差分を見る

postfix のデフォルトからの変更点を把握する
解答 1
% postconf -n

解答 2
% cd /etc/postfix
% diff -ub main.cf.default main.cf
--- main.cf.default
+++ main.cf
@@ -393,3 +393,11 @@

+
+#
+# use RBL to reject spam
+#
+smtpd_recipient_restrictions = permit_mynetworks
+ reject_maps_rbl
+ check_relay_domains

(page 56)

プラモデル指向への疑惑

大きなプログラムの極一部を入れ換える手法は？
- 開発は簡単、高速だろう
- パッチも作りやすい
- しかし、保守性が良いとは誰も保証していない

このようなパッチワークは何回くらい有効か？
- 相互に矛盾しないのか？
- 自分のした操作を把握し切れるか？
- 複数台のホストで行なわなければならないとしたら？

例: qmail
- 基本的な論法は
  - www.qmail.org で探す
  - プログラムを入れ換える ;)
  - パッチを当てて再コンパイル ;_;

(page 57)

例: (サーバでの)フィルタリング

Sendmail
- sendmail.cf

Postfix
- header_checks ディレクティブ
- body_checks ディレクティブ
- Content Filter

Qmail
- プログラムの集合体…
- 参照: http://www.qmail.org/

(page 58)

ケーススタディ: sendmail.cf (1)

http://www.sendmail.org/m4/anti-spam.html

m4 のルールが用意されていれば簡単
- FEATURE(`relay_entire_domain')
- FEATURE(`dnsbl')

キーワードマッチくらいは簡単

複雑なルールを仕込むのは大変

(page 59)

ケーススタディ: sendmail.cf (2)

例: @ を含まないMessage-IDははじく
LOCAL_CONFIG
Kstorage macro

LOCAL_RULESETS
HMessage-Id: $>CheckMessageId

SCheckMessageId
# Record the presence of the header
R$* $: $(storage {MessageIdCheck} $@ OK $) $1
R< $+ @ $+ > $@ OK
R$* $#error $: 553 Header Error

Scheck_eoh
# Check the macro
R$* $: < $&{MessageIdCheck} >
# Clear the macro for the next message
R$* $: $(storage {MessageIdCheck} $) $1
# Has a Message-Id: header
R< $+ > $@ OK
# Allow missing Message-Id: from local mail
R$* $: < $&{client_name} >
R< > $@ OK
R< $=w > $@ OK
# Otherwise, reject the mail
R$* $#error $: 553 Header Error

(page 60)

ケーススタディ: postfix

[/etc/postfix/main.cf]
header_checks = regexp:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks

[/etc/postfix/header_checks]

/^Message-Id:[ \t]$/ REJECT
/^Subject:.*(money wanted|make lots of \$\$|\$\$\$)/ REJECT
/^Subject:.*are you (being investigated|in need of a lifestyle)/ REJECT
/^Subject:[ \t]+ADV:/ REJECT
/^From:.*infowatch\.net/ REJECT
/^To:.*customer@aol/ REJECT

(page 61)

ケーススタディ: qmail

www.qmail.org の中から探して適宜入れ換える;)

例: mess822 を入れて .qmail を書き換えなさい

~user/.qmail に
| condredirect user-null except 822field From

~user/.qmail-null には
#

(page 62)

二重化

データを守りたい

無停止でサービスを提供したい

(page 63)

二重化の例: WWW サーバの二重化

コンテンツのアップデートが緩やかなら簡単

(page 64)

メールサーバの二重化 (1)

メールサーバのソフトウエアとしては？

ディスクに書く部分の二重化ができない
- 時間スケール
- 逆の例: WWW
- ハードウエアで頑張る → ディスクの強化

メールの受信の並列化

メールの送信の並列化

(page 65)

メールサーバの二重化 (2)

理想論

(page 66)

メールサーバの二重化 (3)

データを守る

ハードウエア

ディスクの RAID 1 化 (1+0 化)
- software なら OS 附属でもいいだろう
  - RAIDFrame
- hardware は多種多様
  - 2,3 万のカード～数千万

(page 67)

メールサーバの二重化 (4)

サービスの無停止化

ネットワーク
- routing (layer 3)

フロントエンドの並列化

(page 68)

fml の日々の運用

(page 69)

日々の運用

ログファイルを見る

ディスク使用量
- 自動的に記事のスプールを圧縮する
- 自動的にスプールの記事を消す
- 古いログファイルを順次消す

設定の変更と更新履歴を残す

バックアップ

(page 70)

fml: ユーザ管理

自動登録 / 手動登録
- confirmation

confirmd (2.2 new)
- 一定期間ごとに参加し続けるか？をユーザに尋ねる
- 返事がないと削除する。

USE_MEMBER_NAME (2.2 new)
- メンバーのアドレスと名前をセットにして管理する
- 4.0 以降は RDBMS が普通か？

エラーメールの自動解析
- DSN qmail ...
- Mail::Bounce (fml 5.0)

(page 71)

fml: データの集中化および永続化

データベースアクセス機能 (4.0 new)
- メンバーリストをデータベースで管理する
- 記事をデータベースに格納する

組織全体でデータの一元化をはかる

(page 72)

fml: フィルタリング

投稿メールのフィルタリング (2.2 new function)
- 中身のないメール
- unsubscribe 一行だけのメール
- Melissa ウィルスチェック(2.2.1 new)

ContentHandler
- 例: HTML mail 対策: HTML部分を切落とす (2.2.1 new, optional)

トラフィックモニタ (2.2 new function)
- 単純なメール爆撃対策

メールのループ検出
- Message-ID Cache
- system account rejection
- MD5 checksum によるループ検出 (3.0 new, optional)

(page 73)

fml: ディスク

自動圧縮(spool -> tar.gz style)

記事の自動 expiration (DISKがない場合)

newsyslog(8)
- log ファイルのrotation (log -> log.0, log.0 -> log.1 ...)

(page 74)

まとめ

(page 75)

まとめ (1)

SMTP の仕組み

配送の高速化

MTA の構造とセキュリティ

運用

fml の日々の運用

(page 76)

まとめ (2)

OS やメールサーバを使って何をするか？
- OS は万年筆

いざという時に備えて
- 地道な努力
- ネットワーク設計/tuning
  - simple is best

UNIX
- toolbox

(page 77)