アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
メールの規格を (スコア:0)
メールに使われている技術というか規格そのものを変更することは出来ないの?
Re:メールの規格を (スコア:5, 参考になる)
例えばメール技術、仕様に対するチャレンジとしては、OP25Bの導入がありましたが。
あれも結局のところ「一次元を特定やすくする」ことで抑制力が多少は生まれていますが
根本的な「SPAMを送信できなくする」という技術ではないため未導入経由で送信されます。
極端な話。 botnetが存在する限り。 botnetを利用して、全員がmsnなりyahooなりアカウントを取得するよう仕向けて、
そのアカウント経由でSPAM送信するようなプログラムを打破するには、「文章を見る」以外に方法はないでしょう。
そして、文章を見る。というのは、貴方が受信しなくともサーバが受信した後。というわけです。
私は、このspamhereなメールアドレスに送信されたものを自動的に全てアサシンに学習させて
**SPAM** をサブジェクトに入れさせてフィルタしていますが今のところ後手でも耐えられています。
(たまに、ハウステンボスからの必要な広告メールまでspam扱いされちゃうのですがホワイトリストは、あまり使いたくないんだよなぁ...)
先手を考えるとなると...。
やはり免許なり認証が必要になるんでしょうか。 ハムみたいに。
==========================================
投稿処理前プレビュー確認後書込処理検証処理前反映可否確認処理後……
Re:メールの規格を (スコア:5, おもしろおかしい)
Spam Mail Transfer Protocolでどうだろう。
Re:メールの規格を (スコア:3, おもしろおかしい)
その結果どうなるかというと:
・ごく一部のマイノリティは「俺たちの権利が侵害された!」とネットで暴れる
・ユーザーは乗り換えコストを聞いた途端「ユーザーにコスト負担させるな、これだから技術屋のオナニーは」と愚痴り始める
・既得権益がある連中は何がなんでもでも「新規格は失敗だ、切り替えは止めるべき」と情報操作に遁走する
・一番乗りは損なのでベンダーもサービス提供者もユーザーも切り替え期限ギリギリまで待つチキンレースになる
・関連ストーリーが立つ度に「どうせメールなんてもう使ってないし」と宣言する人が現れる
あれ、どっかで聞いたことあるような。
署名スパムがウザい?アカウント作って非表示に設定すればスッキリさ。
Re: (スコア:0)
Re: (スコア:0)
Re:メールの規格を (スコア:1)
つっこむ所はそこじゃないだろ (スコア:0)
Re:メールの規格を (スコア:1)
しれませんが、時間の問題かと。
その前提で行くなら「頻繁な規格変更でも世界中のユーザーが問題無く使い続けられる仕組み」
なんてのを作ってからじゃないと。メーラー使ってたら「新しい規格パターンファイルがダウン
ロードされました」とかって新規格に変わるとか(笑
#ほぼ脊椎反射で書いてますので細かい突っ込みには耐えられません。
Re:メールの規格を (スコア:1)
Re:メールの規格を (スコア:1)
ATOKの反応がなんか鈍いと思ったんですよ...
(脊椎と反射で単語が切れていた)
Re: (スコア:0)
○脊髄反射
脊椎は骨。脊髄は神経。
あくまで反射するのは神経である脊髄ですね。骨である脊椎は反射しません。
しかし、もしかしたら「脊椎動物特有の反射現象(内臓反射や姿勢反射など)の総称」として脊椎反射という新語が生まれつつあるのかもしれません。
「とても」が肯定的な意味で使われるようになったように、「新たしい(あらたしい)」が「新しい(あたらしい)」になったように、「あきばはら」が「あきはばら」になったように、言葉は生まれ変わるものですしね…。
Re:メールの規格を (スコア:1)
Re:メールの規格を (スコア:2, 参考になる)
やたらと来るようになりました。
みんなが対応する前に、SPAMERが対応しちゃったら、どうしようもないですね...orz
SPFやDKIMはspam防止手段じゃないだろ (スコア:0)
Re:SPFやDKIMはspam防止手段じゃないだろ (スコア:2, すばらしい洞察)
したり遮断したりアカウント停止したりできなかった(そんなことしたら、無実の人に被害が及ぶので)けども、
SPFやDKIMによって、それがやりやすくなるという点でspam抑制効果は高いと思いますよ。
#それぞれの開発された経緯も、元はといえばspam対策なんじゃないですか。
Re:メールの規格を (スコア:1)
でどうでしょう?
…実装は、たぶん、ない。
Re: (スコア:0)
False Positiveその他の不都合への考慮はもちろん必須ですが、いきなり
「免許が云々」とか極端な話にいく前に、既にいろいろ提案されている方法に
目を向けてほしいなぁ、と思います。
Re: (スコア:0)
他にもS25Rの単独使用を嫌う人も居るみたいですし。
最低限自動救済の仕掛けを用意しておかないと実際問題として厳しいかと。
うちでもメールサーバーは動いていますけど
結局IPとかFQDNレベルではじくのは現実的ではないという結論に達し
bsfilterを上手く学習させることで99%のSPAMは防げているようです。
もっとも上手い学習というのが曖昧なんですが.....
Re:メールの規格を (スコア:2, 興味深い)
greylisting(あやしいホストからの接続は、再送要求を出して切断)や
tarpitting(あやしいホストからの接続は、一定時間待たせる)は、
正しく実装されたMTAであれば「メールが届かない」という問題は発生しないはずなので
救済は不要ですね。
greylistingは「あやしいけど問題ないホストからのメール」が届くのに数時間の遅延が発生するのが、
すごく使い勝手が悪いというかリスクが大きいですが、
tarpittingの方はリスクは無いしかなりうまい方法だと思ってます。
というわけで、S25R+tarpitting [srad.jp]でやってますが、なかなか快適です。
bsfilterも併用しているのですが、bsfilterだけのころは1日100通ぐらいくぐりぬけていたのが、両方併用で1日10通ぐらいに減りました。
(1日100通でも、6000通中の100通=98%のスパム検出が出来ているのですが、とにかく絶対数が多すぎで…)
あと、bsfilter は、false positive が発生しやすいのが難点です。
特に、普段日本語のメールだけを扱ってると「英語のメールは全部spam」みたいな学習をしがちで、たまに来た英語のメールがのきなみスパムに分類されたりとか…