トップページ⇒unix
1001コメント309KB

Postfix(6)

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。2006/09/20(水) 02:04:10
Postfixスレッド その6です。

●リンク
　本家
　http://www.postfix.org/

　Postfix のぺーじ (ドキュメントの日本語訳、MLなど)
　http://www.kobitosan.net/postfix/

過去スレ、関連スレなどは>>2-4あたり
0205名無しさん＠お腹いっぱい。2006/12/11(月) 16:39:43
>>204
そのファイルの定義によるｗ
virtual_alias_maps だとしたら、外のアドレスを書いても問題ない。
0206名無しさん＠お腹いっぱい。2006/12/13(水) 02:49:49
Postfix adminの為にPHPやMySQL入れるの嫌じゃー

つー事で、あまり環境依存のないwebベースの管理ツール教えてください
0207名無しさん＠お腹いっぱい。2006/12/14(木) 03:26:58
Postfix 2.3.5
0208名無しさん＠お腹いっぱい。2006/12/15(金) 01:39:46
>>206 わけわからん。。。
管理者やめちまえ
0209名無しさん＠お腹いっぱい。2006/12/15(金) 01:42:31
>>202 つうかさ、ベイジアンなんか元から何の役にも立ってねぇよ？
登場してから今に至るまでこのロジックで満足できたという奴を俺は知らんｗ
とりあえず上手く行きそうな未来を感じるのはSURBL系だろ？
0210名無しさん＠お腹いっぱい。2006/12/15(金) 03:13:16
スーペリアボーイズラブ系？
0211名無しさん＠お腹いっぱい。2006/12/15(金) 03:24:17
>>210 楽しいのかスパマ〜？
0212名無しさん＠お腹いっぱい。2006/12/15(金) 14:12:20
いま208がイイこと言った!!
0213名無しさん＠お腹いっぱい。2006/12/15(金) 18:43:49
bayesian を否定したがってる >209 は spammer
0214名無しさん＠お腹いっぱい。2006/12/16(土) 08:56:07
ISPや携帯キャリアの「迷惑メール拒否サービス」ってベイジアンフィルタじゃないの？
NGワードで拒否ってるだけ？
0215名無しさん＠お腹いっぱい。2006/12/16(土) 09:36:35
フィルタのせいで大事なメールをspam扱いされた経験がある身としては
迂闊に判定して捨てないで欲しいけどな。

MLとか通販伝票とかがヤバい
0216名無しさん＠お腹いっぱい。2006/12/16(土) 09:45:15
>215
んじゃもっといい方法を作って実装して提供してくれ
0217名無しさん＠お腹いっぱい。2006/12/16(土) 10:09:01
>>216
>>215はメールフォルダにSPAMすら10通も来ない寂しい人なんだよ。
0218名無しさん＠お腹いっぱい。2006/12/16(土) 11:03:52
postfixの話じゃねえじゃねえか。

過疎ってるこのあたりでも使ってやれよ。
http://pc8.2ch.net/test/read.cgi/unix/1128256415/
0219名無しさん＠お腹いっぱい。2006/12/18(月) 09:54:04
>>213
だがベイジアン盲信するのも馬鹿だがな
0220名無しさん＠お腹いっぱい。2006/12/18(月) 21:02:59
何でも盲信するのは馬鹿。

だか使って考察しようとせずに高みの見物を決め込むのはアホ。
0221名無しさん＠お腹いっぱい。2006/12/18(月) 23:52:08
そもそも、解決できるなら、spamがこんなに騒ぎになってスレが荒れる事はありえない。

「解決できず、人によって許容できる・できないが分かれる物」を話題にしてしまうから荒れるんだろ。
0222名無しさん＠お腹いっぱい。2006/12/19(火) 00:33:17
つーか spam 対策には銀の弾丸は存在しなくて、いくつもの技術を組み
合わせてバランスを取ってくひたすら不毛な作業でしかないわけだよね。
ある技術 (たとえばベイジアンフィルタリングとか) が万能ではないから
といって役立たず扱いするってのは、極端杉だろう。
0223名無しさん＠お腹いっぱい。2006/12/19(火) 02:03:23
ベイジアンでもxBLでも「誤認識」が一番怖くて白・黒追加判定は結局必要
有料でも当然完全ではないので妄信はどのみち不可

結局MUA/MTAで診断結果をヘッダ付加しユーザーが目視チェックする
しかなく、上流で拒絶するタイプは弊害が大きく毒になるってこと

んで、ベイジアンが前者の目視チェックタイプの導入例が多くxBLは後者
の拒絶する導入例が多いという事
(xBLチェックはMTAで行う歴史があり、ベイジアンはSpamAssassinって事)

そう考えるとInternet社会の中では xBL 系の方が実害が多く毒になってる
とは思う

結局、管理者はどちらを使うにしろ最低限の検出率UP対策はするべきであり
RBLならどこを使うかの選定、SpamAssassinなら日本語化対応、白黒学習
の方法の指導など「仕組みが悪い」と居直る前に先手先手に立ち回らなければ
いけない（ログのチェックは当然だしね）

ウイルス対策がいたちごっこな用にSPAM対策も同じように対処しなければ
いけない

だから、このスレでは何でも何回でも同じ議論がされてOK
常に”敵”は進化するんだからこちらも進化しなければいけない

例：reject_ns　（今はもう必要ない）

結局、俺たち管理者の仕事は今後も永久に無くならないｗ
俺は少なくてもISPの有料フィルターやF-Sxxxxxなんかの糞製品には負けない
サービスを会社で構築している自負と自信があるよ
たとへ会社がそれを評価するかどうかは知らんけどさ・・・　＿|￣|○ ｱｳｱｳ
0224名無しさん＠お腹いっぱい。2006/12/19(火) 03:43:20
>>223
spamassassinでDNSBLだのURIBLだのをやっていることを知らない人?
0225名無しさん＠お腹いっぱい。2006/12/19(火) 03:54:57
>>224 論点が違うと思うんだが？
0226名無しさん＠お腹いっぱい。2006/12/19(火) 09:35:49
論点とかどうでもいい。spammer をぶっ殺せ。殺して焼き尽くせ。話はそれだけだ。

それと、スレ違いです。続けるのなら別のところでどうぞ。
0227名無しさん＠お腹いっぱい。2006/12/19(火) 09:38:10
>>223
> reject_ns　（今はもう必要ない）
qsv系って今もうこれ効かないの？
0228名無しさん＠お腹いっぱい。2006/12/19(火) 12:02:10
postfixに乗り換えようかと思ってるんですが、今からという事だと
2.3.xでおっ毛（無難）ですかね？

調べてみてもバージョンごとの違いが明確に出てこないもんで
0229名無しさん＠お腹いっぱい。2006/12/19(火) 12:13:51
これから新規にインストールする時は
開発元が最新の安定版だとしているものを迷わずインストールしろ。
オープンソースソフトの場合
商用ソフトのような「新製品を買わせるための新製品」は無いのだから。
0230名無しさん＠お腹いっぱい。2006/12/19(火) 13:10:22
ごもっともですね。
どうも失礼しました。
0231名無しさん＠お腹すいた。2006/12/19(火) 17:20:38
質問させてください。

master.cf にて設定を行い
外部から25番で受けたメールを他サーバに飛ばして、検疫後10025番で受ける
というシステムを動かしています。

ポート毎にログを分ける
もしくはpostfix/smtpdが受けたポート番号をmaillogに出力する
ことは可能でしょうか？
0232名無しさん＠お腹いっぱい。2006/12/19(火) 18:21:30
>>231
submission ポートで受け付けたことをログに記録したくても、
一筋縄では出来ないってことと同じ問題かな？

たしか smtpd からハードリンクした submitd 等のファイルを
作成して、master.cf で submission ポートの smtpd の代わり
に指定すれば、ログで判別できるようになるのだったっけ。
0233名無しさん＠お腹いっぱい。2006/12/19(火) 19:26:38
symlinkでもエエけどね。漏れの環境は

cd /usr/libexec/postfix; ln -s smtpd smtpA
master.cfに
587 inet n - n - - smtpA

でオケ。logは

Dec 19 19:22:09 svr postfix/smtpA[24798]: connect from localhost.localdomain[127.0.0.1]
Dec 19 19:22:25 svr postfix/smtpA[24798]: 3245233360: client=localhost.localdomain[127.0.0.1]
0234名無しさん＠お腹いっぱい。2006/12/19(火) 20:47:08
>>227　どうだろう、効かないとは言わないけど
最近QSV系は皆無だね
DDNS側で対策したんじゃないの？
02352322006/12/19(火) 21:05:46
>>233
symlink でもイケるのですね。テキトーなこと書いちゃってすみません……
0236名無しさん＠お腹いっぱい。2006/12/19(火) 21:45:35
念のため。
それで実現できるけど、推奨はされない。本家 ML でもときどき話題に出るけど、
かならず「もうひとつ postfix を起動しろ」という回答に落ち着く。

2.3 では smtp と lmtp が統合されてひとつのバイナリになって、
どの名前で起動されたかによって動作を変えるようになった。
今のところ smtpd はそういうことはしないけど、
将来もずっとそうだとは保証はされない。
02372312006/12/20(水) 11:35:33
>>232
>>233
>>236

ありがとうございます。
もうひとつPostfixを起動させるとなると、ちょっと気軽に構成変更はできないですね･･･
maillogの client= とかでgrepして集計するようにしたいと思います。

本家MLでも出る話題なのですね。そちらもチェックしたいと思います。
ありがとうございました！
0238名無しさん＠お腹いっぱい。2006/12/20(水) 11:39:14
>>234
ほんとだ。
dmfactorysとかbusiassistとか、mel@なやつにしか効いてねえや。
0239名無しさん＠お腹いっぱい。2006/12/21(木) 03:51:16
postfixadminって2年近くアップデートされていないけど、
他にいいwebフロントエンドないかな?
まあ、ユーザ管理をするだけならpostfix専用のwebフロントエンドは
必要ないのは確かなんだけど。
0240名無しさん＠お腹いっぱい。2006/12/21(木) 16:40:56
>>239
postfixadminの不満点は？
0241名無しさん＠お腹いっぱい。2006/12/21(木) 17:30:33
>>240
2年近くアップデートされていないこと自体が不満になる罠。
ttp://forums.high5.net/viewforum.php?f=1を見る限りフォーラムは盛況なので、
開発が停止して死んだプロダクトと化しているわけではないだろうけど。
0242名無しさん＠お腹いっぱい。2006/12/21(木) 18:38:11
じゃ自分でバージョン表記書き換えりゃいーじゃん
内容に不満は無いんでしょ？
0243名無しさん＠お腹いっぱい。2006/12/21(木) 18:55:48
242はたぶん包茎
0244名無しさん＠お腹いっぱい。2006/12/21(木) 19:09:22
>>242
でダメな理由はちょっとしりたい
0245名無しさん＠お腹いっぱい。2006/12/21(木) 19:14:11
240=242=ただの荒らし
0246名無しさん＠お腹いっぱい。2006/12/21(木) 19:16:13
239がpostfixadmin以外にどんなwebフロントがあるのか聞いているのに、
大したキチガイ発言だ。
0247名無しさん＠お腹いっぱい。2006/12/21(木) 20:05:27
良いフロントエンドというからには
良し悪しの基準が239にはあるのだろうし、
それに照らし合わせてpostfixadminのよしあしを
語ってもらえれば良いんじゃないかな？
とりあえず最近アップデートされているやつが欲しいというのは読み取れた。
0248名無しさん＠お腹いっぱい。2006/12/21(木) 20:21:50
いい加減240うざすぎ。消えろ。
0249名無しさん＠お腹いっぱい。2006/12/21(木) 20:40:34
めでたしめでたし
0250名無しさん＠お腹いっぱい。2006/12/21(木) 20:41:11
239さん
postfixadminの不満点を書いてよﾜﾝﾜﾝ
0251名無しさん＠お腹いっぱい。2006/12/21(木) 20:50:25
>>250
質問をすると240に噛みつかれる点
0252名無しさん＠お腹いっぱい。2006/12/21(木) 20:52:02
240の発狂っぷりが凄まじいな
0253名無しさん＠お腹いっぱい。2006/12/21(木) 20:53:55
postfix-jp-listに送ろうとするんだけど、Greylistingに阻まれて
遅れない。にょろーん。なんか独自パッチが当たっているっぽい。
そして独自パッチがバグっていると思う…。

しゃあないので、2chに転載しますが、
------------
少々お知恵を拝借したいのですが、LDAPサーバ障害時の対策について
なにか良い手がないでしょうか?

現在

LDAPサーバ CentOS4.2 /OpenLDAP : 1台
メールサーバ CentOS4.4 /Postfix : 1台

構成で運用しています。

先日、LDAPサーバのldap daemon(プロセス)が落ちてました。

メールサーバでUnknown Userエラーで大量のメールが落ちてしまいました。
とほほ。そこで対策を考えていたのですが、

色々調べた所

(続く)
02542532006/12/21(木) 20:55:27
(1)LDAPサーバのldap daemon(プロセス)が落ちた場合:
即時にUser Unknown エラーになる。つまり、再送は期待できない。
---
% telnet mail.example.ac.jp 25
Trying 192.168.0.1...
Connected to mail.example.ac.jp.
Escape character is '^]'.
220 mail.example.ac.jp ESMTP Postfix
HELO hoge.example.ac.jp
250 mail.example.ac.jp
RCPT TO: hogehoge@mail.example.ac.jp
550 <hogehoge@mail.example.ac.jp>: Recipient address rejected: User unknown in local recipient table
---

(2)LDAPサーバのLANケーブルを抜いた場合:
LDAPサーバに接続しようとして反応しなくなる。
---
% telnet mail.example.ac.jp 25
Trying 192.168.0.1...
Connected to mail.example.ac.jp.
Escape character is '^]'.
(この状態で黙る)
---
しかし 即時にUser Unknown エラーにはならないので、後日、再送が期待できる

送信側の/var/log/maillogより:
-----
Dec 21 19:13:22 hoge postfix/smtp[25039]: [ID 197553 mail.info] 107541DB41: conversation with mail.example.ac.jp[192.168.0.1] timed out while sending MAIL FROM
-----
(続く)
02552532006/12/21(木) 20:56:17
という調査結果になりました。(2)の状態になるなら良いのですが、(1)の状態
が問題です。

何か手はないでしょうか?

例えば、

1. LDAPサーバのヘルスチェックをして、反応が無くなったら

/etc/postfix/main.cf
---
unknown_local_recipient_reject_code = 550
---
から
---
unknown_local_recipient_reject_code = 450
---
に書き換えてくれるようなスクリプトとか、

2. LDAPサーバのldap daemonが落ちた場合でも即時にエラーにならないような
/etc/ldap.confの設定方法とか。

なにかありましたらよろしくお願いします。
0256名無しさん＠お腹いっぱい。2006/12/22(金) 00:08:38
>>253
独自パッチの当たったGreylistingで送れない気がする、というほうが気になるんだが。
どういうエラーログが出てるのか、どういう環境から送ってるのか知りたいところ。
02572532006/12/22(金) 01:14:55
普通のgreylisyingじゃないんだ。

telnetで叩いてみると、sourceforgeだと

% telnet lists.sourceforge.jp 25
Trying 202.221.179.24...
Connected to lists.sourceforge.jp.
Escape character is '^]'.
220 lists.sourceforge.jp ESMTP Postfix (Debian/GNU)
HELO 私のドメイン
250 lists.sourceforge.jp
MAIL FROM: 私のメアド
250 Ok
RCPT TO: Postfix-jp-list@lists.sourceforge.jp
450 <私のメアド>: Sender address rejected: unverified address: host 私のホスト名[私のIP] said: 451 <私のメアド>: (長いので折り曲げ)
Recipient address rejected: Greylisted, see http://isg.ee.ethz.ch/tools/postgrey/help/私のドメイン.html (in reply to RCPT TO command)
quit
221 Bye

となるのだが、これは普通のgreylisting(postgrey-1.27)と応答が違う。

(続く)
02582532006/12/22(金) 01:16:04
普通のgreylisting(postgrey-1.27)だと、

$ telnet mail.example.ac.jp 25
Trying 192.168.0.1...
Connect to mail.example.ac.jp (192.168.0.1).
Escape character is '^]'.
220 mail.example.ac.jp ESMTP Postfix
HELO 私のドメイン
250 送り先のドメイン
MAIL FROM: 私のメアド
250 2.1.0 Ok
RCPT TO: 送り先のメアド
451 4.7.1 <送り先のメアド>: Recipient address rejected: Greylisted, see http://isg.ee.ethz.ch/tools/postgrey/help/送り先のドメイン.html
quit
221 2.0.0 Bye

になる。応答が違うんだよ。たぶんパッチが当たっている。

一時間過ぎてpostfix flushしても遅れないのでqueueを消した。
0259名無しさん＠お腹いっぱい。2006/12/22(金) 01:33:19
postgrey以外にもたくさんPostfix用のgreylistingプログラムがあるってこと知らんのか、こいつ
02602562006/12/22(金) 01:37:45
>>257
たぶんパッチとかそういう話じゃないと思います。
Sender address rejected: unverified adress:
って出てるのでreject_unverified_senderでの制限のほうが先に掛かって、それで抜けれないのでは？
Postfix-MLでそんな目に会ったことないんですが、参考まで逆引き設定とかどうなってますか？
02612562006/12/22(金) 01:39:41
>>259
257に書いてあるエラーで、postgrey特有のメッセージが出てるから、postgrey利用してるのは
間違いないと思います。
0262名無しさん＠お腹いっぱい。2006/12/22(金) 10:15:03
sourceforge.jp は greylisting なんかやっていない。
そのかわり、送信者のアドレスが実在するか確認するために、
from アドレスの MX に逆接続して RCPT TO: の応答を見る。

そこで、「おまえのサーバ」が greylisting をやって sourceforge.jp からの
接続を蹴ってるから、sourceforge の方も from アドレス詐称だな、と判断して
おまえからのメールを拒否する。自分が参加してる ML ぐらいホワイトリストに
入れておけ。ホワイトリストなしで greylisting 使うなボケ。
02632532006/12/22(金) 10:50:27
>>262
あ、なるほど。よくわかりました。

しかし、この仕様は大人数のサーバだと厳しいですね。MLに参加するには
管理者に事前申請して登録してもらわないといけないわけだ。
0264名無しさん＠お腹いっぱい。2006/12/22(金) 11:08:26
受信側が sender address verification、送信側が greylisting という環境でも
再送してりゃそのうち届くだろ。
02652532006/12/22(金) 12:18:55
whitelist無しでも送れるようになりました(^^;;

今回は他のバグにも当たってたようです。greylistingの
待ち時間が1時間以上になっていました。そのためsender address
の検査にも1時間以上かかるようになっていたようです。

これも原因がよくわからないのですが、設定では300秒になっている
のですが、なぜか1時間以上になっていました。再起動したら300秒
に戻りました。何らかの原因でパラメータが壊れたようです。半年
以上動かしているサーバですので、宇宙線が壊したかもしれませんが(^^;;
そういう時でもECCメモリならコレクトしてくれるのかもしれませんね。
0266名無しさん＠お腹いっぱい。2006/12/22(金) 12:24:22
ここはよいｇｄｇｄｽﾚですね
0267名無しさん＠お腹いっぱい。2006/12/22(金) 14:06:49
デフォルトの設定だと
recipient_canonical_mapsでアドレスいじってtransport_mapsでリレー先に送る
って動いてるみたいですけど
transport_mapsでリレー先を決定してアドレス変えてから送信するってどうやればいいんでしょうか？
0268名無しさん＠お腹いっぱい。2006/12/22(金) 15:03:09
smtp_generic_maps、generic(5) でできそうな気がするけど、
実際にできるかどうかは未確認。
0269名無しさん＠お腹いっぱい。2006/12/22(金) 21:35:14
greylistingが解決したところで本題ｗ

さて>>253氏は>>254でtelnetした際の応答を出しただけで
LDAPなマップをmain.cfでどのように指定しているのか、とか
エラーが発生したときにどのようなログが吐かれたのか、などの
肝心な情報をさっぱり示さないのはどうしてだろう？
02702532006/12/22(金) 22:15:12
>>269
LDAPはpam経由、つまり普通のUNIXユーザ認証で使っています。 main.cfには何も書いていません。

エラーログは大学に行かないと取れないので、明日出します。
0271名無しさん＠お腹いっぱい。2006/12/22(金) 22:48:24
>>270
それなら正直postfixと無関係だろ。
alias_maps=ldap:/foo/bar ならpostfixの話題になるだろうけど。
0272名無しさん＠お腹いっぱい。2006/12/22(金) 23:20:51
ｴｴｴｴｰ驚愕の事実判明>>270
02732532006/12/22(金) 23:47:53
>>271-272
もしかして、postfixのスレで尋ねるにはナンセンスな質問でしたかね?

pamの設定かなぁ〜？

authconfigが自動的に作ったpamの設定を見ると、こんな設定がありますね。
これを変更してみようか。

/etc/pam.d/system-auth
account [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_ldap.so

とりあえず明日試してみます。
0274名無しさん＠お腹いっぱい。2006/12/23(土) 00:17:53
なんだか面白い展開になってきたな。

俺的にはそれなりに参考になると思うので差し支えなければ
成功/鯖落/LAN断線それぞれの場合のログを見せてほしいな。

LDAPのヘルスチェックはLDAP鯖の方でやって
自動でプロセス再起動した方がいいんじゃないか？
落ちていたらメール以外でも支障が出そうだ。
0275名無しさん＠お腹いっぱい。2006/12/23(土) 00:46:54
シェルから id hoge とか実行してどういう応答が返ってくるか見てみると
いいんじゃないかと。あと、postmap -q hoge unix:passwd.byname とか。
0276名無しさん＠お腹いっぱい。2006/12/23(土) 10:40:00
id hoge || service LDAP restart
ってな感じか？異常終了してるならlockファイルの掃除など必要そうだが
02772532006/12/23(土) 21:34:46
>>273
>authconfigが自動的に作ったpamの設定を見ると、こんな設定がありますね。
>これを変更してみようか。

どうもLDAPの場合はpamは実質参照してないようです。/etc/pam.d/system-auth
からLDAPの行を消してもLDAPのユーザが見えます(?_?)

こちらにそのような記載があります。
http://www.linux.or.jp/JF/JFdocs/LDAP-Implementation-HOWTO/pamnss.html#AEN239
02782532006/12/23(土) 21:36:26
>>269
>>274
※正常に動作しているときのlog

postfix/smtpd[25126]: connect from 送信元ホスト名[送信元IP]
postfix/smtpd[25126]: D03EA558062: client=送信元ホスト名[送信元IP]
postfix/smtpd[25126]: disconnect from client=送信元ホスト名[送信元IP]

※LDAP daemonが落ちているとき。
LDAP daemonが落ちてからの経過時間により挙動が違う。

- LDAP daemonが落ちた直後にtelnetで叩いた時。
LDAPサーバへの再コネクトで約1分待ち、そして550を返す。送信元からの再送
は期待できない。

postfix/smtpd[25133]: connect from 送信元ホスト名[送信元IP]
postfix/proxymap[25127]: nss_ldap: reconnecting to LDAP server...
postfix/proxymap[25127]: nss_ldap: reconnecting to LDAP server...
postfix/proxymap[25127]: nss_ldap: reconnecting to LDAP server (sleeping 4 seconds)...
postfix/proxymap[25127]: nss_ldap: reconnecting to LDAP server (sleeping 8 seconds)...
postfix/proxymap[25127]: nss_ldap: reconnecting to LDAP server (sleeping 16 seconds)...
postfix/proxymap[25127]: nss_ldap: reconnecting to LDAP server (sleeping 32 seconds)...
postfix/proxymap[25127]: nss_ldap: could not hard reconnect to LDAP server - Can't contact LDAP server
postfix/smtpd[25133]: NOQUEUE: reject: RCPT 送信元ホスト名[送信元IP]: 550 (折曲げ)
<受信者メアド>: Recipient address rejected: User unknown in local recipient table; (折曲げ)
from=<送信者メアド> to=<受信者メアド> proto=SMTP helo=<送信元ドメイン>
postfix/smtpd[25133]: disconnect from 送信元ホスト名[送信元IP]
(続く)
02792532006/12/23(土) 21:37:37
- LDAP daemonが落ちて2-3分経過後の場合。
即時550を返す。送信元からの再送は期待できない。

postfix/smtpd[25133]: connect 送信元ホスト名[送信元IP]
postfix/smtpd[25133]: NOQUEUE: reject: RCPT from 送信元ホスト名[送信元IP]: 550 (折曲げ)
<受信者メアド>: Recipient address rejected: User unknown in local recipient table; (折曲げ)
from=<送信者メアド> to=<受信者メアド> proto=SMTP helo=<送信元ドメイン>
postfix/smtpd[25133]: disconnect from 送信元ホスト名[送信元IP]

※LDAP サーバからケーブル抜いた時

LDAPサーバへの再コネクトで約18分待ち、そして550を返す。多くの場合、送
信元のMTAがタイムアウトしていると思われるため、送信元からの再送が期待
出来る。

postfix/smtpd[25204]: connect from 送信元ホスト名[送信元IP]
postfix/proxymap[25205]: nss_ldap: reconnecting to LDAP server...
postfix/proxymap[25205]: nss_ldap: reconnecting to LDAP server...
postfix/proxymap[25205]: nss_ldap: reconnecting to LDAP server (sleeping 4 seconds)...
postfix/proxymap[25205]: nss_ldap: reconnecting to LDAP server (sleeping 8 seconds)...
postfix/proxymap[25205]: nss_ldap: reconnecting to LDAP server (sleeping 16 seconds)...
postfix/proxymap[25205]: nss_ldap: reconnecting to LDAP server (sleeping 32 seconds)...
postfix/proxymap[25205]: nss_ldap: could not hard reconnect to LDAP server - Timed out
postfix/smtpd[25204]: NOQUEUE: reject: RCPT 送信元ホスト名[送信元IP]: 550 (折曲げ)
<受信者メアド>: Recipient address rejected: User unknown in local recipient table; (折曲げ)
from=<送信者メアド> to=<受信者メアド> proto=SMTP helo=<送信元ドメイン>
postfix/smtpd[25204]: disconnect from 送信元ホスト名[送信元IP]
02802532006/12/23(土) 21:42:34
>>275-276
そのあたりが良さそうですね。LDAPの再起動についてなんですが、先日LDAPの
デーモンが落ちた時の原因はLDAPのデータベースが壊れたためでした。そのた
め無条件に再起動は少々問題があります。古いデータベースのrestoreが必要
なため、postfixを停止する方向で考えています。
(続く)
02812532006/12/23(土) 21:44:49
idコマンドを使ったテストを試してみました。

※正常に動作しているときの

% time id LDAP-USER || /etc/rc.d/init.d/postfix stop
約0.026秒でid コマンドが正常終了する。postfixは停止しない。

※LDAP daemonが落ちているとき。
% time id LDAP-USER || /etc/rc.d/init.d/postfix stop
約0.008秒でid コマンドが異常終了する。postfixが停止する。

※LDAP サーバからケーブル抜いた時
% time id LDAP-USER || /etc/rc.d/init.d/postfix stop
約2分でid コマンドが異常終了する。postfixが停止する。

※とりあえず出来る対策

1. LDAPサーバを2重体制にする。
2. IDコマンドを使ったテストをcrontabに仕込む
メールのロストを少なくするためには可能な限り短い間隔でテストする。しか
しLDAPのタイムアウトに時間かかるので、二重起動しない対策。本テストで
postfixが落ちた事を検出し通知する手を考える。

という所でしょうか。ホントだったらpostfixが検出してくれて自動的にエラー
コードを550から450に切り替えてくれたらいいんですけどね。
0282名無しさん＠お腹いっぱい。2006/12/24(日) 01:11:42
ちょwwwwおまえらwwwwwwwwwwwww

nss経由でLDAP叩いてるくせに、postfixに難癖つけますか、そうですか。
そんなもん、postfixが判断できるわけねぇだろ。

このばかちん！
0283名無しさん＠お腹いっぱい。2006/12/24(日) 01:37:14
PAMとNSSは別。idやPostfixのローカル配送はNSSの方。
02842532006/12/24(日) 02:06:23
>>282
まぁ、そうだな。ソース読むと、UNIX認証の場合はgetpw* 経由で読んでいる。こいつの
返値しか見てない。

LDAPのヘルスチェックは無理。
http://www.linux.or.jp/JM/html/LDP_man-pages/man3/getpwent.3.html

というかpostfixでLDAPを直接参照する方法がよくわからない。にょろーん。
バーチャルドメインの設定例は良くあるけどね。
0285名無しさん＠お腹いっぱい。2006/12/24(日) 02:24:09
>>282
いや、だから>>271の時点でばっさり切り捨てているでそ。
それ以後、まともな人はもう相手してない。
0286名無しさん＠お腹いっぱい。2006/12/24(日) 08:45:34
253と284が見えない
0287名無しさん＠お腹いっぱい。2006/12/24(日) 12:28:26

　　　　　　　　　　 　 -‐ '´￣￣｀ヽ､
　　 　 　 　 　 　 ／　／" ｀ヽ ヽ　　＼
　　　　　　　　　//, '/　　　　 ヽﾊ 　､　ヽ
　　　　　　　　 〃 {_{　　　 　　　ﾘ| ｌ.│ i| 　に
　　　　　　　　 ﾚ!小ｌノ　　　 ｀ヽ 从　|、i|　　ょ
　　　　　　　 　 ヽ|l　●　　　●　 |　.|ﾉ│　 ろ
　 　 　 　　　　　 |ﾍ⊃ ､_,､_,⊂⊃j 　|　, |.　　l
　　　　　　　　　　|　/⌒l,､ __,　イァト |/ |　 ん
.　　　　　　　　　 | /　 /::|三/::/／　 ヽ |
　　　　　　　　　 | |　　l ヾ∨:::/ ヒ::::彡, |
0288名無しさん＠お腹いっぱい。2006/12/24(日) 15:41:54
>>284
一体何のためにソース読んでる？　おまいの目はフシアナですか？
スグ隣に、dict_ldap.c/hがあるだろ！！
0289名無しさん＠お腹いっぱい。2006/12/25(月) 10:37:15
>>268
できたっぽいです。
ありがとうございます。
0290名無しさん＠お腹いっぱい。2006/12/25(月) 14:16:11
postfix-2.2.10使っています。

ヘビーユーザーがいるのですが、ヘビーユーザーのメール管理者から
「短時間に大量のメールを送るのはやめて下さい」
といわれてます。だいたい数万通のメールを飛ばしているらしいです。
＃トラップを飛ばしている

該当ユーザに、そんなに大量のメールを送る設定はやめなさい、という以外に、
何かのオプションで流量制限、もしくは遅延させることができないでしょうか？
0291名無しさん＠お腹いっぱい。2006/12/25(月) 14:40:49
>>290
spam業者は即刻アカウント削除
02922902006/12/25(月) 14:55:31
spam業者ではないです、一応…
あれもこれも必要なメールらしいですし
＃どちらかというとDoSかも
0293名無しさん＠お腹いっぱい。2006/12/25(月) 15:11:53
そいつは s p a m 業者だ！疑いの余地無し！人類の敵を抹殺せよ！
0294名無しさん＠お腹いっぱい。2006/12/25(月) 16:21:27
>ヘビーユーザーのメール管理者から
>「短時間に大量のメールを送るのはやめて下さい」
>といわれてます。

じゃあ 290 は一体何者なんだという疑惑
0295名無しさん＠お腹いっぱい。2006/12/25(月) 16:37:58
質問です。
qmgrデーモンがキューからピックアップする際にmaillogに吐く
nrcpt=
の数字は、localやsmtp,virtualなんかに送るメールの数という認識でよいでしょうか？

この辺のステータスについて解説されている資料などありましたらご教授頂けると幸いです。
宜しくお願いいたします。
02962902006/12/25(月) 17:04:16
日本語が変でした

漏れ: サービス系メールサーバの管理者の1人
メール管理者: OA系メールサーバの管理者

サービス系のメールサーバは基本的に送信専用です。普段ログインしない。
OA系のメールサーバのメールは普段読む。
よって、サービス系の中で起こった事は、メールを飛ばして、
サービス系メールサーバ → OA系メールサーバ→ヘビーユーザのクライアント
と流れます。
OA系メールサーバが非力なのか、落ちてしまうようです。
そこで、ヘビーユーザがメールしかける場所を減らす様努力中ですけど、
その他、サービス系メールサーバで絞れないかと。
0297名無しさん＠お腹いっぱい。2006/12/25(月) 17:12:49
spam業者乙
0298名無しさん＠お腹いっぱい。2006/12/25(月) 17:25:51
>>296
数万通というのが時間当たりの単位なのか判りませんが
一般ユーザからすると通常ありえない運用の仕方ですよね。
言われてるように、そのユーザ自身がスパム業者かBOTネットの一員になってるとしか思えないのですが。。。

トラップが飛ぶような仕組みになっているなら、下記資料を参考に
動的にルールセットを切り替える仕組みを作ればいいのではないかと思います。
ttp://www.kobitosan.net/postfix/archives/faq-jp-20010228pl02.html#relay_restrict

>>297
そういった非生産的な発言は控えて頂きたい
0299名無しさん＠お腹いっぱい。2006/12/25(月) 17:27:03
spam業者を支援する人もspam業者です。
0300名無しさん＠お腹いっぱい。2006/12/25(月) 17:28:02
290がノイローゼになったあげくにサーバを破壊して自殺するのがベストの解決
0301名無しさん＠お腹いっぱい。2006/12/25(月) 17:53:27
メールでsnmpのトラップでも飛ばしてるんでしょ？
そりゃ数万通ぐらい平気で飛ぶわな。
サービス系メールサーバで異常時だけOA系メールサーバへメールを
飛ばすようなプログラムを仕込んでおくのがいいと思うよ。
0302名無しさん＠お腹いっぱい。2006/12/25(月) 18:04:06
>>299　>>300
何なんだお前ら
さっさと死ね
お前らの発言はspam並みに役経たず＆不快だ
0303名無しさん＠お腹いっぱい。2006/12/25(月) 18:20:27
煽りに乗ったら負け。
0304名無しさん＠お腹いっぱい。2006/12/25(月) 18:32:05
しかしうさん臭い
■ このスレッドは過去ログ倉庫に格納されています