Anonymous Coward曰く、"NetBSDのソースツリーにはMTAとしてsendmailとpostfixが取り込まれており、設定ファイルで切り替えて使うように設計されています。ですが 5月29日にCoreグループ(NetBSDプロジェクトの取締役会のようなもの、詳しくはリンク先参照)からの連絡として、ソースツリーからsendmailを外したというメールがながれました。脱sendmailの流れは加速していくのでしょうか。
- CVSツリーからFileRemoveが告知されたメール
- CVSWEBでの該当場所
なお、NetBSDでは何年か前のエイプリルフールネタでsendmailを捨てましたというメールが流れましたが、今回は本当のようです。"
OS付属のMTAとして (スコア:2, 興味深い)
こういうのはメールサーバを構築しなくてはならない人が使えばいいのであって、そうでないホストにはオーバースペックではないのかとずっと思ってました。
ローカル配送と外部SMTPへの接続だけやってくれるような小さいperlスクリプトなんかがあればいいのかなあ、と思ったりもするのですが。
Re:OS付属のMTAとして (スコア:3, 興味深い)
BSD 使うからにはメールサーバー程度、個人でも設定して使ってても普通かな、と感じてしまいますが
> 外部SMTPへの接続だけやってくれるような小さいperlスクリプトなんかがあればいいのかなあ
逆説的だけど、「その程度は MTA 設定すりゃ済む話」なわけで。
そんなに MTA を恐れなくてもいいんじゃないかな。
Re:OS付属のMTAとして (スコア:1, すばらしい洞察)
Re:OS付属のMTAとして (スコア:3, 参考になる)
明示的にコメント解除してsmtpdを有効にしない限りは外部からのsmtp接続は受け付けません。
> ローカル配送と外部SMTPへの接続だけやってくれる
という状態になっておりお望みの状態に近いかと思います。
Re:OS付属のMTAとして (スコア:0)
IP Messengerみたいので事足りるケースだってあるし、まったく必要ない人だっているし。
選択オプションとしておいたほうが賢いと思うがな。
Re:OS付属のMTAとして (スコア:0)
それを言い出すと宗教戦争的な方向にしかいかない気がするけど．
伝統的ないわゆるUNIX環境について考えた場合，動作はしてなくてもパッケージとしてMTAが存在することは必要だと思うけどなぁ．どうせ皆がbashやtcsh使うからって/bin/shを無くしたら困るっしょ？どうせemacs使うからってvi無くしたら困るっしょ？/usr/binとか/binとかには俺は一度も使ったことの無いコマンドなんて腐るほどあるけど，そいつらをrmする勇気は無いぞ．
まぁHDDが1MB=1万円とかならまだしも，このご時勢なんだからMTAくらい入ってたって良いじゃない．で，伝統的にはsendmailが入ってるのが一般的だったワケだけど，そのあたりの妥協案として別のMTAを入れるってのもアリだと思う．もちろん，「デフォルトで謎の設定のまま動作してる」なんてことが無い前提でね．
Re:OS付属のMTAとして (スコア:0)
Re:OS付属のMTAとして (スコア:0)
Re:OS付属のMTAとして (スコア:1, 参考になる)
が今風の書き方なのでこっちのほうを使いましょう。
Re:OS付属のMTAとして (スコア:0)
Re:OS付属のMTAとして (スコア:0)
Re:OS付属のMTAとして (スコア:0)
けどMTAは適切な設定も必要だし、してもメール周りはSMTPで配送受けるよりは
POPなりなんなりでプロバイダに取りにいく環境作ることの方が多そうな気が。
この取りに行く環境にはSMTP送信が含まれることが多そうだし。
マルチユーザで使うならあってもいいけど(メールでやり取りもあるだろうから)、
個人利用だといらないしねぇ。
入れちゃってるならセキュリティのメンテもいるし、
手間が掛かる割には得るものが少ないというのが感想。
(debianのeximも邪魔なんだよな……)
Re:OS付属のMTAとして (スコア:1)
FreeBSD なんかだと、デフォルトでは root が日/週/月次レポートを送る関係上配送デーモンは上がりますが、受信用のデーモンは上げないので、比較的最小限の設定で入ってたりします。
というか、さすがに最近は MTA を入れていても、こうした上げ方をデフォルトにしてるのが普通と思いますが。
このレポートの送り先を変えたい場合でも /etc/mail/aliases を書き換えて /etc/mail で make 叩く程度だし、わざわざ入れ替える手間まで費やして、配送専用の小さなものに変えるとかはして欲しくないですね。
受信用にも使ってるから、sendmail 抜かれたらわざわざ入れないといけなくなるし。
Re:OS付属のMTAとして (スコア:1)
配送デーモンが標準で上がるのはいまいちだと思いますけどね。
MTAなしで運用できるのが標準になると一番嬉しい。
私は /etc/periodic.conf に以下の設定書いて
レポートメールを出さないようにしてます。
daily_output="/var/log/daily.log"
weekly_output="/var/log/weekly.log"
monthly_output="/var/log/monthly.log"
最近 root にメールがくる場面は at コマンドで
時刻指定のコマンド実行した時かな。
Re:OS付属のMTAとして (スコア:0)
Re:OS付属のMTAとして (スコア:0)
Re:OS付属のMTAとして (スコア:0)
Null Mail ClientとフルスペックのMTA、どちらのコードの方が安全性を検証しやすい?
Null Mail ClientとフルスペックのMTA、どちらの方が設定ミスを起こしやすい?
Null Mail ClientとフルスペックのMTA、普通の環境（多数決的に）でどちらの方が圧倒的にニーズが多い?
普通は賢いMTAはいくつかあれば十分でWebサーバはもちろん、LDAP, DNSサーバにフルスペックのMTAなんて必要性はまったくありません。と言うか必要な設計だったら設計が間違っているでしょう。
Re:OS付属のMTAとして (スコア:0)
そういうディストリビューションがあってもいいとは思うけど、少なくともNetBSDはそうじゃないってだけのことだろ。
Re:OS付属のMTAとして (スコア:0)
＃今は使ってないのでAC
Re:OS付属のMTAとして (スコア:3, すばらしい洞察)
それこそ自分で書く/探すってのが想定された姿では？
「標準品」である以上どちらの形態でも動作可能なもの
が入ってるのは正しいありようだと思います。
どちらかの動作しか出来ないものが標準なのはおかしいし
特殊用途向きの限定品こそユーザー独自で設定/作成すべき。
発想が逆だと思いますよ。
個人的にはいいところも悪いところもよく知られたMTAを
様々な検証もなされた類例どおりに設定するほうが
必然的に検証者の少なくなるマイナーor自作なスクリプトより
理論上の可能性はともかく実用上は
よっぽど安全（に近づけやすい）と思います。
Re:OS付属のMTAとして (スコア:1, オフトピック)
---にょろ～ん
Re:OS付属のMTAとして (スコア:1)
---にょろ～ん
Re:OS付属のMTAとして (スコア:1, おもしろおかしい)
Re:OS付属のMTAとして (スコア:1, 参考になる)
いまどきの Linux ユーザの感覚では理解できないのかもしれませんが、
NetBSD には perl は付属しません (pkgsrc から入れることはできます)
必要ない人は入れないのが普通なんです。
Re:OS付属のMTAとして (スコア:0)
たしかに・・・ (スコア:0)
FreeBSDも5.Xまではいろいろてんこもりでしたが
FREEBSD6.Xからはいろいろ削除されていたり
してた
qmailに出来ればいいのにね (スコア:1, 興味深い)
Re:qmailに出来ればいいのにね (スコア:5, 参考になる)
Re:qmailに出来ればいいのにね (スコア:1)
sendmail環境からの移行・併設を考えるとPostfixってことになるのでは.
Re:qmailに出来ればいいのにね (スコア:0)
Re:qmailに出来ればいいのにね (スコア:2, 参考になる)
設定の手引きがあまりないんでとっつきにくい以外は良いと思いますよ
使い込んでるわけじゃないので詳しいところはわかりませんが。
LAN内LAN稼働中
Debian で exim4 (スコア:2, 参考になる)
設定した当時は日本語での情報が著しく少なかったので、
SMTP AUTH の設定でえらく苦労してました、、、
機能的には、mbox でも Maildir でも行けるし悪くないんですけどね、、、
最近、ISP 各社が OP25B なんて無駄な物導入し始めたおかげで、
近々設定し直さないといけないような気がしてきたのですが、
面倒だなぁ、、、と、、、
OP25B なんて、どう考えても一時しのぎだし、
key logger + sniffer 搭載の高機能 ワーム or ウィルス等の一般化を早めるだけでしょう、、、
# 最近の spam は 1 通毎に送り元が違うみたいなので、
# どうも botnet 経由で送られているのではないかと疑っているので、、、
uxi
Re:Debian で exim4 (スコア:0)
>OP25B なんて、どう考えても一時しのぎだし、 >key logger + sniffer 搭載の高機能 ワーム or ウィルス等の一般化を早めるだけでしょう、、、
普通にISPに入会したとして、宛先ドメインのMXに直接SMTP接続してスパムメールが簡単に送れる環境と、key loggerやbotなどつかって、パスワード窃盗したうえでないとスパムメールが送れない環境はまったく違うとおもいませんか？
OPB25のあとは、SMTP AUTHを実施した上での、認証者ID毎のメッセージ送信通数制限というものがあるわけで、bot経由のスパムもある程度おさえることができるでしょう。
完全にオフトピになってしまったが、、、 (スコア:0, フレームのもと)
短期的視点で単純な攻撃が減ったところで、
馬鹿どもが変な技術つけるほうがよほど脅威に感じるわけ、、、
OP25Bにより奴らの第一目標は確実にIDとパスワードになるんだぞ？
分かてんのか？そこん所？
オープンリレーとは
脅威のレベルが違いすぎるんだよ、、、
uxi
Re:完全にオフトピになってしまったが、、、 (スコア:0)
今の状況、IDやパスワードはそれほど狙われてないと思ってます？
様々な認証やPKIが普及してきたから、消去法的に対策の行われてない(素の)SMTPが狙われてるだけなんですよ。
# PKI って使ってみたかっただけなのでAC
フレーム上等だyo＞モデ (スコア:1, フレームのもと)
フレームの元かよ、、、
問題の深刻さが分ってないだろ、、、＞モデ
この際なので、問題点をはっきりさせておく。
AC氏は、
>ID止めるだけでspam防げる
と言うが、残念ながら現状では一般のユーザーのリテラシーはそれ程高くない。
ID止めるって行為は、踏み台にされた事が判明したから出来るわけであって、
それが分るユーザーばかりならば、ここまで botnet がはびこるわけがない。
加えて、
>今の状況、IDやパスワードはそれほど狙われてないと思ってます？
ってのは、狙われてはいるが、
それは一般の spammer よりも、
もっと技術力もあり悪質な連中。
一般の spammer の場合、
あまり高度に技術力を駆使出来無いため
狙いは DM の配布手数料だとか、
せいぜいソーシャルエンジニアリングによるフィッシング止まりであるが、
より高度で悪質な連中は、もっと直接的に我々の懐を狙う事が出来る。
少なくとも一般の spammer のビジネスモデルの範疇では
メールが送れさえすれば良いため、
>消去法的に対策の行われてない(素の)SMTPが狙われてるだけなんですよ。
で十分な結果が得られるため、
わざわざIDやパスワードを得るために面倒な仕掛を講じる必要がないのが
現状であると思われる。
ところが、OP25B により、
一般の spammer もIDやパスワードを盗まなくては spam が送れなくなってしまうと、
奴らの第一標的がIDやパスワードへとシフトしてしまう。
奴らがIDやパスワードを手にした場合、
どういう結果をもたらすかは想像に難くないだろう、、、
もちろん、これは時間の問題であり、
OP25B を実施しなくとも、いずれは来るべき未来ではあるのだが、
少なくとも OP25B により、その到来が前倒しにされるのは確実だし、
IDやパスワードを抜かれれば OP25B の有効性も皆無になる事は疑いようもない。
結局、OP25B なんてのは、一時しのぎに過ぎず、
その結果は spammer 以外を幸せにしないんだよ、、、
uxi
自分のフリ見て我がフリ直せ (スコア:1, すばらしい洞察)
#951657 [srad.jp]から#951694 [srad.jp]への文体の豹変や、#951776 [srad.jp]の冒頭の悪態等、通して見るとなんかサスペンスで犯人が本性をあらわしたみたいな感じで結構笑えるモノがあるから「おもしろおかしい」モデでもいいかもしれんけどね。
＞問題の深刻さが分ってないだろ、、、＞モデ
人に文章を読んでもらう時の態度を分かってないだろ、、、
と内心思ったヤツもいると思うぞ？
OP25Bは犯罪者を国外追放する対策方法だ (スコア:0)
> それが分るユーザーばかりならば、ここまで botnet がはびこるわけがない。
ISPにとってはISPのメールサーバーが踏み台にされた方が対策はとりやすいと考えられる。
電気通信事業者法により、通信の秘密を犯してはならないというルールがあるのでお客さんのボットネットに参加させられていたとしても基本的にはそれを監視、抑止することはできない。
つまり、TCP port 25の通信の内容を見て、迷惑メールに多く出てくるキーワードだから送信禁止という手法はとりにくい。
また、顧客の通
Re:フレーム上等だyo＞モデ (スコア:0)
そんなわけねーだろ。すくなくとも、手軽にお金がもうかるからスパムうってるレベルの奴らをスパム打たせなくする効果はある。ID盗めるぐらいの技術があったら他のデータ盗んで売るだろ。
>少なくとも OP25B により、その到来が前倒しにされるのは確実だ し、IDやパスワードを抜かれれば OP25B の有効性も皆無になる事は疑いようもない。
どこらへんが、どう確実なんだか。他のだれかもい
Re:フレーム上等だyo＞モデ (スコア:0)
>>ID止めるだけでspam防げる
>と言うが、残念ながら現状では一般のユーザーのリテラシーはそれ程高くない。
>ID止めるって行為は、踏み台にされた事が判明したから出来るわけであって、
>それが分るユーザーばかりならば、ここまで botnet がはびこるわけがない。
ユーザが、じゃなくて「ISP側でID止めれば(メール送信できなくなるので)」送信者受信者
の被害が低減できる、って事です。
>>今の状況、IDやパスワードはそれほど狙われてないと思ってます？
>ってのは、狙われてはいるが、
>それは一般の spammer よりも、
>もっと技術力もあり悪質な連中
Re:Debian で exim4 (スコア:0)
OP25B 対応をしなくちゃならない「気がする」ってもね。
自分の ISP のサービス内容を見て、変更する／しないだけじゃないの？
exim 使う理由 (スコア:1)
結局、調べる必要があるなら、どれでも同じって感じで、
exim にした事には、そんなに深い理由はないよ。
強いて言えば Debian のデフォルトだからって理由が一番大きいかもしれないけど。
# 逆に言えば、Debian 使ってなければ exim は使ってなかったと思う。
# おいらは、アップデートを自動でやってもらって手間を省き省きたいので、
# なるべくデフォルトの設定をいじらないって運用方針でやってるから。
まぁ、日本でこそマイナーではあるけど、
つまりは、それなり評価されてるって事だし、
少なくとも Debian ではメンテも積極的に行なわれてるって事の現れとも取れる。
それに、もし MTA としてもマイナーであるなら、
攻撃対象とされる確率が低く見積れるはず。
OP25B がらみの設定の問題で面倒なのは、
ポート2つ開く必要があるって点。
結構デフォの設定からいじらないといけないよね。
exim の設定ファイルに数行加えればで済む話なのか、
別にもう1つ設定ファイル作って、
init.d スクリプトでもう1つサービス立ち上げる必要があるのか、
その辺りの調査がまず面倒だよね、、、
もちろん、アップデートの際の面倒事にも繋がるしさ。
ディストリビューションが OP25B 前提で
デフォの設定やってくれてれば楽だけどさ、、、
そういうディストリビューションってもうあったっけ？
少なくとも、今の時点では、
ISP の思惑と、ディストリビューターの方針には温度差があるんでないかな？
uxi
Re:qmailに出来ればいいのにね (スコア:0)
debian も postfix に変えようという話が何度か出てたと思います。
ただ、標準の mta を選択したとき postfix はまだ枯れてなかった (だったかな?)、
そして、乗り換える積極的な理由が今ひとつない (exim で困ってない) から変えないとか、
なんかそんな話だったような。
以上、くわしくない人間の曖昧な記憶です。
まちがってたらゴメンなさい。
# weekly news あたりを検索するだけでソースが見つかりそうだけど、
# それすらもめんどうなので AC。
ちなみに、うちも woody から debian 使ってるんですが、
インストール後、即座に postfix にしたクチです。
Re:qmailに出来ればいいのにね (スコア:0)
qmail関連は関係が有るので AC
Re:qmailに出来ればいいのにね (スコア:0)
もうとっくに (スコア:0)
Re:もうとっくに (スコア:3, すばらしい洞察)
メジャーなディストロがサポートをやめることは
大きな違いがあると思う。
robustness (スコア:0)
Re:robustness (スコア:3, 参考になる)
まあ 1000人程度の会社なので、たいしたトラフィックじゃないですけど。
それ自体は見てないんですが (スコア:0)
はsendmailで送信されたんでしょうか？