アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
Gmailの問題点 (スコア:4, 興味深い)
いや、それだけじゃない。
Gmailの最大の問題点は、web経由でメイルを送信する際、クライアントのIPアドレスをヘッダに記録しない点にある。
このために、DNSBLが全く使えない。
これじゃspamの温床になって当然だろう。
Re:Gmailの問題点 (スコア:1)
Re:Gmailの問題点 (スコア:2, 参考になる)
以前は Received も送信者の IP が一番下になってた気がするのですが、最近は違うみたいです。
Re: (スコア:0)
殆どのIPが固定ではないIPになるだろうし・・・
DNSBLで排除できるものって
だと思うのですが…
IPがきちんと組織名の引けるIPだけとかにするなら、そもそもGmail全部ブロックすればいいんじゃね?
Re:Gmailの問題点 (スコア:1, 参考になる)
> * スパム業者のメールサーバ
> * リレーを許しているようなメールサーバ
> * 固定IPでは無いクライアントPCで立ち上げたメールサーバ
> だと思うのですが…
DNSBLに登録されるIPアドレスは、DNSBLサーバの運営者のポリシーで変わる。
その中には、単純にspam発信元IPアドレスを登録する、という、一見すると乱暴なものもある。
そういうポリシーのDNSBLは、受信側MTAでの運用には全く適さない。
その代わり、spamフィルタのスコアリングの手がかりになる。
spammerが多く利用するISPのIPから発されるメイルは、それだけで「怪しい」と言えよう。
その怪しさを、本文に記されるURLをURIBLで引っ掛けたり、ベイジアンフィルタでスコアリングする等で、より「spamらしさ」を評価することが可能になる。
日本語spamに限って言うならば、
中国から発された日本語メイルなら、それだけで怪しいと言えよう。
まだGmailの日本語spamはお目にかかっていないが、今後もしそういう類のものが現れたなら、送信元IPアドレスがわかるか否かがとても重要になる。
要するに、仮に正規のルートで発されたメイルであっても、送信元IPアドレスは十分手がかりになり得る、ということ。