qmailいろいろ(8)
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。
2006/11/12(日) 19:07:01いろいろ情報交換しましょう!
前スレ qmailいろいろ(7)
http://pc8.2ch.net/test/read.cgi/unix/1114157851/
関連スレ、関連サイトは >>2-10 あたり。
0328名無しさん＠お腹いっぱい。
2007/12/28(金) 09:38:11おいおい
antibadmailの使い方知ってるの?
0329名無しさん＠お腹いっぱい。
2007/12/28(金) 11:08:42windowsの似た名前のスパムフィルタと勘違いしてたわ
0330名無しさん＠お腹いっぱい。
2007/12/28(金) 18:11:26（中継はされないけどキューイングされる状態）
tcprules上では「127.0.0.1:allow,RELAYCLIENT=""」を許可してたのですが、
smtpdのログを見るとfrom 127.0.0.1からアタックされてるように見えます。
IPが偽装されてるのだと思うんですが、対策はないでしょうか
0331名無しさん＠お腹いっぱい。
2007/12/28(金) 20:32:160332名無しさん＠お腹いっぱい。
2007/12/28(金) 21:36:49ユーザ数は多いの？
少ないならvalidrcpttoとか使って許可するユーザを特定しちゃうとか
0333名無しさん＠お腹いっぱい。
2007/12/28(金) 22:44:54rkhunter入れて調べろ。
話はそれから。
0334名無しさん＠お腹いっぱい。
2007/12/29(土) 17:38:50まぁのっとりだよなぁ
0335名無しさん＠お腹いっぱい。
2007/12/30(日) 11:07:56一見さんお断り方式ってパッチでてますか？
0336名無しさん＠お腹いっぱい。
2007/12/30(日) 19:11:100337名無しさん＠お腹いっぱい。
2007/12/30(日) 21:49:060338名無しさん＠お腹いっぱい。
2008/01/02(水) 01:04:34だね。httpdとMUAが動いているホストではよくあるアタック
0339名無しさん＠お腹いっぱい。
2008/01/02(水) 03:01:30安全と思って毎日ちゃんとログみないやつ多そうだしな（特に自宅鯖厨
0340名無しさん＠お腹いっぱい。
2008/01/03(木) 12:56:56http://k2net.hakuba.jp/qgrey/index.html
を入れてみようと思うんだけど、S25R で reject されなかったメールは
基本再送要求を出す（遅延する）のかな？
ホワイトリストを定義しないと全て遅延？
それとも S25R で reject 候補になったものだけ再送要求をかけるってことかな？
使ったことある人・詳しい人、どうか教えて下さい。
0341名無しさん＠お腹いっぱい。
2008/01/03(木) 15:40:480342名無しさん＠お腹いっぱい。
2008/01/03(木) 22:28:11S25Rしたいなら
Qgrey - S25R + qgreylist パッチ
ttp://k2net.hakuba.jp/qgrey/
S25R + tarpit before qgreylist パッチ
ttp://chiji.atnifty.com/tools/s25rtarpit_before_qgreylist/s25rtarpit_before_qgreylist.html
を使うべし。ともにQgreyのパッチ
S25Rの条件にhitしたホストまたは初めてアクセスのあったホストにだけ再送要求。
これらのホストの再送が短い間隔で行われたら拒否。
それ以外は一定期間許可（一定期間でアクセスのあったホストの情報はリセット）
なのでホワイトリストを定義しないと全て遅延ではない。
後者のパッチはホスト名でのブラックリストホワイトリストの機能があるので、後者をおすすめ。
0343名無しさん＠お腹いっぱい。
2008/01/04(金) 09:33:45QgreyとかtaRgreyとかの中の人ですが、後者のパッチは初めて知りました。
自分もこちらのほうがよいと思います。
>>340-341
Webにも書いていますが、自分がQgrey書いたのは、知人でqmail使っているところから
Rgreyみたいなことできないか？と頼まれてそれで書いたもので、その知人も結局
postfixをフロントエンドにおいてtaRgreyで運用するようにしてしまったので
自分ではもうqmail使っていないため、今後のメンテもあまり考えてません。
ただ、ここの過去スレとか見ると、qgreylist自体があまり出来良くないので
qmail-sppベースでパッチ書いてそちらを使うように薦めたほうがいいかと思っています。
しかし前述のように自分はqmail使っていないのでテストできないため
どなたかテストをしていただける方がいたら>>56の内容で修正したもの書いて
公開しようかと思うのですが、需要ありますでしょうか？
0344名無しさん＠お腹いっぱい。
2008/01/04(金) 14:44:25あります。是非使わせて下さい。
0345名無しさん＠お腹いっぱい。
2008/01/04(金) 18:00:16おねがいします。いろいろな手法をくみあわせてスパム対策していますが
まだまだ届いているんです。
0346343
2008/01/04(金) 18:27:21ではパッチ書いたときにテストをお願いしたいので、メールでご連絡いただけないでしょうか。
あと、RgreyとかtaRgreyとかは誤検出や遅延などなるべく少なくする、というコンセプトで
これだけでスパムを一通も受けなくする、というようなものは目指してないんですが
そのあたりは了解されてますか？
たぶん９割強はこれで落とせるので、後はHELOのブラックリストとか、コンテンツフィルタで
さらに減らす、というような運用になると思います。
0347名無しさん＠お腹いっぱい。
2008/01/04(金) 18:33:25別の人ですが、私も試してみたいかなと思っています。
ただ、大方どんなものになるかが分からないと
評価できる環境か否かが分かりません。
qmailは皆さん色々パッチを当てているでしょうし。
qmail-sppは必須ということでしょうか？ あと、Perlでしょうか。
もう少し詳しく教えて下さい。
0348343
2008/01/04(金) 23:54:46qmail-spp用のgreylistプラグインgreylisting-sppを改造して、tarpitとselective greylist可にします。
qmail-sppは必須で全部Cで書かれたコードになると思います。
qmail-sppを使うと、postfixであるようないろんな条件、例えばおかしなHELOの時だけ
rejectしたりgreylistingしたりというように、柔軟にフィルタを設定できるようなので
ベースとしてこれ入れるようにしたほうがいいんじゃないかと思います。
0349347
2008/01/05(土) 00:01:04了解致しました。
現在、qmail-sppは未導入なので、早急に導入して
メールを出させていただきます。その時には宜しくお願い致します。
0350名無しさん＠お腹いっぱい。
2008/01/05(土) 01:03:080351名無しさん＠お腹いっぱい。
2008/01/05(土) 08:40:500352名無しさん＠お腹いっぱい。
2008/01/05(土) 10:25:42netqmail-1.05にqmailのライセンス変更が付加されたもの
0353名無しさん＠お腹いっぱい。
2008/01/05(土) 17:24:54ここで言われているtarpitなる機能は
http://spamthrottle.qmail.ca/
と同等と考えても良いのでしょうか？
S25R・greylistingが含まれないことは承知しております。
0354名無しさん＠お腹いっぱい。
2008/01/05(土) 17:30:17より凝ったことやってる、と言ってるね。
0355347
2008/01/05(土) 23:36:37まずqmail-vidaとの相性がすこぶる悪いです。
手でrejectされたpatchを当てて頑張っているですが、更に
DomainKeys・SPF・TSL対応という大御所も控えているので
やんわり挫折しています。
0356名無しさん＠お腹いっぱい。
2008/01/06(日) 04:52:34| | | | やんわりと窓から投げ捨てれ
| | ∧＿∧ | |
| |（ ´∀｀）つ ミ | ┌────┐
| |/ ⊃ ﾉ | | | qmail |
￣￣￣￣'￣￣￣￣ | └────┘
0357名無しさん＠お腹いっぱい。
2008/01/06(日) 14:30:570358名無しさん＠お腹いっぱい。
2008/01/06(日) 14:41:000359名無しさん＠お腹いっぱい。
2008/01/06(日) 15:02:26netqmail
0360343
2008/01/07(月) 09:12:56throttlingは、単位時間内のメール数をカウントして、閾値を超えたら制限する、という手法です。
tarpitは、SMTPの返答を数十秒遅らせることで、相手が待ちきれずに切断してくるのを期待するものです。
なので、手法自体が違います。
>>354
throttlingのほうがいいと書いてるのは、単純にtarpitするとDoSされうるんで、そのことだと思います。
が、taRgreyではtarpitを抜けなかった同一IPからの接続はgreylistに回すのでその問題は回避されます。
しかし>>56で書かれている内容だと、tarpitを抜けたかどうかを検知できないんで、その問題は
残ったままになるんで、どうしたもんか思案してます。
>>355
359も書いてるみたいにnetqmailってそのへんのパッチ済みのやつではないんでしょうか。
qmail詳しくないんで嘘言ってる可能性大ですが。
0361名無しさん＠お腹いっぱい。
2008/01/07(月) 18:40:46日本以外から望んだメールが来ることはない（これまでも10年弱なかった）ので
JP以外のccTLDをほぼ全てブラックリスト（接続元ホスト）にいれて
ドットを含まないなどHELOのブラックリストを若干追加して
ほぼ（99%くらい）spamを遮断することが出来ています。
すり抜けてくるspamは接続元IPアドレスが逆引き出来ない所からのもの
ばかりなので、ばっさり拒否したいのですが、逆引き出来ないMXを立てることって
悪意と素人以外に考えられる正当なパターンってありますかね？
関連で、日本の固定IPアドレスサービスで逆引きなし・DNS設置不可
なんてところがあるならば、教えて欲しいです。
0362名無しさん＠お腹いっぱい。
2008/01/07(月) 18:44:020363名無しさん＠お腹いっぱい。
2008/01/07(月) 19:49:41http://www.nic.ad.jp/ja/topics/2005/20051024-01.html
まあ、その間のメールが全部ブラックリストに放り込まれても、
JPNIC氏ねで済むならいいんじゃね。
0364名無しさん＠お腹いっぱい。
2008/01/07(月) 20:23:53http://moin.qmail.jp/DNS_2fWrong#head-27e8e97d0224caaaabf2150224310f22bb1a0f7c
より、MXはAレコードのラベル。で、なぜ対になるPTRを定義しないのか。
何か隠したいことでもあるのか？ と思ったりする訳です。
また、OP25Bが急速に普及したような日本で、何か逆引き設定できない
特別な理由でもあるのか？ とも思ったりする訳です。
http://moin.qmail.jp/DNS_2f_b5_d5_b0_fa_a4_ad_c0_df_c4_ea_a4_cb_a4_c4_a4_a4_a4_c6
http://moin.qmail.jp/_a5_e1_a5_a4_a5_eb_a5_b5_a1_bc_a5_d0_a4_ce_a4_bf_a4_e1_a4_ceDNS_20_a5_ec_a5_b3_a1_bc_a5_c9_c0_df_c4_ea#head-2c662f43e73125a858ccc9e87e2398ca260b3d04
とかでも書いてあるけど、昨今の状況を考えると正規のMXでは
逆引きを設定しないと自分が困ることになることが多い現状で…（以下略）
>>363
確かにそういう事態は考慮しないといけないですね。
でも、逆引き出来ない間は即ブラックリストじゃなく
グレイリストに残り続けるということなら許容出来るかなぁ、と。
まぁ、何れもポリシーの問題ってことで、了解です。
0365名無しさん＠お腹いっぱい。
2008/01/07(月) 23:06:15なぜ知る必要のないことまで知ろうとするんだ？
> 昨今の状況を考えると正規のMXでは
> 逆引きを設定しないと自分が困ることになることが多い現状で…（以下略）
そういう状況にしてるのはあなたのような人たちでしょ。
0366名無しさん＠お腹いっぱい。
2008/01/07(月) 23:08:40何をそんなに怯えているの？
0367名無しさん＠お腹いっぱい。
2008/01/07(月) 23:20:040368名無しさん＠お腹いっぱい。
2008/01/08(火) 00:59:26そんなこと言ったら、HELOで言ってくることなんて、全くもって知る必要がない情報じゃない？
0369名無しさん＠お腹いっぱい。
2008/01/08(火) 01:32:01HELO飛ばしても、SMTPセッション継続する実装普通にあるしね
0370名無しさん＠お腹いっぱい。
2008/01/08(火) 01:51:23逆引きの必要性・重要性は認識してもらわないと。
http://www.itmedia.co.jp/help/howto/win/win2000/0007special/dns/chap3/06.html
0371名無しさん＠お腹いっぱい。
2008/01/08(火) 03:08:31それじゃ説得力皆無.
だいたいスレ違いもいいところだ。いい加減にしろ。
0372名無しさん＠お腹いっぱい。
2008/01/08(火) 09:40:41MX を FQDN で指定することと逆引きの必要性に何の関係があるんだ？
0373名無しさん＠お腹いっぱい。
2008/01/08(火) 09:57:550374名無しさん＠お腹いっぱい。
2008/01/08(火) 10:16:56スパム対策に使われる手法って、こういう場合はスパムの可能性が高いという指標でしかないでしょう。
ベイジアンフィルタなんて小さな指標を多数積み重ねて判断してるわけだし
greylistingだって、再送してこないクライアントはスパムクライアントの可能性が高いから、だし。
それがRFCに載ってるかどうかとかなんて関係なくて、誤検知の少ない指標があれば使えばいい。
その指標の精度を高めるために、複数の指標を組みあせて使うことで、誤検知や他への悪影響を
減らすように考えれば良いのでは。
0375名無しさん＠お腹いっぱい。
2008/01/08(火) 11:32:52御意。それを>>370のように、わけのわからない話を持ち出して、
逆引き登録するのは当然だとか言い出すのがいけない。370は猛省すること。
0376名無しさん＠お腹いっぱい。
2008/01/08(火) 11:37:36猛省すべきことか？
何か問題があったときに連絡先の手掛かりとなる逆引きの設定を
敢えてしないなんて迷惑だ。
クライアントの話じゃないぞ。公開サーバだぞ。
>>370に同意だ。
0377名無しさん＠お腹いっぱい。
2008/01/08(火) 11:53:040378名無しさん＠お腹いっぱい。
2008/01/08(火) 11:58:07逆引き→whoisですが？
whoisだけだったら上位アロケーションの管理者しか出てこなくて困ることがある。
0379名無しさん＠お腹いっぱい。
2008/01/08(火) 11:58:240380名無しさん＠お腹いっぱい。
2008/01/08(火) 11:59:15んで指標としてどのくらい使えるのかね。
0381名無しさん＠お腹いっぱい。
2008/01/08(火) 12:04:24こういうこと書く人って、実際にabuse連絡とかしたことないんだろうね、と思う。
0382名無しさん＠お腹いっぱい。
2008/01/08(火) 13:35:30それなりに。
少なくともgreylistingへまわすか判断させるには十分。
0383名無しさん＠お腹いっぱい。
2008/01/08(火) 22:07:56Sender IDとかいうDNSのSPFレコードを参照するスパム対策ってありましたよね・・・
Ｍ＄が提案したらしいですが・・・
0384名無しさん＠お腹いっぱい。
2008/01/08(火) 22:21:480385名無しさん＠お腹いっぱい。
2008/01/08(火) 23:03:59そっから連絡つくじゃん。
逆に FQDN わかってもそこから連絡とれるとは限らん。
0386名無しさん＠お腹いっぱい。
2008/01/08(火) 23:12:50だからabuse連絡したことないでしょ。
CodeRedやNimdaの時とか（も）結構色々なとこに連絡したけど
whoisの情報でちゃんと連絡が取れたのって5割くらいだったような。
残りは、FQDN→対象会社のウェブページを推定→連絡先を探すパターンか
仕方ないから上位の管理者に連絡を取ってもらうか
電話しか分からないってところもあった。
迷惑なんだよ。困るんだよ。
0387名無しさん＠お腹いっぱい。
2008/01/08(火) 23:17:22でも公開サーバで連絡先の特定が困難になる状況は勘弁して欲しい。
0388名無しさん＠お腹いっぱい。
2008/01/08(火) 23:39:52DynamicDNSで運用してる自宅鯖厨を全否定で桶？
0389名無しさん＠お腹いっぱい。
2008/01/08(火) 23:48:290390名無しさん＠お腹いっぱい。
2008/01/08(火) 23:49:18国内のまっとうなプロバイダの動的割り当ては逆引きも出来るし
それはプロバイダに連絡してしかるべき対処をしてもらえれば良いから関係なし。
0391名無しさん＠お腹いっぱい。
2008/01/16(水) 00:36:380392名無しさん＠お腹いっぱい。
2008/01/19(土) 02:17:53failure notice
0393名無しさん＠お腹いっぱい。
2008/01/21(月) 11:05:110394名無しさん＠お腹いっぱい。
2008/01/22(火) 01:52:34最近では逆引きできるISPが増えてる。
効果として２割方は削減できるので、逆引き不能サイトを弾く効果はある。
ただし、どこかの国内馬鹿ISP(エッチ立系のとこ）は、逆引きをしない。
顧客サイトが多いために、ホワイトリストを管理する必要がある
0395名無しさん＠お腹いっぱい。
2008/01/23(水) 05:36:47必死ですねwww
0396名無しさん＠お腹いっぱい。
2008/01/25(金) 04:44:14postfixでバーチャルサーバーやるときに
vpopmailみたいなツールあるのかな？
それとqmailadminみたいなシンプルな管理ツールもあるのかな？
0397名無しさん＠お腹いっぱい。
2008/01/25(金) 09:08:420398名無しさん＠お腹いっぱい。
2008/01/25(金) 09:32:59vpopユーザのアカウントとパスワードを、システムアカウントにしたいと思ってます。
システムアカウントから、vpop形式にするには、vconverterと言うプログラムがありますけど、
この逆の事がしたいのです。
何か、良い方法ってあります？
0399名無しさん＠お腹いっぱい。
2008/01/25(金) 15:01:46なんだかここではvpopmailが人気だな。
0400名無しさん＠お腹いっぱい。
2008/01/26(土) 00:12:07vpopmailのアカウント管理って、どの形式でやっとるん？
LDAPに移行して、LDAPで認証する、とかどない？
>>399
そりゃ、vpopmailだとWebから管理するためのツールがついてくるからね
0401名無しさん＠お腹いっぱい。
2008/01/26(土) 09:38:09LDAPもsqlも使ってなく、通常ののvpopパスワード形式です。
0402名無しさん＠お腹いっぱい。
2008/01/30(水) 14:12:12ローカルで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だと出ません。
0403名無しさん＠お腹いっぱい。
2008/01/30(水) 15:26:25削除されないで MTA に渡ってきたときに MTA が消すのを
小さな親切と考えるのが sendmail や postfix、大きなお世話と考えるのが qmail。
0404名無しさん＠お腹いっぱい。
2008/01/30(水) 15:55:05ありがとうございました。
0405名無しさん＠お腹いっぱい。
2008/01/30(水) 16:40:09削除というか、普通はヘッダに付けないのでは？？
0406名無しさん＠お腹いっぱい。
2008/01/30(水) 23:09:28Bccの受信者が安易に返信しない様に
Bccを残すべきという考え方もある
Bccが付いたメールに返信する場合に
警告するMUAはまだ見たことがないが
0407名無しさん＠お腹いっぱい。
2008/01/30(水) 23:32:33わかりません
ttp://www.puni.net/~mimori/rfc/rfc2822.txt
前略
"Bcc"フィールドの使用には３つの方法がある。最初は、Bccフィールドを持つ
メッセージの送信準備が出来たとき、すべての受取人（Bccフィールドで指定
したものも含む）にメッセージのコピーが送られるが、Bccの行が削除される。
２つめの場合、ToやCcで指定した行で規定される受取人それぞれは上記と同じ
く、Bcc:の行が消されたメッセージのコピーを受け取るが、Bcc行にある受取
人はBcc行を含むメッセージの別のコピーを受け取る。（Bccフィールドに複数
の受取人アドレスがあるなら、いくつかの実装では実際、その特定の受取人の
アドレスだけを含む、それぞれの受取人への別々のメッセージのコピーを送る）
最後に、Bccフィールドはアドレスを持っていないかもしれないので、ブライ
ンドコピーが誰かにおくられたということを受取人に示さず、アドレスなしの
Bccフィールドとして送られる。Bccの利用をいずれの方法で行うかは実装依存
だが、この文書の「セキュリティに関する考察」のセクションをめいめいの議
論のために参照せよ。
後略
0408名無しさん＠お腹いっぱい。
2008/01/31(木) 09:21:430409名無しさん＠お腹いっぱい。
2008/02/15(金) 17:15:06ttp://www.puni.net/~mimori/rfc/rfc2821a.txt
>一般に、リレーするSMTPは、その受けとったメッセージ内容が有効であり、
>エンベロープにそれを許可するように書かれており、内容を検査することな
>るリレーするべきである(SHOULD)。
↑「る」は「く」の誤り
(中略)
>セクション2.4.1で議論したように、リレーのSMTPはメッセージのヘッダやボ
>ディのデータを調べたりそれにより動作したりする必要はなく、自分自身の
>"Received:"ヘッダを加えること、またオプションでメールシステムのループ
>を検出する(セクション6.2を見よ)ことを除きそうしてはならない(MUST NOT)。
(中略)
>メッセージがメール環境の境界を超えてゲートウェイされるのに必要な時、
>ヘッダフィールドを書き換えてもよい(MAY)。これは、セクション2.4.1での禁
>止事項にもかかわらず、メッセージボディの検査や宛て先のローカルパートの
>解釈を含んでもよい。
0410名無しさん＠お腹いっぱい。
2008/02/21(木) 00:54:53これじゃアンチや信者と変わらない
http://ya.maya.st/
0411名無しさん＠お腹いっぱい。
2008/02/21(木) 00:59:20たとえばどこが間違ってるの？
0412名無しさん＠お腹いっぱい。
2008/02/21(木) 09:17:33そこをdisるなんて勇気あんな。
よっぽどqmailに詳しい人でも、たぶん間違いだらけって指摘のほうがまとはずれ。
0413名無しさん＠お腹いっぱい。
2008/02/21(木) 11:49:380414名無しさん＠お腹いっぱい。
2008/02/21(木) 23:24:170415名無しさん＠お腹いっぱい。
2008/02/22(金) 10:24:34unixの改行がLFなのは自明のことなのにCRLFがうまく変換できないとか
そもそも改行に2バイトも使うRFCにも問題があるのにCRLFのままで保存しろとか
qmailの「安全でないパッチ地獄」が問題だと言うが元々バグだらけのものに「最新の」パッチを沢山当てることは安全なのかとか
まともなことも沢山言っているが偏見による間違いも多い
qmailは駄目を前提に悪い印象を与えようとするDHMO的な文章の書き方だと思う
偉い先生なのかもしれないが俺程度が間違いを指摘できるようでは鵜呑みにはしないほうがいい
0416名無しさん＠お腹いっぱい。
2008/02/22(金) 11:23:19> 例えばRFCに準拠してないと言っているが準拠の基準となるRFCがqmailが作られたより後にできたRFCとか
現状にあってないてことじゃんｗ
0417名無しさん＠お腹いっぱい。
2008/02/22(金) 11:28:33思っているんであれば別に従う必要はないんでないすかね。
個人的にはやまやの書いていることは同意出来ること多いと思います。
ま、人は人、自分は自分、でいいんじゃない？
0418名無しさん＠お腹いっぱい。
2008/02/22(金) 11:33:00> 例えばRFCに準拠してないと言っているが準拠の基準となるRFCがqmailが作られたより後にできたRFCとか
それだけメンテされてないってのは問題でしょう。
> unixの改行がLFなのは自明のことなのにCRLFがうまく変換できないとか
いまいち意味がわからん。
もうちょい詳しく。
> そもそも改行に2バイトも使うRFCにも問題があるのに
どんだけディスク小さいんだよ。
> qmailの「安全でないパッチ地獄」が問題だと言うが元々バグだらけのものに「最新の」パッチを沢山当てることは安全なのかとか
これも意味がよくわからん。
0419名無しさん＠お腹いっぱい。
2008/02/22(金) 12:24:36法は過去に遡って適用されない
従って「違反」ではない
最初にも述べたが問題にしてるのは詭弁や虚言と自分の間違いは改めない態度であってqmailの現状を擁護しているわけではない
それと現状にそぐわないの原因になっていた変なライセンスはPDLになったことで解消されている
問題の指摘の方こそ現状にあってない
0420名無しさん＠お腹いっぱい。
2008/02/22(金) 12:33:33それを完全に無視してリリースしてしまった上、その後修正しなかったのは
よろしくないと思うけど。
0421名無しさん＠お腹いっぱい。
2008/02/22(金) 12:40:51qmail-injectは単純にLFをCRLFに変換する
CRLFだとCRCRLFになってしまうという話
>どんだけディスク小さいんだよ。
確かに圧縮という意味では貧弱すぎる
しかしファイルに保存した場合1byteの違いが512や1024の違いになることを考えればわざわざこんな設計はしない
ディスクの浪費は資源の浪費であり富める者の傲慢でもある
> qmailの「安全でないパッチ地獄」が問題だと言うが元々バグだらけのものに「最新の」パッチを沢山当てることは安全なのかとか
パッチを集中管理して検証してないから安全でないということだと理解したがパッチはqmail.orgなどで集められているし「最新」のパッチが十分検証されているはずがないので他が安全だということにはならない
0422名無しさん＠お腹いっぱい。
2008/02/22(金) 13:20:47> パッチはqmail.orgなどで集められているし
単に集積されてるだけでしょう。
集中管理して検証してるの？
> 「最新」のパッチが十分検証されているはずがないので
どのパッチのことを言ってるんだ？
> 他が安全だということにはならない
「他が安全だ」なんて言ってたっけ。
0423名無しさん＠お腹いっぱい。
2008/02/22(金) 13:39:260424名無しさん＠お腹いっぱい。
2008/02/22(金) 14:56:32> 法は過去に遡って適用されない
> 従って「違反」ではない
現状にあってないと書いただろ。最新の RFC に適応していない、qmail を現在
進行形で運用していることについて言っている。
> 最初にも述べたが問題にしてるのは詭弁や虚言と自分の間違いは改めない態度であってqmailの現状を擁護しているわけではない
おまえこそ詭弁だな。
0425名無しさん＠お腹いっぱい。
2008/02/22(金) 20:03:03新規参入しようつうヤツが、どっから手をつけたら
良いのか迷うところが問題。
0426名無しさん＠お腹いっぱい。
2008/02/22(金) 20:19:20自覚が有るから責任放棄しただけだろう
0427名無しさん＠お腹いっぱい。
2008/02/22(金) 21:36:08042881
2008/02/22(金) 22:15:23単に集積と集中管理がどれほど違うのか
他(例えば先生が勧めるPostfix)が集中管理して検証しているのならば例えばコアなコミッターが何日か数人で検証したところで作った人自身が注意深く作るのとどれほど違うのかと言っている
検証とは世界中の人に公開されてある程度少なくとも数ヶ月くらいは晒されることだと思う(論文なんかはもっと長いし)
だから「全て」の最新のパッチが十分検証されているはずがないと言った
「qmailは安全ではない他のものを勧める」から「他が安全だ」という印象を持つだろう
他のものを勧めるなら少なくともqmailより安全であることを説明できなければ公平とは言えない
>>424
だから現状を擁護しているわけではないと書いている
現状にあってないなら現状にあってないと書くべきでRFC違反だと書くのはおかしいと言っている
どこがどう詭弁なのか説明してくれ直すから
俺は先生の文のどこが詭弁なのか説明したつもりだ
>>425
>>426
折角レスくれたのに申し訳ないがそういうところがあると思うので議論するつもりは無い
なんか俺が詭弁と言い出したことで詭弁で遊ばれてる気がしてきた
ちょっと疲れたからまた気が向いたら来るわ
■ このスレッドは過去ログ倉庫に格納されています