Note that only FEATURE(`enhdnsbl') uses a DNS map. We do not have an assessment whether this problem is exploitable, however, if you use a DNS map and an 8.12 version older than 8.12.9, then either upgrade (strongly recommended) or apply the trivial patch given below.
実行可能かどうかはまだ分っていないはず (スコア:4, 参考になる)
とある通りですが、自分の Sendmail が DNSMAP オプション付きでコンパイルされているかどうか、また enhdnsbl 機能を使っているかどうかも判らない人がメールマスターをやっているなら、今回のはバグには違いないので
ただのちゃちゃ (スコア:0, フレームのもと)
どうしてこう (スコア:1, すばらしい洞察)
私はそういう雰囲気がいやでpostfixを使っているクチですが。
何にせよ選択肢があるのは良い事です。
#qmail信者に刺されるのがいやなのでAC
Re:どうしてこう (スコア:1)
下手な営業と同じで, 困っている人に解決策を与えるのが目的ではなく, qmailを使わせることが目的の様に見えますからね. この記事みたいに他のMTAが話題になっていても, 何の前提も出すことなくqmail使えじゃ信者呼ばわりされても仕方ないように私も思います.
Re:どうしてこう (スコア:0)
おまけに設定が難しいという話も良く聞きます。
一方qmailはそういう話を聞いたことがありません。
それでもsendmailを選択する人が多くいるのは何故なんでしょうか。
想像するに、
Re:どうしてこう (スコア:1)
qmail の場合は RCPT の段階で local user の存在をチェックして reject できないので、嘘の envelope from で流されて対象ユーザがいない場合に error mail のループに陥りやすいとか、そういった事を理解していないと使えないかと思います。
sendmail は、少なくとも MAILER(local) はこれを行います。(Cyrus IMAPd を使うと qmail と同じように取り込んでしまうのですが)
sendmail の設定が難しいというは過去の話だとしか思えません。普通 .mc から生成でしょ。
配送性能の優位性を誇る、と言っても相手が受けきれなかったら全く意味がありませんし、同一ドメインへのまとめ送りを標準でサポートしない qmail はどうなのよ、という気もします。社内サーバとかで、ほとんど流れるメールが同一ドメインなどだと、無駄にトラフィック発生しまくりで嫌すぎ、とか十分あり得ます。
qmail の場合、ポリシーに従って使う場合、標準のまま使う人はそうそういないので patch を当てまくって使う場合なども多いわけですが、patch の全ての内容をチェックして、system call 置き換えるの? とかまで拘らないとダメなのでは、とか考えさせられます。
いわゆるイマドキの機能を使いたい、という場合には、qmail では patch を当てて……から始まるので、結構きついです。
似たようなことをする patch が複数あり、それぞれを評価して……とかになってくると、qmail のシンプルさの優位点などというのは存在しないように思えます。
djb の主張に従って使うのであれば、複雑な TLS なんて使いたくないとかになるでしょうし、TLS 周りの実装を OpenSSL を利用せずに djb の主義にしたがって再実装とかまでやるとしたら……非現実的すぎますね。
あと、FreeBSD 辺りだと /etc/mail で make cf install で sendmail.cf/submit.cf をさくっと生成してくれるとか、その辺りのワークフレームが標準提供されているのは非常に便利です。下手すると qmail より設定は少ないかもしれません。
ports ではなく、contrib の範囲に関しては gshapiro [gshapiro.net] がメンテナンスしてるので安心感があります。多分 sendmail を利用する場合、一番幸せな環境。ports から入れていても、このワークフレームはそのまま利用できます。
TLS + SMTP AUTH 辺りまでの要求であれば Postfix でもいいのですが、+IPv6 となるといきなり Postfix はこける (TLS + IPv6 がどうにも……) などの理由から、Postfix は未だに現実的な評価ができません。
用途に応じて、qmail の方が長けている場合も十分にありますから一概に否定する気はありませんが、私は qmail から sendmail に移行しました。
Re:どうしてこう (スコア:1)
＞普通 .mc から生成でしょ。
.def にしろ .mc にしろ、十分難しい存在だと思います。
あなたの言う「過去」は .cf を自前でかく話ですか？
もしそうなら戻りすぎですし、そうでないならsendmailに習熟しているからこそ出る台詞ではないでしょうか。
必ず.mc → .cf という手順を踏むことに十分なメリットがあるとはどうしても思えません。
.mcから生成できない設定がしたければは結局.cfを編集することになり、cfが出力する書式が変わればそれを追いかけねばなりません。
# sendmailは万能ナイフで逆に扱いづらく、
# qmail は理想ばかりで現実的メリットが言う程じゃないと感じたのでpostfix使ってます。
# rm -rf ./.
Re:どうしてこう (スコア:1)
教育用計算機センターのアカウントから別ホストで qmailで運用している クラスMLとかサークルMLに記事を投稿すると。。。 たとえば80人登録されていると（全員センターのアカウントが 登録されているので）80倍のトラヒックになって帰ってくる。 さらにそれにウィルスが付いていると、センターのメールサーバから ウィルス検知報告メールが80通システム管理者に送られる。 などと、システム管理者が愚痴ってました。
sendmail.cfの生成は昔より楽になったけど、一般論としては まだ結構大変だと思いますよ。 しかし、生成しないといけないような複雑な運用をしている マシンの割合は少ないと思いますが。たいていは、添付の client.cfをそのままつかうとか、中の 「自分のFQDN」定義の １行だけエディタで書き換えれば済むとおもうのですが。
しかし、sendmail.cfは難しくてと主張している人のうち sendmail.cfに実際に挑戦してみて難しいと体感した人は 何割居るのでしょうか？多くは誰かに言われたのをそのまま オウム返ししてるだけじゃないの？
Re:どうしてこう (スコア:0)
Re:どうしてこう (スコア:1)
sendmail.cfは文法はシンプルだしね。下手なアセンブラの方が syntaxは複雑かも。
Re:どうしてこう (スコア:1)
私が言っている過去は、CF の頃です。CF 自身が sendmail に追従するまでは、.cf 自体を弄らなければいけないのはこの頃でしょう。
現状の cf は標準配布物で提供されていて、基本的には作者側が自分達で管理する上で使いやすいツールを提供しているので、追従されないということは考えにくいものです。ドキュメンテーションが追い付いていないというのは実際にありましたが。
.mc から生成できない設定というものに遭遇したことはありませんが、どのような内容のことを言われているのでしょうか。LOCAL_* などを使っても対応しきれない世界というのが、ちょっとわかりません。
一般的に利用される機能関係については、FEATURE で簡単に有効にしたりなどができるわけで、大抵は .mc 中に 1 ～ 数行程度の指定しか書かないと思います。
標準配布物に patch を当てずに各種機能を利用したい (当て忘れの防止などよりも、バージョンアップ時などの追従に関する時間差や、patch を探す手間の問題) という要求はあるわけで、そう考えると、Postfix も十分ではないかと思います。qmail ほどではありませんが。
security hole が見つかった時に、patch 待ちなので update できませんとか、一時的に機能が低下しますとか、そんなこと言えるわけがないので。
cf を使った管理は qmail より楽、というのが実体験上からの経験でしょうか。参考になるというかそのまま書き写してしまえば終わるようなレベルの記事 [imasy.or.jp]が存在するのも理由ですけど。