SlideShare a Scribd company logo
メールシステムのおはなし荒木靖宏twitter.com/ar1facebook.com/araki.yasuhiro#mailerstudy
荒木 靖宏(あらき やすひろ)Twitter:ar1Debianオフィシャル開発者2010年度Debian JP プロジェクト会長.Postfix詳解の著者. 博士(科学). 東北大->NAIST->IIJ->ネットビレッジ->HP->東大->DeNA->AWSでびでびあんあんでびあんあん。 今の仕事: 「お客様のやりたい事」の実現AWS化を手伝います。Amazon Web Servicesソリューションアーキテクト
メールシステムと私1995年qmailとの出会い. linux-users MLの管理. 1997年 NAISTのメールサーバ等の管理
spamとの戦い開始
99年初頭にqmailへのリプレース
S/MIMEのMLへの適用で修士をいただく
1999年 IIJでメールサービス開発
JUSのイベントでqmailの話をする
2000年imode系のメールサービスベンチャ
Postfixを使った最大級のサービス
2001年 JUSのイベントでPostfix代表として登壇
2004年Postfix詳解出版アジェンダメールシステム超基本編これであなたもメール談義ができるように!メールシステム現実編これであなたもメール騙りができるように!
メールシステム超基本編これであなたもメールの話題の輪に加われますキレイゴトの世界
DNSインターネット全体俯瞰NTPメールサーバMail Delivery AgentMail Transfer Agent (MTA)MailboxMail User Agent (MUA)ユーザ
Mail User Agentユーザが利用するアプリケーションメールを読むメールを書くメールを保存するメールを検索する例Thunderbird, Outlook, ….
Mail Transfer Agentメールの受信送信先の決定メールの送信リモートへ(SMTP)ローカルへ(MDAへ)キューイングエラー通知実装例Sendmail, qmail, Exchange, Postfix, Exim,..
メールメッセージ
メールアドレス発信者と受信者を特定する情報user@example.com(失われた)その他形式user % example.com @ relay@relay: user@example.comexample.com! userユーザ部ドメイン部
ヘッダと本文RFC5322(822->2822と変遷)で定義ヘッダヘッダ名: ヘッダ内容ヘッダと本文は空行で分けるTo: yasu@debian.or.jpFrom: ar@debian.orgSubject: test本文の1行目
ヘッダとエンベロープSMTPのRFCで定義。5321(821->2821と変遷)エンベロープ送信手続をした人と、配送先。封書の表書きのイメージMUAやMTAが作成する。MTAは配信ホップ毎に書きかえる。ヘッダ封書の中身に「だれだれさんから、だれだれさんへ」と書くのに相当本文を書いた人(From)が読んで欲しい人(To)を記述ヘッダとエンベロープが一致しない例個人にあてられたbccメーリングリスト
インターネットプロトコルDNSNTPメールサーバローカルファイル操作SMTPIMAPPOP3SMTP
DNSとメールuser@example.comにどう届く?送信側: MXレコードに書かれたアドレスのAレコード宛に送信するMXレコード優先度を指定できる(数値が小さいほうが優先される)たまに見る間違いCNAMEを指定する(RFC2181で禁止)MTAによってはメールが届かない
$ dig mx hiroba.org;; QUESTION SECTION:;hiroba.org.			IN	MX;; ANSWER SECTION:hiroba.org.		86400	IN	MX	5 alt1.aspmx.l.google.com.hiroba.org.		86400	IN	MX	5 alt2.aspmx.l.google.com.hiroba.org.		86400	IN	MX	10 aspmx2.googlemail.com.hiroba.org.		86400	IN	MX	10 aspmx3.googlemail.com.hiroba.org.		86400	IN	MX	10 aspmx4.googlemail.com.hiroba.org.		86400	IN	MX	10 aspmx5.googlemail.com.hiroba.org.		86400	IN	MX	1 aspmx.l.google.com.;; AUTHORITY SECTION:hiroba.org.		170129	IN	NS	ns-165.awsdns-20.com.hiroba.org.		170129	IN	NS	ns-1624.awsdns-11.co.uk.hiroba.org.		170129	IN	NS	ns-1347.awsdns-40.org.hiroba.org.		170129	IN	NS	ns-1003.awsdns-61.net.;; ADDITIONAL SECTION:aspmx.l.google.com.	185	IN	A	74.125.127.27alt1.aspmx.l.google.com. 	187	IN	A	74.125.45.27alt2.aspmx.l.google.com. 	197	IN	A	74.125.93.27aspmx2.googlemail.com.	2212	IN	A	74.125.43.27aspmx3.googlemail.com.	2213	IN	A	74.125.127.27aspmx4.googlemail.com.	2945	IN	A	209.85.229.27aspmx5.googlemail.com.	1888	IN	A	74.125.157.27ns-165.awsdns-20.com.	44352	IN	A	205.251.192.165ns-1003.awsdns-61.net.	44352	IN	A	205.251.195.235ns-1347.awsdns-40.org.	162645	IN	A	205.251.197.67
DNSを使った送信先決定DNS root serverDNS cache serverMTA21,5.com SOA3Example.comのMXレコード?Example.comのMXレコード?->.comに聞けExample.comのMXレコード?->.example.comに聞けExample.comのMXレコード?->10 mail.example.comだよMail.example.comのAレコード?.....example.comSOA4
SMTPHELO sender.example.com250 OKMAIL FROM: user@example.com250 OKexample.jpSender.example.comRCPT TO: user1@example.jp250 OKMTAMUADATA354 Startヘッダ,本文.. <CRLF>.<CRLF>250 OKQUIT250 OK
SMTPのステータスコード200番台正常応答情報提供300番台データ入力を促す(354)400番台一時的なエラー: サーバシャットダウン、メールボックスbusy、メールボックス溢れ500番台システムエラー: コマンド間違い転送エラー: メールアドレスなし、処理失敗通知
メーリングリスト配送の場合HELO sender.example.com250 OKMAIL FROM: user@example.comRCPT TO: user1@example.jp250 OK配送サーバMLプログラム250 OKRCPT TO: user2@example.jp250 OK参加者分くりかえしDATA354 Startヘッダ,本文.. <CRLF>.<CRLF>250 OKQUIT250 OK
配信エラーメールSMTPセッション時のエラー送信元のMTAが作成。エンベロープの発信者メールアドレスにエラーメールが戻るSMTPセッション時以外送信先のMTAが作成エンベロープの発信者に戻る or Errors-To:
メールシステム現実編これであなたもメール管理者の穴にはいれます参加者みなさまとおはなししていきたい
メール騙りのために重いんだけど?Logどうしてる?SPAM対策は?現実解?皆様の体験談を聞きたい!
vs重いんだけど?MUA問題?重いんだけど?外部配送速度攻撃?内部配送速度気のせい?
Logは重要とはいえ考えること多数Firewall vs SniffSyslog vs独自ログDB vsテキスト集中管理 vs分散管理ローテーション vs永久保存コンプライアンス vs技術理由メール専用vs汎用事後解析vsリアルタイムデータ爆発!
メール用のログ解析メール専用qmailanalog, pflogsum,logrep, mailstatsコンバータmaillog2commonlog [sendmail|smail|newsmail|qmail] < logfile
Log->通知リアルタイムLogsurferSwatch定期的LogcheckLogwatch
vs SPAMメールの悲しみ他者からの入力を認証なしにうけつけてしまったのが発端個人として受信したときの対応はどうとでもなる: フィルタでもなんでもできる自分のメールアドレスでSPAMを送信されたときは大変。今なら社会的に抹殺されるかもしれないサーバ管理者として受信する側: 下手な対応はできない送信する側: ものすごく厳しくするのオススメ

More Related Content

メールシステムのおはなし #Mailerstudy