アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
送信元証明 (スコア:1, 興味深い)
というようなことをするようにすればいいのでは?
もともと送信元に連絡が取れないものはサーバ間移動時に破棄する。と。
サーバとメーラ 両方の対応が必要になりそうだけど
どっちもたいした変更が必要とも思えないし。
大手のメーラが標準で対応してくれれば一気に広がるかな?
spamを駆逐できるとは思うんだけど。
Re:送信元証明 (スコア:2, 興味深い)
いつのまにかRFCになってました。
SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message [rfc-editor.org]
RFC4405~4408の4部作だそうで。
そろそろうちにも入れてみるか、qmailでの実装はどうなってるんだろう、と調べてみると、
SPF checker [saout.de]というのがあるようで。けどSPFって、SenderIdへ統合される元の規格だよなあ。
やっぱちゃんとRFC読もう。
Re:送信元証明 (スコア:5, 参考になる)
patchなどが提供されていますね。
http://new.openspf.org/Implementations [openspf.org]
一方、SPFと並んで出てくるDomainKeysについても
主要なMTAでは既に使えるようになっているようです。
http://domainkeys.sourceforge.net/ [sourceforge.net]
SPFはあるメールアドレスのメールを外部に送信
できるホストが何れかを明示する技術で、
DomainKeysはあるメールが特定のメールサーバーを
通ったことを証明する技術ですね。
前者はプロバイダーのメールサーバーから送ったメール
だけが正当なメールのような状況を作りたいときに
使え、後者は分散配信しているメールマガジン
のように、正当な送信者であるかの確認を送信の
ための接続のときに一箇所で行い、それを五月雨式に
配送するような場合に向いているでしょう。
しかしながら、これらの技術は共存できる技術の
筈なのに悲しいかなメール送信ユーザーを多く抱えている
hotmailもYahoo!メールもお互いの技術を使おうと
しないんですよね。