メールサーバをちゃんとする

13,331 views
12,817 views

Published on

Published in: Technology

メールサーバをちゃんとする

  1. 1. メールサーバをちゃんとする BPS やました
  2. 2. 今日話すこと ● postfixは安定してるので、デフォルトでもまあ動く ● 運用がおざなり ● 理解も含めてちゃんとしよう 参考 ● 弊社 mail: 8958 sent /day
  3. 3. 今日話すこと 1. メールサーバ(MTA)の仕事 2. reject,deferをちゃんとする 3. メールキューをちゃんとする 4. セカンダリサーバをちゃんとする 5. Webアプリ送信方法をちゃんとする 6. まとめ
  4. 4. 1.メールサーバ(MTA)の仕事 送信 MUA MTA SMTP MTA SMTP MDA 今日はこの話 POP3/IMAP MUA・・・ thuderbird,Becky MTA ・・・ postfix,sendmail,qmail MDA・・・ maildrop等,(MTA)
  5. 5. 1.メールサーバ(MTA)の仕事 ● 配送 メールを他のサーバにrelayしたり メールボックスに保存したりする 自分が受け取らないメールは拒否したり relay MTA Mail Box MTA reject MTA
  6. 6. 1.メールサーバ(MTA)の仕事 ● キュー管理 メールが一時的に送れないようならあとでまた送ろう 機能(postfixならデフォルトで5日間再チャレンジする) ・・・・ 1.メール送るよー^o^ あれ返事がない? しばらくしてから送ろう MTA 2.キューに入れておこう MTA
  7. 7. 1.メールサーバ(MTA)の仕事 ● エラー通知 配送できなかったことを送信者に伝える bounceメール MTA 1.メール送るね 2.駄目受け取らない 3.ゴメン無理だったw MTA
  8. 8. 1.メールサーバ(MTA)の仕事 SMTPステータスコード ステータスコード 受信側 送信側 2xx メールを受け取ったよ。 送信成功したからキューは消しと く 4xx (応答がない場合 も) 今ちょっと受け取れない 後で送ろう キューに入れておく 5xx 今後もずっと受け取らない 2度と送ってくるな キューから消して エラー通知を送信者に送る 3xx系は省略
  9. 9. 2.reject,deferをちゃんとする ● ● reject怖い ⇒ 設定ミスでrejectしたメールは失われる 機械的に送られるメーリングリストから削除されるかも MTAはキューにためて再送する仕組み(defer)があるの で、メールサーバが落ちても(大抵は)メールが失われ ることはない
  10. 10. 2.reject,deferをちゃんとする ● ● メールサーバが落ちても慌てない(キューに溜まるので すぐには消えない) 誤ってrejectしてしまうほうが被害が大きいかも
  11. 11. 2.reject,deferをちゃんとする ● 自信が無かったらすぐには上げない 外部からの25番ポートへの受信を絶って落ち着いて確認 する #確認ホスト以外は25番をブロック iptables -A INPUT -s 192.0.2.0/24 -p tcp --dport 25 -j ACCEPT iptables -A INPUT -p tcp --dport 25 -j DROP
  12. 12. 2.reject,deferをちゃんとする ● SMTPを手で打ってちゃんと確認 (OP25Bの影響を受けないホストから確認する) OP25B = 大抵の個人向けISPは外向き25番の通信を禁止 している telnet 192.0.2.1 25 220 example.com ESMTP Postfix HELO postfix 250 example.com MAIL FROM: <test@example.com> 250 2.1.0 Ok RCPT TO: <hoge@example.com> 250 2.1.5 Ok
  13. 13. 3.メールキューをちゃんとする ● 配送できなかったメールはキューに溜まるけど 監視してないと異常に気付けない nagiosとかで監視してみる
  14. 14. 3.メールキューをちゃんとする ● キューがあるところは全部見る (実はmailmanもキューを持つ)
  15. 15. 3.メールキューをちゃんとする ● プラグイン入れても安心しない nagiosのcheck_mailqプラグインはバグがある postfixだとmailqが常にゼロだと判定される(←致命的) 修正箇所 宣伝 nagiosのcheck_mailqプラググインがうまく動かないとき nagiosでmailmanの監視をする
  16. 16. 3.メールキューをちゃんとする ● 雑談 メールサーバの異常をそのメールサーバを使って送ろう としない example.comメールサーバの異常をalert@example.com に送っても届かない(←あたりまえ)
  17. 17. 3.メールキューをちゃんとする ● nagiosだと contactを新しく定義して、Gmail等の違う メールアドレスを使う ※一部抜粋 define service { host_name mail service_description SMTPS contact_groups admins_gmail check_command check_smtp } define contact{ contact_name gmail ..... email hoge@gmail.com, huga@gmail.com } define contactgroup{ contactgroup_name admins_gmail alias Nagios Administrators members gmail }
  18. 18. 4.セカンダリサーバをちゃんとする ● こんな構成のセカンダリサーバ *@example.com は全部受信してprimary に転送するだけ secondary primary
  19. 19. 4.セカンダリサーバをちゃんとする ● 一度受信するのでbounceメールを送信する責任が生じる 3.送信者にbounce メール 1. hoge@exmaple.comをリレーする primary secondary 2. hoge@exmaple.comは存在しないので primaryがreject
  20. 20. 4.セカンダリサーバをちゃんとする ● 後方散乱 (backscatter) メールに利用されやすい ● キューが詰まりやすい 最初からsecondaryに送信する輩も多いので、primaryが 生きててもガンガン届く
  21. 21. 4.セカンダリサーバをちゃんとする ● 後方散乱 (backscatter) RCPT TO: 存在しないアドレス MAIL FROM: SPAM送り先 1. primaryに送るも拒否される secondary 2. 送ってないのにbounceメールが届く
  22. 22. 4.セカンダリサーバをちゃんとする ● キューが詰まる RCPT TO: 存在しないアドレス MAIL FROM: 存在しないアドレス 1. primaryに送るも拒否される secondary 2. 送信先がいないのでキューに溜まる
  23. 23. 4.セカンダリサーバをちゃんとする ● RBL,SPFを使って怪しい人はrejectする smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_rbl_client bl.spamcop.net, reject_rbl_client sbl.spamhaus.org, reject_rbl_client all.rbl.jp, check_policy_service unix:private/policy-spf
  24. 24. 4.セカンダリサーバをちゃんとする ● SPFの限定子はSoftFail(~)が多いので、対応できなさそ うならSoftFailもrejectする SPF例 v=spf1 include:spf01.softbank.ne.jp include:spf02.softbank.ne.jp include:spf99.softbank.ne.jp ~all v=spf1 +ip4:203.138.203.0/24 ~all 設定例 postfix-policyd-spf-python Mail_From_reject = SoftFail
  25. 25. 5.Webアプリ送信方法をちゃんとする ● サーバにpostfix入れるの('A`)メンドクセ アプリから直接送ろう ⇒突然の死(Gmailアカウント停止) config.action_mailer.smtp_settings = { :enable_starttls_auto => true, :address => 'smtp.gmail.com', :port => 587, :domain => 'example.com', :authentication => :plain, :user_name => 'hogeuser@example.com', :password => '123456' } _人人人人人人_ > 突然の死 <  ̄Y^Y^Y^Y^Y ̄
  26. 26. 5.Webアプリ送信方法をちゃんとする ● ● サーバの死=メールの消失 ⇒ MAIL FROMが適当だった場合、bounceメールすら受 け取れないかも そこでMTAですよ ⇒駄目でもキューに入れてリトライしてくれる ⇒キューさえ見ておけばメール消失を防げる
  27. 27. 5.Webアプリ送信方法をちゃんとする ● sendmailコマンドで送る ⇒キューの管理が出来る ⇒よほどの理由がないかぎりMTAに任せたほうが無難 △ web-app → 外のMTA → 受信者 ○ web-app → MTA → 外のMTA(必要なら) → 受信者 ※外のMTA = Gmail等 config.action_mailer.delivery_method = :sendmail
  28. 28. 5.Webアプリ送信方法をちゃんとする ● 豆知識 web-app → MTA → 外のMTA(Gmailとか) → 受信者 突然のアカウント停止! → Gmailから「535 authentication failed 」 → 5xx系エラーだからキューに溜まらない? postfixの粋な計らいにより例外的にキューに入れて defer扱いにしてくれる (smtp_sasl_auth_soft_bounceオプションがデフォルトyes) postfix△!
  29. 29. 6.まとめ ● ● 監視大事 ⇒ MTAやMDA等キューが溜まりそうなところは全部見 る ⇒ 日々のbounce,reject,sent量も見ておく(普段と違うこ とに気付けるようにする) テスト大事 ⇒ SMTPはSimple、めんどくさがらないでちゃんと見る
  30. 30. 6.まとめ ● 運用状況をメールで送る 毎日のbounce,deferred,rejectを見てみる 宣伝 postfixの運用状況をレポートにして送信する
  31. 31. 6.まとめ ● SMTPを確認する ⇒expectとかで工夫するとそんなに面倒じゃない require 'pty' require 'expect' describe "mail" do it "relay access denied" do PTY.spawn("telnet mail.example.com 25") do |r,w| w.sync = true r.expect(/ESMTP Postfix/) { w.puts "HELO postfix" } r.expect(/^250/) { w.puts "MAIL FROM: test@example.com" } r.expect(/^250/) { w.puts "RCPT TO: hoge@example.com" } r.expect(/^554/) { w.puts "QUIT" } r.readline.match(/Relay access denied/) end end end
  32. 32. メールサーバをちゃんとする \(^o^)/オワリ

×