qmailいろいろ(8) - 暇つぶし2ch

qmailいろいろ(8) ..

237:名無しさん＠お腹いっぱい。
07/10/20 10:09:15
>>234
まぁExchangeやnotesは1通しか来ないからなぁ。

238:名無しさん＠お腹いっぱい。
07/10/20 11:05:25
>>235-236
thx．

ケータイからもアクセスしたいってのが要望としてあるので、
今回は自前で作ることに。

Perlかなんかで簡単に済まします。

239:名無しさん＠お腹いっぱい。
07/10/20 12:24:26
>>238
keitai webmail とかそんな名前のヤツがあったハズ。

240:名無しさん＠お腹いっぱい。
07/10/20 15:29:09
>>239
ｍｊｓｋ！

ﾄﾝｸｽ。

241:名無しさん＠お腹いっぱい。
07/10/23 13:08:43
すいません　質問させて下さい

maillogの中の、
delivery 1111: success: did_0+0+0/

この　did_0+0+0/ の部分、３つの0 or 1が入る部分は
何を意味しているのでしょうか？

242:名無しさん＠お腹いっぱい。
07/10/23 14:22:53
順番に、ふつーにメールボックスに保存された数、
別のアドレスに転送された数、プログラムに渡された数。

0 or 1 ではなく、.qmail の記述によっては2以上になることもある。

243:241
07/10/23 18:42:03
ありがとうございます

244:名無しさん＠お腹いっぱい。
07/10/23 20:14:17
恐れ入りますちょっと質問させてください
qmail + vpopmailの環境で運用しています。

最近プロセスを見ると、

qmaild　/var/qmail/bin/qmail-smtpd
　や
qmailq　bin/qmail-queue

が大量にプロセス上に発生しており、
SMTPコネクションが足りなくなる事態が発生しています。

maillogを見ると、自ドメイン宛のスパムメールのようです。
（うちのドメインがexample.jp宛だとすると、存在しないxxxx@example.jp宛に大量メール）

ちなみにエラーメールは
「| /var/vpopmail/bin/vdelivermail '' delete」
として返らない設定にしているつもりです。
対策方法をご存じの方がいましたら教えてください。

245:244
07/10/23 20:22:47
>>244

追記です。

ちなみにオープンリレーのテストはパスしたので、
誰かにメールを撒かれまくっているという状況ではないようです。

246:名無しさん＠お腹いっぱい。
07/10/23 22:39:16
greylist+s25r

247:名無しさん＠お腹いっぱい。
07/10/24 16:25:09
qmailの大きな弱点のひとつ、存在しないアドレス相手にSMTP段階でbounceができないというものだね。
qmail-sppのプラグインなどで対処可能。
たとえば、 URLﾘﾝｸ(www.maiers.de)

248:244
07/10/24 17:37:41
>>246-247
ありがとうございます。

ひとまずconcurrencylocalとconcurrencyremoteを増やして応急処置してみました。
近々根本的な解決をしたいと思います。

249:名無しさん＠お腹いっぱい。
07/10/30 00:51:53
antibadmail つかってみ。
誤認が気になるなら、デバッグモードでコンパイル。
Rejectをキーにログ見てホワイトリストをつくればよろし。

250:名無しさん＠お腹いっぱい。
07/10/30 22:00:59
FreeBSD　でqmail を使用しているのですが /var/log/maillog に以下のような
メッセージが出てきました。

alert: unable to opendir mess/0, sleeping...
alert: unable to opendir mess/0, sleeping...
alert: unable to opendir mess/0, sleeping...
alert: unable to opendir mess/0, sleeping...
alert: unable to opendir mess/0, sleeping...

/var/qmail/queue/mess/0 を開けずに出力されているメッセージかと
思いパーミッションなどを確認してみたのですが設定は合ってそうです。

drwxr-x--- 11 qmailq qmail 512 Oct 30 21:08 .
drwxr-xr-x 12 root qmail 512 Oct 30 21:29 ..
drwx------ 2 qmails qmail 512 Oct 30 21:52 bounce
drwx------ 25 qmails qmail 512 Oct 30 21:08 info
drwx------ 25 qmailq qmail 512 Oct 30 21:08 intd
drwx------ 25 qmails qmail 512 Oct 30 21:08 local
drwxr-x--- 2 qmailq qmail 512 Oct 30 21:08 lock
drwxr-x--- 25 qmailq qmail 512 Oct 30 21:08 mess
drwx------ 2 qmailq qmail 512 Oct 30 21:52 pid
drwx------ 25 qmails qmail 512 Oct 30 21:08 remote
drwxr-x--- 25 qmailq qmail 512 Oct 30 21:08 todo

どなたか、アドバイス頂けませんでしょうか。

251:名無しさん＠お腹いっぱい。
07/11/04 18:08:58
fsck かけてみるとか

252:名無しさん＠お腹いっぱい。
07/11/09 17:23:06
virtualdomainsで

user@unko.net:test

と設定した場合、
user-可変文字列@unko.net 宛のメールって受信できます？
.qmail-user や .qmail-default 置いても受信できない…

253:名無しさん＠お腹いっぱい。
07/11/12 23:52:26
qmailの設定なんだが最初からサーバーに入ってたため設定がイチマイチわからん…

.qmailってのはどこに置けばいいんですか？

qmailの位置は /var/qmail です。

254:名無しさん＠お腹いっぱい。
07/11/13 00:22:28
ホームディレクトリ

255:名無しさん＠お腹いっぱい。
07/11/13 01:37:57
>>252
MXはあってるのだろうな？
rcpthosts とか、localsチェックしたか？
場合によっちゃ、/var/qmail/users/assign を弄る必要アリ。

256:名無しさん＠お腹いっぱい。
07/11/13 21:30:41
>>254
各ユーザーのディレクトリって普通どこにあるもんですか？
色々徘徊してみたがわからない…

/var/qmail/users にあるかと思ったんだがそこになかったもので

257:名無しさん＠お腹いっぱい。
07/11/13 21:32:15
あと/homeかと思ったんだがそこにはアドレスごとのアカウントはなかった。

258:名無しさん＠お腹いっぱい。
07/11/13 21:41:36
情報不足で状況が全然分からんから先に進まないと思う。
まぁ、/home/以下にないんだったら、qmail-vidaとかが導入されていて
/home/pop/か/home/vpop/にあるんだとおもうけどね。

259:名無しさん＠お腹いっぱい。
07/11/13 21:46:55
>>258
うーん…/home/popとかはないですね。
/homeの中に一応ユーザーっぽいのはあるんですが
メールアドレスのアカウント名と違うんですよね。

どのような情報があれば良いでしょうか？

260:名無しさん＠お腹いっぱい。
07/11/13 21:59:14
>>259
君にはメールサーバのメンテは敷居が高いと思うから
然るべき所・人に対価を払ってやってもらった方が良いと思う。

261:名無しさん＠お腹いっぱい。
07/11/13 22:10:11
>>260
そう言われてしまうと何も言い返せないんですが
一応やりたかった事だけ書いておきますね。

.qmailを使ってメールがきたらphpを起動するって事をやりたかったんです。

解答ありがとうございました。

262:名無しさん＠お腹いっぱい。
07/11/13 22:13:02
>>261
久々に言おう

　　　　　　　　　　コ　　ン　　サ　　ｒ（ｒｙ

263:名無しさん＠お腹いっぱい。
07/11/13 22:58:43
rcスクリプトを探しまわしたりpsしてqmail-smtpがどのような環境変数を与えられて
動いているのか確認すれば、後はそれを追いかけていけば済む話なのに…

264:名無しさん＠お腹いっぱい。
07/11/14 08:17:49
/var/qmail/alias に置くのではいかんのか

265:ち○こもtiny
07/11/14 15:02:21
ここで聞いていいかわからんですが、qmailなプログラムに含むってことで

djbdns(=tinydns)ですが、新しくレコードを追加するときは
=hogehoge.co.jp:1.8.7.108
な書き方をしますが、
こいつのIPをかえるときって
=hogehoge.co.jpl:1.8.7.199
とかで既存レコードの上書きにはならないの？
-hogehoge.co.jp:1.8.7.108
ってしてから
=hogehoge.co.jp:1.8.7.199
しないと駄目なのかな？

リファレンス見たが
URLﾘﾝｸ(cr.yp.to)

-fqdn:ip:ttl:timestamp:lo

For versions 1.04 and above: This type of line is used by
programs that automatically edit + lines in data to
temporarily exclude addresses of overloaded or dead
machines. The line is ignored.

一時的にってのがどうも分からん。
その他にも調べたけど既存データの書き換えについて書かれているところ
がない！
教えて君ですみませんが、教えてください。

266:名無しさん＠お腹いっぱい。
07/11/14 15:14:00
>>265
つｽﾚﾘﾝｸ(unix板)

267:ち○こもtiny
07/11/14 15:23:26
>266

誘導ありが㌧

268:名無しさん＠お腹いっぱい。
07/11/14 19:13:06
Nov 14 19:02:30 server smtpd: 1195034550.790939 envdir: fatal: unable to run relay-ctrl-chdir: file does not exist
Nov 14 19:02:30 server pop3d: 1195034550.793693 envdir: fatal: unable to run relay-ctrl-chdir: file does not exist
これは一体どうやって解決すればいいんでしょう？

269:名無しさん＠お腹いっぱい。
07/11/14 19:26:39
file does not existって書いてあるじゃん。

270:名無しさん＠お腹いっぱい。
07/11/14 19:28:26
どこのファイルが無いのかがわからんのです。

271:名無しさん＠お腹いっぱい。
07/11/14 21:26:49
ユーザのMaildir内のディレクトリを確認すれば?

272:名無しさん＠お腹いっぱい。
07/12/09 16:31:14
なんか、最近 man.qmail.jp が見えないんだけど、前って見えてたかな。
URLﾘﾝｸ(man.qmail.jp)って
URLﾘﾝｸ(djb.qmail.jp) から参照されてたり
するようなとこ。

273:名無しさん＠お腹いっぱい。
07/12/09 19:59:44
>>272
ホスト名の逆引きで制限しているっぽい。

*.jp じゃないと駄目なのかな。こちらは *.net だが、撥ねられている。
1～2年前から？

274:名無しさん＠お腹いっぱい。
07/12/09 21:11:22
久しぶりにこのスレ更新されていたから見てみたけど、
ライセンスの件は話題にはならないのね。
URLﾘﾝｸ(journal.mycom.co.jp)

275:名無しさん＠お腹いっぱい。
07/12/09 21:37:08
ある意味、本人は自覚してて、陳腐化宣言なのかな、とかオモタ

276:名無しさん＠お腹いっぱい。
07/12/09 22:29:56
DJB: ﾏﾝﾄﾞｸｾ、ｵﾏｲﾗ勝手にﾔﾚ

277:名無しさん＠お腹いっぱい。
07/12/10 00:35:11
>>275
本人はとっくにpostfixに移行してたら笑うな

278:名無しさん＠お腹いっぱい。
07/12/10 07:34:14
本人やる気もう無くしたのと、標準的GNUライセンスでなんであれ
開発を肩代わりするチームを作らなかった行状の報いだな。（悲

279:名無しさん＠お腹いっぱい。
07/12/10 11:02:55
無意味に山のように機能追加されて、無様に生き恥を晒すこともあるまい
システムのライフサイクルとして、単純・単機能・使い捨てというのも
ひとつのありかただと思うけど

280:名無しさん＠お腹いっぱい。
07/12/10 21:33:03
>>273
ちょ、ちょ、こんなもの返すなよｗ

bash-2.05b$ dnsq any man.qmail.jp a.ns.qmail.jp
255 man.qmail.jp:
113 bytes, 1+1+1+3 records, response, authoritative, noerror
query: 255 man.qmail.jp
answer: man.qmail.jp 86400 A 127.0.0.0
authority: qmail.jp 86400 NS a.ns.qmail.jp
additional: a.ns.qmail.jp 86400 A 131.112.32.6
additional: a.ns.qmail.jp 86400 A 218.44.237.137
additional: a.ns.qmail.jp 86400 A 202.41.218.243
bash-2.05b$

281:名無しさん＠お腹いっぱい。
07/12/10 22:13:48
>>279
使い捨てられる、と思ってたのにいつまでも使われ続けてる例はごまんとある
2000年問題とか、COBOLがまだ使われてるとか、、、
10年後もろくにメンテされてないDJBwareがどこかで動き続け、
その一部は周囲に迷惑をかけ続けているだろう
DJBの意固地なライセンス体系が結果としてDJBwareをダメにした

282:名無しさん＠お腹いっぱい。
07/12/10 22:48:03
public domain になった以上、それを拾ってきて GNU 系プロジェクト
として立ち上げるのは、イセンス的にはおｋなんじゃいのか？いろいろ
フォークしちゃう可能性は否定できないが、netqmail まわりに結集
すれば。。。。

283:名無しさん＠お腹いっぱい。
07/12/10 22:53:04
publib domainを拾ってきても、著作者にはなれない(著作権はそれを生み
出した人に発生する)のだから、著作権を主張するGPLとは相容れない。

284:282
07/12/10 23:06:40
げ、それじゃどうしょうもない、てこと？

285:名無しさん＠お腹いっぱい。
07/12/10 23:14:32
GNU系プロジェクト
というのが地雷

286:名無しさん＠お腹いっぱい。
07/12/10 23:14:57
>>284
いや、GPLにはなれないってだけで、いわゆるオープンソース的に開発することは
十二分に可能。

287:名無しさん＠お腹いっぱい。
07/12/10 23:16:27
public domain とはそういうこと。
URLﾘﾝｸ(www.gnu.org) より
> GNUをどうやって配布するか?
> ==========================
>
> GNUはパブリック・ドメインには置かない。それにより、誰もがGNUを修正して
> 再配布でき、配布者が再配布することを禁止されることもない。つまり、独占
> 的な修正はできないのである。私は、あらゆるバージョンのGNU ([訳注] 誰で
> もソース・コードをアクセスできるという意味で)が確実にフリーであり続け
> て欲しいのである。

288:名無しさん＠お腹いっぱい。
07/12/11 09:32:55
>>280
それのどこがいけないのか説明できないだけだろ。

289:名無しさん＠お腹いっぱい。
07/12/12 12:42:07
いけなくはないかもしれないけど、漏れも分からん・・・どういう意図が？
教えてplz

dig man.qmail.jp | grep '^[^;].*IN[[:blank:]]*A'
man.qmail.jp. 86400 IN A 127.0.0.0

290:名無しさん＠お腹いっぱい。
07/12/12 12:53:08
設定したあのお方も説明に苦しむ気がしないではない。

291:名無しさん＠お腹いっぱい。
07/12/12 21:52:33
老害ですな

292:名無しさん＠お腹いっぱい。
07/12/13 02:06:21
127.0.0.x ってDNSBLじゃないの？

293:名無しさん＠お腹いっぱい。
07/12/13 02:12:03
あ、すまない。昔はman.qmail.jpにqmailの日本語訳マニュアル等のコンテンツが置いてあったのか…
DNSBLなんかを立てようとして失敗してるとか？？？

294:名無しさん＠お腹いっぱい。
07/12/13 02:40:25
東工大の中で引いても127.0.0.0返してるぜ
学内ネットのDNSをBINDで構築された腹いせだろうか

295:名無しさん＠お腹いっぱい。
07/12/13 20:45:13
t3.hpcl.titech.ac.jp:80 に HOST:man.qmail.jp で問い合わせると
HTTP/1.1 301 Moved Permanently（略）Location: URLﾘﾝｸ(man.qmail.jp:8000)
を返されるけど、学内からは t3.hpcl.titech.ac.jp:8000 見えたりするのかな？

296:名無しさん＠お腹いっぱい。
07/12/20 12:58:09
前から気になってたんだけど、この
前野年紀ってのは何者なんですか？
なんか電波じみた思想のひとっぽいですが…

297:名無しさん＠お腹いっぱい。
07/12/20 13:18:59
ぐぐれ。

298:名無しさん＠お腹いっぱい。
07/12/20 13:56:04
このくらいで電波なんて言ってたら身が持たんぞ

299:名無しさん＠お腹いっぱい。
07/12/20 21:18:48
1944生まれって、定年じゃないのか？
しかも、准教授だしｗｗ

300:名無しさん＠お腹いっぱい。
07/12/20 22:29:56
>>299
そもそも博士号持ってねーから

301:名無しさん＠お腹いっぱい。
07/12/20 22:35:01
djbの若さと、単なる信者の前野の年寄りぶりは対照的だよなぁ。

302:名無しさん＠お腹いっぱい。
07/12/20 23:31:03
>>296
東工大の原子炉研に飼われていたが原子炉に関係ある仕事を一切せず、ひたすら趣味に走った税金泥棒
そして親の東工大計算機センターからは完全スルーされてる哀れな老人

303:名無しさん＠お腹いっぱい。
07/12/20 23:36:54
それでも（当時は）公務員だったからクビも切られず現在に至る・・・か
てか、こういう立場の教員って研究室持ちで指導担当学生がいるの？

304:名無しさん＠お腹いっぱい。
07/12/20 23:42:39
大学院受けるとき、応用物理専攻と原子核工学専攻のどっち受けるか迷って
原子炉研に話を聞きに行ったが、学生とってないっぽかった。
教授会からも無視されてるんじゃない？

305:名無しさん＠お腹いっぱい。
07/12/21 04:48:35
日本の場合、物理のｶﾞｯｺのｾﾝｾｲはＩＴリテラシ技術なんての興味がなくて
結局置いてかれているもの。　バセダだって陸橋だってどこだってそんな感じ。
CERNみたいなのあこがれちゃう。それであの先生は一目置かれているんじゃねの

306:名無しさん＠お腹いっぱい。
07/12/21 11:07:10
開発者ならわかるけど、エバンジェリストにそこまで一目置くかなあ・・・

307:名無しさん＠お腹いっぱい。
07/12/21 12:26:42
296っす。おもったよりレスついてちと嬉しかったり…
ありがとうございます。

man.qmail.jpって、前から妙なアクセス規制してたり
なにをやりたいんだろうこの人は…というのが個人的疑問でして。

308:名無しさん＠お腹いっぱい。
07/12/21 15:10:16
>>306
日本における教祖的役割だったのは確かだし、10年前ぐらいまでは
日本のインターネット界隈ではそれなりに一目置かれていたのも確かだけど、
学校における立場まではわからんなぁ

309:名無しさん＠お腹いっぱい。
07/12/21 15:33:57
つまり、臭いものに蓋というのが教授とかエライ人のやり方。
んで、臭いものを扱わなくちゃいけない時点で、汲み取り屋に頼む。
これは、一般的ではないのか？

310:名無しさん＠お腹いっぱい。
07/12/21 18:03:24
皆さんがお勧めするパッチの組み合わせはどれ？

但し、組み合わせる時に修正が必要なものは、修正ポイントも教えてくれると嬉しいです。

311:名無しさん＠お腹いっぱい。
07/12/21 18:19:51
そもそも qmail なんか使わないというのがオススメ。
これまでの惰性で使い続ける以外に qmail を選択する理由なんか存在しないし、
これから新しくパッチを試すとか組み合わせを考えるなんてナンセンス。

312:名無しさん＠お腹いっぱい。
07/12/21 18:27:55
>>308
要するに、
IT・ネットワーク技術者関係から：以前は>>308
学内・本業関係から：>>302-305
って評価ってことでおｋ？
最近は見ないけど１０年くらい前にはよくいた、
研究者くずれの大学のネットワーク・計算機運用屋ってことだな
itojun氏追悼スレでもそんな話が出てた

313:名無しさん＠お腹いっぱい。
07/12/21 22:15:40
前野氏の話題は読んだ記憶ないが？

314:名無しさん＠お腹いっぱい。
07/12/21 22:25:08
>>313
前野氏じゃなくても、同じような研究者くずれのネットワーク屋ってことだろ

315:名無しさん＠お腹いっぱい。
07/12/22 00:20:35
もう終わりだね

316:名無しさん＠お腹いっぱい。
07/12/22 00:33:06
しかし
URLﾘﾝｸ(www.postfix-jp.info)
を見てると、Postfixって1～2ヵ月に1回のペースでバージョンアップしてるのね。
修正内容までチェックしてないけど、正直このペースでバージョンアップ作業を
しなきゃいけない（must）なら、メンテのコストは結構掛かるね。
入れ替え時（バージョンアップを含む）にメールのロストが起きなくて、
性能が極端に落ちるとかなければ、移行を検討したいけど。

317:名無しさん＠お腹いっぱい。
07/12/22 00:37:36
別にやらなくっても大丈夫。セキュリティアップデートじゃないから。
あと、バージョンアップでメールロストなんてないよ。

318:名無しさん＠お腹いっぱい。
07/12/22 00:49:48
>>317
修正履歴は一体何処に書いてあるんだ…

319:名無しさん＠お腹いっぱい。
07/12/22 00:51:06
>>317
くだらねえ。

320:310
07/12/22 01:24:03
>>311
でも数年トラブル無しで使えたのは助かっています。
今から他に移る気力が無いので、お勧めのパッチだけ教えて頂ければ助かります・・・

321:名無しさん＠お腹いっぱい。
07/12/22 05:22:46
qmailのパッチだとspam対策関係は必須だと思う。

322:名無しさん＠お腹いっぱい。
07/12/22 20:19:17
うちはnetqmail-1.05をベースに
・qmail-1.03-concurrencydomain.patch
・netqmail-qregex-20040601-vrt.patch
・qmail-spf-rc5.patch
・qmail-103-dns.patch
・netqmail-1.05-smtpd-auth-0.31.patch
で使ってます

323:名無しさん＠お腹いっぱい。
07/12/23 00:56:24
一からまっさらの鯖をあげるのに今さらqmailってことはないと思うが、
何年も動かしっぱなしの鯖だと、とりあえず現状に追随するだけはしときたいってこともあるよな

324:名無しさん＠お腹いっぱい。
07/12/23 09:00:45
>>322
具体的な例をありりです。

#パッチ同士の「相性」がないといいなぁ。
#diffとか、よくわかりません＞＜

325:名無しさん＠お腹いっぱい。
07/12/23 18:38:17
qmail本体ではないがspam対策だと
qgreyにS25R + tarpit before qgreylist パッチをあててqmail-smtpdの前にかまして使うのがおすすめ

326:名無しさん＠お腹いっぱい。
07/12/26 15:32:37
SPAM対策にはパッチいらん
antibadmailで十分

327:名無しさん＠お腹いっぱい。
07/12/26 17:01:23
それクライアントでの対策だろうが

328:名無しさん＠お腹いっぱい。
07/12/28 09:38:11
>>327
おいおい
antibadmailの使い方知ってるの?

329:名無しさん＠お腹いっぱい。
07/12/28 11:08:42
すまん
windowsの似た名前のスパムフィルタと勘違いしてたわ

330:名無しさん＠お腹いっぱい。
07/12/28 18:11:26
不正中継対策はしてるのですが、大量のメール中継攻撃をくらってます。
（中継はされないけどキューイングされる状態）

tcprules上では「127.0.0.1:allow,RELAYCLIENT=""」を許可してたのですが、
smtpdのログを見るとfrom 127.0.0.1からアタックされてるように見えます。

IPが偽装されてるのだと思うんですが、対策はないでしょうか

331:名無しさん＠お腹いっぱい。
07/12/28 20:32:16
乗っ取られてるな

332:名無しさん＠お腹いっぱい。
07/12/28 21:36:49
>>330
ユーザ数は多いの？
少ないならvalidrcpttoとか使って許可するユーザを特定しちゃうとか

333:名無しさん＠お腹いっぱい。
07/12/28 22:44:54
>>330
rkhunter入れて調べろ。
話はそれから。

334:名無しさん＠お腹いっぱい。
07/12/29 17:38:50
IP偽装で127.0.0.1とTCPで会話出来るとは思えんが・・・
まぁのっとりだよなぁ

335:名無しさん＠お腹いっぱい。
07/12/30 11:07:56
前野さんおすすめの
一見さんお断り方式ってパッチでてますか？

336:名無しさん＠お腹いっぱい。
07/12/30 19:11:10
一見さんお断り≒greylist

337:名無しさん＠お腹いっぱい。
07/12/30 21:49:06
cgiとか不用意に公開しているんだろ。

338:名無しさん＠お腹いっぱい。
08/01/02 01:04:34
>>337
だね。httpdとMUAが動いているホストではよくあるアタック

339:名無しさん＠お腹いっぱい。
08/01/02 03:01:30
djbが開発したソフトウェアの安全性は高いので、
安全と思って毎日ちゃんとログみないやつ多そうだしな（特に自宅鯖厨

340:名無しさん＠お腹いっぱい。
08/01/03 12:56:56
Qgrey
URLﾘﾝｸ(k2net.hakuba.jp)

を入れてみようと思うんだけど、S25R で reject されなかったメールは
基本再送要求を出す（遅延する）のかな？
ホワイトリストを定義しないと全て遅延？

それとも S25R で reject 候補になったものだけ再送要求をかけるってことかな？

使ったことある人・詳しい人、どうか教えて下さい。

341:名無しさん＠お腹いっぱい。
08/01/03 15:40:48
>>47→>>51→>>56→>>68の流れにあった配布物ってどこで公開されているの？

342:名無しさん＠お腹いっぱい。
08/01/03 22:28:11
Qgrey単体ではS25Rできません。
S25Rしたいなら
　Qgrey - S25R + qgreylist パッチ
　　URLﾘﾝｸ(k2net.hakuba.jp)
　S25R + tarpit before qgreylist パッチ
　　URLﾘﾝｸ(chiji.atnifty.com)
を使うべし。ともにQgreyのパッチ
S25Rの条件にhitしたホストまたは初めてアクセスのあったホストにだけ再送要求。
これらのホストの再送が短い間隔で行われたら拒否。
それ以外は一定期間許可（一定期間でアクセスのあったホストの情報はリセット）

なのでホワイトリストを定義しないと全て遅延ではない。

後者のパッチはホスト名でのブラックリストホワイトリストの機能があるので、後者をおすすめ。

343:名無しさん＠お腹いっぱい。
08/01/04 09:33:45
>>342
QgreyとかtaRgreyとかの中の人ですが、後者のパッチは初めて知りました。
自分もこちらのほうがよいと思います。

>>340-341
Webにも書いていますが、自分がQgrey書いたのは、知人でqmail使っているところから
Rgreyみたいなことできないか？と頼まれてそれで書いたもので、その知人も結局
postfixをフロントエンドにおいてtaRgreyで運用するようにしてしまったので
自分ではもうqmail使っていないため、今後のメンテもあまり考えてません。

ただ、ここの過去スレとか見ると、qgreylist自体があまり出来良くないので
qmail-sppベースでパッチ書いてそちらを使うように薦めたほうがいいかと思っています。
しかし前述のように自分はqmail使っていないのでテストできないため
どなたかテストをしていただける方がいたら>>56の内容で修正したもの書いて
公開しようかと思うのですが、需要ありますでしょうか？

344:名無しさん＠お腹いっぱい。
08/01/04 14:44:25
>>343
あります。是非使わせて下さい。

345:名無しさん＠お腹いっぱい。
08/01/04 18:00:16
>>343
おねがいします。いろいろな手法をくみあわせてスパム対策していますが
まだまだ届いているんです。

346:343
08/01/04 18:27:21
>>344-345
ではパッチ書いたときにテストをお願いしたいので、メールでご連絡いただけないでしょうか。

あと、RgreyとかtaRgreyとかは誤検出や遅延などなるべく少なくする、というコンセプトで
これだけでスパムを一通も受けなくする、というようなものは目指してないんですが
そのあたりは了解されてますか？
たぶん９割強はこれで落とせるので、後はHELOのブラックリストとか、コンテンツフィルタで
さらに減らす、というような運用になると思います。

347:名無しさん＠お腹いっぱい。
08/01/04 18:33:25
>>346
別の人ですが、私も試してみたいかなと思っています。
ただ、大方どんなものになるかが分からないと
評価できる環境か否かが分かりません。
qmailは皆さん色々パッチを当てているでしょうし。
qmail-sppは必須ということでしょうか？　あと、Perlでしょうか。
もう少し詳しく教えて下さい。

348:343
08/01/04 23:54:46
>>347
qmail-spp用のgreylistプラグインgreylisting-sppを改造して、tarpitとselective greylist可にします。
qmail-sppは必須で全部Cで書かれたコードになると思います。

qmail-sppを使うと、postfixであるようないろんな条件、例えばおかしなHELOの時だけ
rejectしたりgreylistingしたりというように、柔軟にフィルタを設定できるようなので
ベースとしてこれ入れるようにしたほうがいいんじゃないかと思います。

349:347
08/01/05 00:01:04
>>348
了解致しました。
現在、qmail-sppは未導入なので、早急に導入して
メールを出させていただきます。その時には宜しくお願い致します。

350:名無しさん＠お腹いっぱい。
08/01/05 01:03:08
netqmail-1.06には素のqmail-1.03にどのようなパッチが当たっているのでしょうか？

351:名無しさん＠お腹いっぱい。
08/01/05 08:40:50
さっさと拾ってきて展開してみたら？

352:名無しさん＠お腹いっぱい。
08/01/05 10:25:42
>>350
netqmail-1.05にqmailのライセンス変更が付加されたもの

353:名無しさん＠お腹いっぱい。
08/01/05 17:24:54
>>348
ここで言われているtarpitなる機能は
URLﾘﾝｸ(spamthrottle.qmail.ca)
と同等と考えても良いのでしょうか？
S25R・greylistingが含まれないことは承知しております。

354:名無しさん＠お腹いっぱい。
08/01/05 17:30:17
throttling 開発者は、tarpitting よりこっちのほうが
より凝ったことやってる、と言ってるね。

355:347
08/01/05 23:36:37
qmail-spp導入はなかなか厳しいですな。
まずqmail-vidaとの相性がすこぶる悪いです。
手でrejectされたpatchを当てて頑張っているですが、更に
DomainKeys・SPF・TSL対応という大御所も控えているので
やんわり挫折しています。

356:名無しさん＠お腹いっぱい。
08/01/06 04:52:34
　　　　＿＿＿＿.＿＿＿＿　　 |　
　　　　　|　　　　 | 　　　　|　　 |　　　やんわりと窓から投げ捨てれ
　　　　　|　　　　 | ∧＿∧　|　　 |　
　　　　　|　　　　 |（　´∀｀）つミ |　　┌──┐
　　　　　|　　　　 |/ ⊃　ﾉ　|　　 |　　|　　qmail　　|
　　　　￣￣￣￣'￣￣￣￣　　 |　　└──┘

357:名無しさん＠お腹いっぱい。
08/01/06 14:30:57
だれかがa patchy qmailでもつくらねーかなー(w

358:名無しさん＠お腹いっぱい。
08/01/06 14:41:00
apache.org が引き取ってくれれば良いわけだ。

359:名無しさん＠お腹いっぱい。
08/01/06 15:02:26
>>357
netqmail

360:343
08/01/07 09:12:56
>>353
throttlingは、単位時間内のメール数をカウントして、閾値を超えたら制限する、という手法です。
tarpitは、SMTPの返答を数十秒遅らせることで、相手が待ちきれずに切断してくるのを期待するものです。
なので、手法自体が違います。

>>354
throttlingのほうがいいと書いてるのは、単純にtarpitするとDoSされうるんで、そのことだと思います。
が、taRgreyではtarpitを抜けなかった同一IPからの接続はgreylistに回すのでその問題は回避されます。
しかし>>56で書かれている内容だと、tarpitを抜けたかどうかを検知できないんで、その問題は
残ったままになるんで、どうしたもんか思案してます。

>>355
359も書いてるみたいにnetqmailってそのへんのパッチ済みのやつではないんでしょうか。
qmail詳しくないんで嘘言ってる可能性大ですが。

361:名無しさん＠お腹いっぱい。
08/01/07 18:40:46
ここで紹介されていたtaRgreyを試してみました。

日本以外から望んだメールが来ることはない（これまでも10年弱なかった）ので
JP以外のccTLDをほぼ全てブラックリスト（接続元ホスト）にいれて
ドットを含まないなどHELOのブラックリストを若干追加して
ほぼ（99%くらい）spamを遮断することが出来ています。

すり抜けてくるspamは接続元IPアドレスが逆引き出来ない所からのもの
ばかりなので、ばっさり拒否したいのですが、逆引き出来ないMXを立てることって
悪意と素人以外に考えられる正当なパターンってありますかね？

関連で、日本の固定IPアドレスサービスで逆引きなし・DNS設置不可
なんてところがあるならば、教えて欲しいです。

362:名無しさん＠お腹いっぱい。
08/01/07 18:44:02
むしろ不当だとする理由がないだろ。

363:名無しさん＠お腹いっぱい。
08/01/07 19:49:41
逆引きは、DNS鯖が落ちた実績があるからなー
URLﾘﾝｸ(www.nic.ad.jp)
まあ、その間のメールが全部ブラックリストに放り込まれても、
JPNIC氏ねで済むならいいんじゃね。

364:名無しさん＠お腹いっぱい。
08/01/07 20:23:53
>>362
URLﾘﾝｸ(moin.qmail.jp)
より、MXはAレコードのラベル。で、なぜ対になるPTRを定義しないのか。
何か隠したいことでもあるのか？　と思ったりする訳です。

また、OP25Bが急速に普及したような日本で、何か逆引き設定できない
特別な理由でもあるのか？　とも思ったりする訳です。
URLﾘﾝｸ(moin.qmail.jp)
URLﾘﾝｸ(moin.qmail.jp)
とかでも書いてあるけど、昨今の状況を考えると正規のMXでは
逆引きを設定しないと自分が困ることになることが多い現状で…（以下略）

>>363
確かにそういう事態は考慮しないといけないですね。
でも、逆引き出来ない間は即ブラックリストじゃなく
グレイリストに残り続けるということなら許容出来るかなぁ、と。

まぁ、何れもポリシーの問題ってことで、了解です。

365:名無しさん＠お腹いっぱい。
08/01/07 23:06:15
>>364
なぜ知る必要のないことまで知ろうとするんだ？

> 昨今の状況を考えると正規のMXでは
> 逆引きを設定しないと自分が困ることになることが多い現状で…（以下略）
そういう状況にしてるのはあなたのような人たちでしょ。

366:名無しさん＠お腹いっぱい。
08/01/07 23:08:40
知る必要のないこと？　何それ？
何をそんなに怯えているの？

367:名無しさん＠お腹いっぱい。
08/01/07 23:20:04
まるで迷子の子猫さんのように

368:名無しさん＠お腹いっぱい。
08/01/08 00:59:26
>>365
そんなこと言ったら、HELOで言ってくることなんて、全くもって知る必要がない情報じゃない？

369:名無しさん＠お腹いっぱい。
08/01/08 01:32:01
うん
HELO飛ばしても、SMTPセッション継続する実装普通にあるしね

370:名無しさん＠お腹いっぱい。
08/01/08 01:51:23
MXはFQDNで指定するんだし、公開されているサーバなんだから
逆引きの必要性・重要性は認識してもらわないと。
URLﾘﾝｸ(www.itmedia.co.jp)

371:名無しさん＠お腹いっぱい。
08/01/08 03:08:31
>>370
それじゃ説得力皆無.
だいたいスレ違いもいいところだ。いい加減にしろ。

372:名無しさん＠お腹いっぱい。
08/01/08 09:40:41
>>370
MX を FQDN で指定することと逆引きの必要性に何の関係があるんだ？

373:名無しさん＠お腹いっぱい。
08/01/08 09:57:55
逆引きはプロバイダーから委譲してもらっていないとか。

374:名無しさん＠お腹いっぱい。
08/01/08 10:16:56
逆引き設定しないことの是非にはどうでもよくて、指標としてどのくらい使えるかだけ考えればいいのでは。

スパム対策に使われる手法って、こういう場合はスパムの可能性が高いという指標でしかないでしょう。
ベイジアンフィルタなんて小さな指標を多数積み重ねて判断してるわけだし
greylistingだって、再送してこないクライアントはスパムクライアントの可能性が高いから、だし。
それがRFCに載ってるかどうかとかなんて関係なくて、誤検知の少ない指標があれば使えばいい。

その指標の精度を高めるために、複数の指標を組みあせて使うことで、誤検知や他への悪影響を
減らすように考えれば良いのでは。

375:名無しさん＠お腹いっぱい。
08/01/08 11:32:52
>>374
御意。それを>>370のように、わけのわからない話を持ち出して、
逆引き登録するのは当然だとか言い出すのがいけない。370は猛省すること。

376:名無しさん＠お腹いっぱい。
08/01/08 11:37:36
>>375
猛省すべきことか？
何か問題があったときに連絡先の手掛かりとなる逆引きの設定を
敢えてしないなんて迷惑だ。
クライアントの話じゃないぞ。公開サーバだぞ。
>>370に同意だ。

377:名無しさん＠お腹いっぱい。
08/01/08 11:53:04
逆引きで連絡するなアホ。

378:名無しさん＠お腹いっぱい。
08/01/08 11:58:07
>>377
逆引き→whoisですが？
whoisだけだったら上位アロケーションの管理者しか出てこなくて困ることがある。

379:名無しさん＠お腹いっぱい。
08/01/08 11:58:24
whoisひけばよし。

380:名無しさん＠お腹いっぱい。
08/01/08 11:59:15
>>374
んで指標としてどのくらい使えるのかね。

381:名無しさん＠お腹いっぱい。
08/01/08 12:04:24
>>377
こういうこと書く人って、実際にabuse連絡とかしたことないんだろうね、と思う。

382:名無しさん＠お腹いっぱい。
08/01/08 13:35:30
>>380
それなりに。
少なくともgreylistingへまわすか判断させるには十分。

383:名無しさん＠お腹いっぱい。
08/01/08 22:07:56
スレチですが
Sender IDとかいうDNSのSPFレコードを参照するスパム対策ってありましたよね・・・
Ｍ＄が提案したらしいですが・・・

384:名無しさん＠お腹いっぱい。
08/01/08 22:21:48
それがどうかしたか？

385:名無しさん＠お腹いっぱい。
08/01/08 23:03:59
>>378
そっから連絡つくじゃん。
逆に FQDN わかってもそこから連絡とれるとは限らん。

386:名無しさん＠お腹いっぱい。
08/01/08 23:12:50
>>385
だからabuse連絡したことないでしょ。
CodeRedやNimdaの時とか（も）結構色々なとこに連絡したけど
whoisの情報でちゃんと連絡が取れたのって5割くらいだったような。
残りは、FQDN→対象会社のウェブページを推定→連絡先を探すパターンか
仕方ないから上位の管理者に連絡を取ってもらうか
電話しか分からないってところもあった。
迷惑なんだよ。困るんだよ。

387:名無しさん＠お腹いっぱい。
08/01/08 23:17:22
あぁ、CodeRedやNimdaはクライアントの例か。
でも公開サーバで連絡先の特定が困難になる状況は勘弁して欲しい。

388:名無しさん＠お腹いっぱい。
08/01/08 23:39:52
>>387
DynamicDNSで運用してる自宅鯖厨を全否定で桶？

389:名無しさん＠お腹いっぱい。
08/01/08 23:48:29
だから逆引きだけじゃなくて、他のことでも確認してるんだろ？

390:名無しさん＠お腹いっぱい。
08/01/08 23:49:18
>>388
国内のまっとうなプロバイダの動的割り当ては逆引きも出来るし
それはプロバイダに連絡してしかるべき対処をしてもらえれば良いから関係なし。

391:名無しさん＠お腹いっぱい。
08/01/16 00:36:38
failer notice

392:名無しさん＠お腹いっぱい。
08/01/19 02:17:53
>>391
failure notice

393:名無しさん＠お腹いっぱい。
08/01/21 11:05:11
逆引きでないIPからの接続拒否まじおすすめです。

394:名無しさん＠お腹いっぱい。
08/01/22 01:52:34
>>393
最近では逆引きできるISPが増えてる。
効果として２割方は削減できるので、逆引き不能サイトを弾く効果はある。
ただし、どこかの国内馬鹿ISP(エッチ立系のとこ）は、逆引きをしない。
顧客サイトが多いために、ホワイトリストを管理する必要がある

395:名無しさん＠お腹いっぱい。
08/01/23 05:36:47
>>394
必死ですねwww

396:名無しさん＠お腹いっぱい。
08/01/25 04:44:14
qmail+vpopmail+qmailadminの組み合わせで使っているんだけど

postfixでバーチャルサーバーやるときに
vpopmailみたいなツールあるのかな？
それとqmailadminみたいなシンプルな管理ツールもあるのかな？

397:名無しさん＠お腹いっぱい。
08/01/25 09:08:42
postfixadminってのがあるが、メーリングリストは管理できない

398:名無しさん＠お腹いっぱい。
08/01/25 09:32:59
qmail+vpopmail(virtual domain)でメールサーバを使ってますが、
vpopユーザのアカウントとパスワードを、システムアカウントにしたいと思ってます。

システムアカウントから、vpop形式にするには、vconverterと言うプログラムがありますけど、
この逆の事がしたいのです。

何か、良い方法ってあります？

399:名無しさん＠お腹いっぱい。
08/01/25 15:01:46
自分はqmail-vidaを使ってるんだけど
なんだかここではvpopmailが人気だな。

400:名無しさん＠お腹いっぱい。
08/01/26 00:12:07
>>398
vpopmailのアカウント管理って、どの形式でやっとるん？
LDAPに移行して、LDAPで認証する、とかどない？

>>399
そりゃ、vpopmailだとWebから管理するためのツールがついてくるからね

401:名無しさん＠お腹いっぱい。
08/01/26 09:38:09
>>400
LDAPもsqlも使ってなく、通常ののvpopパスワード形式です。

402:名無しさん＠お腹いっぱい。
08/01/30 14:12:12
10.3をフツーに立てて
ローカルで25番を叩いてSMTPコマンドでフツーにメールを出すとします。
例えば下の通り。

HELO localhost
mail from:root
rcpt to:xxx@hotmail.com
rcpt to:aaa@bbb.com
data
Bcc:aaa@bbb.com
Test
.

これでhotmail側の受信メールを見ると
Bcc:aaa@bbb.com行がフツーに表示されるんですが、どういう狼藉なんでしょうか…？
同じように立てたpostfixだと出ません。

403:名無しさん＠お腹いっぱい。
08/01/30 15:26:25
仕様。Bcc は MUA が削除しなければならない。

削除されないで MTA に渡ってきたときに MTA が消すのを
小さな親切と考えるのが sendmail や postfix、大きなお世話と考えるのが qmail。

404:名無しさん＠お腹いっぱい。
08/01/30 15:55:05
おーなるほど！そういうもんなんですね。
ありがとうございました。

405:名無しさん＠お腹いっぱい。
08/01/30 16:40:09
>Bcc は MUA が削除しなければならない。
削除というか、普通はヘッダに付けないのでは？？

406:名無しさん＠お腹いっぱい。
08/01/30 23:09:28
Bccで送信された事が分かる様にして
Bccの受信者が安易に返信しない様に
Bccを残すべきという考え方もある

Bccが付いたメールに返信する場合に
警告するMUAはまだ見たことがないが

407:名無しさん＠お腹いっぱい。
08/01/30 23:32:33
こうですか
わかりません

URLﾘﾝｸ(www.puni.net)

前略

"Bcc"フィールドの使用には３つの方法がある。最初は、Bccフィールドを持つ
メッセージの送信準備が出来たとき、すべての受取人（Bccフィールドで指定
したものも含む）にメッセージのコピーが送られるが、Bccの行が削除される。
２つめの場合、ToやCcで指定した行で規定される受取人それぞれは上記と同じ
く、Bcc:の行が消されたメッセージのコピーを受け取るが、Bcc行にある受取
人はBcc行を含むメッセージの別のコピーを受け取る。（Bccフィールドに複数
の受取人アドレスがあるなら、いくつかの実装では実際、その特定の受取人の
アドレスだけを含む、それぞれの受取人への別々のメッセージのコピーを送る）
最後に、Bccフィールドはアドレスを持っていないかもしれないので、ブライ
ンドコピーが誰かにおくられたということを受取人に示さず、アドレスなしの
Bccフィールドとして送られる。Bccの利用をいずれの方法で行うかは実装依存
だが、この文書の「セキュリティに関する考察」のセクションをめいめいの議
論のために参照せよ。

後略

408:名無しさん＠お腹いっぱい。
08/01/31 09:21:43
ML宛てだったのか、SPAMなのかわかるだろ。

409:名無しさん＠お腹いっぱい。
08/02/15 17:15:06
>>407
URLﾘﾝｸ(www.puni.net)
>一般に、リレーするSMTPは、その受けとったメッセージ内容が有効であり、
>エンベロープにそれを許可するように書かれており、内容を検査することな
>るリレーするべきである(SHOULD)。
↑「る」は「く」の誤り
(中略)
>セクション2.4.1で議論したように、リレーのSMTPはメッセージのヘッダやボ
>ディのデータを調べたりそれにより動作したりする必要はなく、自分自身の
>"Received:"ヘッダを加えること、またオプションでメールシステムのループ
>を検出する(セクション6.2を見よ)ことを除きそうしてはならない(MUST NOT)。
(中略)
>メッセージがメール環境の境界を超えてゲートウェイされるのに必要な時、
>ヘッダフィールドを書き換えてもよい(MAY)。これは、セクション2.4.1での禁
>止事項にもかかわらず、メッセージボディの検査や宛て先のローカルパートの
>解釈を含んでもよい。

410:名無しさん＠お腹いっぱい。
08/02/21 00:54:53
qmailに問題があるのはわかるが間違いの指摘が間違いだらけなのはどうなの？
これじゃアンチや信者と変わらない

URLﾘﾝｸ(ya.maya.st)

411:名無しさん＠お腹いっぱい。
08/02/21 00:59:20
>>410
たとえばどこが間違ってるの？

412:名無しさん＠お腹いっぱい。
08/02/21 09:17:33
>>410
そこをdisるなんて勇気あんな。
よっぽどqmailに詳しい人でも、たぶん間違いだらけって指摘のほうがまとはずれ。

413:名無しさん＠お腹いっぱい。
08/02/21 11:49:38
大岡山の大先生はみなの無理解に呆れサイトを閉じはじめたみたいだが。

414:名無しさん＠お腹いっぱい。
08/02/21 23:24:17
停年だからな

415:名無しさん＠お腹いっぱい。
08/02/22 10:24:34
例えばRFCに準拠してないと言っているが準拠の基準となるRFCがqmailが作られたより後にできたRFCとか
unixの改行がLFなのは自明のことなのにCRLFがうまく変換できないとか
そもそも改行に2バイトも使うRFCにも問題があるのにCRLFのままで保存しろとか
qmailの「安全でないパッチ地獄」が問題だと言うが元々バグだらけのものに「最新の」パッチを沢山当てることは安全なのかとか
まともなことも沢山言っているが偏見による間違いも多い
qmailは駄目を前提に悪い印象を与えようとするDHMO的な文章の書き方だと思う
偉い先生なのかもしれないが俺程度が間違いを指摘できるようでは鵜呑みにはしないほうがいい

416:名無しさん＠お腹いっぱい。
08/02/22 11:23:19
>>415
> 例えばRFCに準拠してないと言っているが準拠の基準となるRFCがqmailが作られたより後にできたRFCとか
現状にあってないてことじゃんｗ

417:名無しさん＠お腹いっぱい。
08/02/22 11:28:33
偉い先生がなんて言おうが、自分が間違っていると
思っているんであれば別に従う必要はないんでないすかね。

個人的にはやまやの書いていることは同意出来ること多いと思います。
ま、人は人、自分は自分、でいいんじゃない？

418:名無しさん＠お腹いっぱい。
08/02/22 11:33:00
>>415
> 例えばRFCに準拠してないと言っているが準拠の基準となるRFCがqmailが作られたより後にできたRFCとか
それだけメンテされてないってのは問題でしょう。

> unixの改行がLFなのは自明のことなのにCRLFがうまく変換できないとか
いまいち意味がわからん。
もうちょい詳しく。

> そもそも改行に2バイトも使うRFCにも問題があるのに
どんだけディスク小さいんだよ。

> qmailの「安全でないパッチ地獄」が問題だと言うが元々バグだらけのものに「最新の」パッチを沢山当てることは安全なのかとか
これも意味がよくわからん。

419:名無しさん＠お腹いっぱい。
08/02/22 12:24:36
>>416
法は過去に遡って適用されない
従って「違反」ではない
最初にも述べたが問題にしてるのは詭弁や虚言と自分の間違いは改めない態度であってqmailの現状を擁護しているわけではない
それと現状にそぐわないの原因になっていた変なライセンスはPDLになったことで解消されている
問題の指摘の方こそ現状にあってない

420:名無しさん＠お腹いっぱい。
08/02/22 12:33:33
RFC2821 はなかったかもしれないけど、821bis の議論はかなり進んでいたのに
それを完全に無視してリリースしてしまった上、その後修正しなかったのは
よろしくないと思うけど。

421:名無しさん＠お腹いっぱい。
08/02/22 12:40:51
> unixの改行がLFなのは自明のことなのにCRLFがうまく変換できないとか

qmail-injectは単純にLFをCRLFに変換する
CRLFだとCRCRLFになってしまうという話

>どんだけディスク小さいんだよ。

確かに圧縮という意味では貧弱すぎる
しかしファイルに保存した場合1byteの違いが512や1024の違いになることを考えればわざわざこんな設計はしない
ディスクの浪費は資源の浪費であり富める者の傲慢でもある

> qmailの「安全でないパッチ地獄」が問題だと言うが元々バグだらけのものに「最新の」パッチを沢山当てることは安全なのかとか

パッチを集中管理して検証してないから安全でないということだと理解したがパッチはqmail.orgなどで集められているし「最新」のパッチが十分検証されているはずがないので他が安全だということにはならない

422:名無しさん＠お腹いっぱい。
08/02/22 13:20:47
>>421
> パッチはqmail.orgなどで集められているし
単に集積されてるだけでしょう。
集中管理して検証してるの？

> 「最新」のパッチが十分検証されているはずがないので
どのパッチのことを言ってるんだ？

> 他が安全だということにはならない
「他が安全だ」なんて言ってたっけ。

423:名無しさん＠お腹いっぱい。
08/02/22 13:39:26
つまりパッチ当てても当てなくても安全じゃないってことじゃんｗｗ

次ページ