メールと 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
(page 2)
Overview
(page 3)
電子メール(1)
(page 4)
電子メール(2)
- しかし、正しい運用とは? 例:
- データ(メール)を失いたくない
- 二重化
- バックアップ
- 速やかな復旧が可能 (設定の保守)
(page 5)
メールシステムの運用 (Operation)
ネットワーク管理者は片手間ではできない
- Political Layer
- 雑用
- 最新情報を追いかける
- ログの解析
- 設定の保守・管理・更新・変更
- 機器メインテナンス
- ユーザ教育
- 苦情処理 (abuse@domain)
(page 6)
電子メールのサービスとしての応用
- ML
- 閉じているもの
- 公開されているもの
- モデレータありのもの
- メールマガジン
?
(page 7)
電子メールのプロトコル的な応用
- 実装も簡単
- 開発者サイドからの見方としては重要
- 新しいものを考える際のお手本
(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
- パイプライン指向
- 特定の働きをするツールの集合 ( toolbox 指向 )
- 小さなプログラムを組合せて使う
- 熟知していれば非常に便利
例: エラーをリアルタイムに見張る
% tail -F /var/log/messages | egrep -i 'error|critical'
(page 12)
ML (fml) と MTA の関係
(page 13)
ML ドライバ
- ユーザにとって便利な環境を提供すること
- どうすれば使いやすいMLになるか?
- 様々な設定の自由度
(page 14)
ML (fml) の構造
(page 15)
SMTP の仕組み
(page 16)
SMTP の仕組み
(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)
高速化技術の要素
(page 24)
DNS の問い合わせ
rudo@nuinui.net -> elena@fml.org
(page 25)
帯域の問題
(page 26)
MTA の構造
Q: 現代的なメールサーバとは?
monolithic vs distributed/modular
- monolithic MTA (all in one)
(page 27)
MTA: Monolithic
(page 28)
MTA: Distributed
Postfix の例
(page 29)
配送方法 (1)
(page 30)
配送方法 (2)
(page 31)
配送効率
(page 32)
ML ドライバと配送性能
- そもそも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
(page 37)
ケーススタディ: FWTK
sendmail を使いつつ、よりセキュアにする試み
http://www.fwtk.org/
http://www.tis.com/
(page 38)
ケーススタディ: qmail
- Author: "D. J. Bernstein"
(page 39)
qmail の内部構造
(page 40)
qmail 利点(1)
1.03 で終り? ( 1.00 〜 1.03 は年に一度くらい )
今までsecurity絡みの緊急リリースはない
- (qmail 用の)一般ユーザ権限のプロセス群からなる
- set-uid されているのは qmail-queue だけ
- ユーザ qmailq に set-uid されていることに注意
- qmail-lspawnだけが root プロセス
注: 外部から接続は受けないprogram
注: 25/tcp を listen(2) するのは inetd など
(page 41)
qmail 利点(2)
- 配送
- 配送の立ち上がりが速い
- 配送時の相乗りをしない
- 少数の配送先なら圧倒的に速い
- VERPs (Variable Envelope Return Paths)
- 特殊な拡張アドレス
- UNIXの伝統にはこだわらない
- 安全? e.g. ~/.forward => ~/.qmail*
- 設定ファイルがちまちまと一杯ある
- DO NOT PARSE
- MailDir 他…
(page 42)
qmail 問題(1)
UNIXの期待/慣習と異なる
小さいファイルが平面的に広がってて読みにくい;_;
(大型機のファイルシステムみたい…)
マシンの負荷はそれなりにかかる
(一つ一つが小さいので思ったほど重くない?)
受けとる方も負担が大きい
宛先が多いと宛先の重なり効果が効き始める
(page 43)
qmail 問題(2)
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
(page 45)
ケーススタディ: Postfix
- Author: Wietse Venema
- TCP Wrapper (tcpd, libwrap.a) の作者
- SATAN (共作) の作者
(page 46)
Postfix Overview (1)
- α バージョンでは vmailer と呼ばれていた
- official と experimental がある
- major version up はゆっくり
- minor bug fixes が2、3カ月に一回くらいずつ出る
(page 47)
Postfix の内部構造
(page 48)
Postfix Overview (2)
- 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 を選択する
- VERPs はない
- stable にはない (VERPs パッチはあるようだ)
- current にはある
(page 50)
運用
(page 51)
運用における基本方針
- deny all + permit ...
- 初期設定は deny all であるべき
- 注意: 良い OS の見分け方 (?)
(page 52)
設定の保守
- (UNIX かつ)テキストファイルなら
- バージョンコントロールシステム
- 変更点のみを簡潔に把握する
例: postconf -n (postfix)
(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
(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)
例: (サーバでの)フィルタリング
- Postfix
- header_checks ディレクティブ
- body_checks ディレクティブ
- Content Filter
(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 附属でもいいだろう
- hardware は多種多様
(page 67)
メールサーバの二重化 (4)
サービスの無停止化
(page 68)
fml の日々の運用
(page 69)
日々の運用
- ディスク使用量
- 自動的に記事のスプールを圧縮する
- 自動的にスプールの記事を消す
- 古いログファイルを順次消す
(page 70)
fml: ユーザ管理
- 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)
(page 76)
まとめ (2)
(page 77)