ここで簡単に作れるよ
早く対応しないと、メールが送信できなくなるらしい
試してみたが、公開情報を登録するだけだから無問題。
SPFレコードで表示される値を入力するだけ。
可能性があるか」を書くだけ。
2はSPF自体の質問ではなくて、件のURL先が信用できるかどうか
心配していた訳。試したところ余計な情報（住所とか電話番号とか...）
を書く必要がないし、答えも妥当な物だったので大丈夫だよと。
ググルとでてくるしな
スパマーはテロに遭って死んで欲しい。
中身は何でもいいから以下のメールアドレスを送ると判定結果がメールで返ってくる。
sa-test at sendmail.net
check-auth at verifier.port25.com
また、ここで生成されるランダムなアドレスにメールを送っても OK。
http://senderid.returnpath.net/ （判定用メールアドレス自動生成）
普通書くだろう
それってoldじゃない？
相手がSPFに書いてあるサーバから送信したのかどうかを判定するには、どのように設定すればよいのでしょうか？
ttp://tatsuya.info/pukiwiki/?%A5%B5%A1%BC%A5%D0%B9%BD%C3%DB%B4%D8%B7%B8%2FPostfix%A4%C7SPF%2FDomainKeys%A4%CB%C2%D0%B1%FE%2FSPF%28C%29
検索ぐらいしろ
メール本体の From: はスルー？
どうなったんだろうな。
相変わらずライセンス結べって話しなんだろうか。
なんてないでしょ。SPAMフィルタの判定パラメータとして使ってる
(というかヘッダ含めて自己学習型のフィルタなら自動)例は結構
あるんじゃないかな。
docomo は pass 以外すべて拒否。
SPFレコードを参照する際のドメインはあくまで
エンベロープFromのドメインなんですね．
あと，SPF レコードがせってい「されていない」場合は
送りつけられた側ではどういう挙動をとるのが一般的なんでしょうか？
結局のところスパマーは SPF レコードが設定されていないドメインを
勝手に名乗って送りつけてくるだけのような気がして，
いまいち実効性に疑問を持っています．
SPF レコードが設定されていない場合はリジェクト，
というのはさすがにやりすぎですよね？ >>23 は
その辺の話をされているのでしょうか？
SPFが設定されていない場合はスルーじゃないかな？
うちが使っているのは完全スルーしてます。
ログ見てみると、ほぼ SoftFail ですが、たまーーーーーに
Fail でひっかかってリジェクトしている感じ。
無いよりマシって感じかなぁ。
envelope fromが詐称不可能になるだけでも効果はある。
漏れは自ドメインのSPFを設定しただけで後は放置。自分のメールが
届かないと困るが、spamは現状の対策で十分防げているからね。
TXT RR 書くだけなら Microsoft に文書送らなくてもいいみたいだが．
ボットからのメール送信を弾くには +all を許すと不味いと思うんだが。
さっき規制するって指定したんだけどSPF書いていない自鯖からメール送れる。
ヘッダ見るとSPF無いから neither permitted nor denied って判定されてるけど
都合が悪くなって来たら次のものに変えるよ。
v=spf1 include:spf.hi-ho.ne.jp include:spf-mow.mserv.hi-ho.ne.jp -all
って返ってくる。
んで、spf.hi-ho.ne.jpを見ると
v=spf1 ip4:202.224.159.128/25 ~all
spf-mow.mserv.hi-ho.ne.jpを見ると
v=spf1 ip4:202.32.78.136/30 ip4:202.32.78.168/30 ~all
んで、hi-ho からのメールが202.32.78.145から飛んでくる。
includeはPASS(+)になった場合ＯＫで、それ以外はスルーされると
思っているので最終的には -all で拒否られると思うんだが
なんか俺の解釈間違っている？
後ろのも条件にマッチしてても無視される。
マッチした時点でPassはわかるんだけど、上の例だとマッチしてないのね。
1) 202.224.159.128/25 は全然違うので取りあえず無視
2) 202.32.78.136/30 は 202.32.78.136 〜 202.32.78.139
3) 202.32.78.168/30 は 202.32.78.168 〜 202.32.78.171
で、実際にメールを送ってきたサーバが202.32.78.145
includeの中の~allは無視されると思うので（RFCにもincludeは一致したら
Passかどうかだけの判断って読み取れた）、一致しているかどうかだけで見ると
202.32.78.145は1,2,3どれにも一致してない。だから最後の-all で
拒否になると解釈したんだけど・・・
防げるはず。
多少スレに関係あるかなｗ
民主党は「なりすましメール」を許しません
ttp://www.dpj.or.jp/special/dkim/
TXT "v=spf1 include:example.com -all"
この違いがよくわからん…
なるほど。
aの場合
gmail.comを名前解決すると出てくる(xxx.xxx.xxx.xxx)を信頼
includeの場合
gmail.comでGoogleが設定したSPF情報(xxx.xxx.xxx.xxx/googlemail.comその他)を信頼
ということですね。
ありがとうございました。
ttp://internet.watch.impress.co.jp/docs/news/20110128_423398.html
どっちも役に立つ気はしないが、DKIMの方が圧倒的にマシ
_spf.example.comとか引くようにするならTXTでも構わんが、単純にTXTを引くとかありえない
さらに、メール転送したきゃSRSなり何なり対策しろとか、アホかと
顧客のメール到達性をよほど軽視してる奴か、またはメール配送の仕組みを理解してない奴でもなきゃ、最後に
-allなんて迂闊に書けたもんじゃないから、この先十年は役立たず確定な仕様だろこれは
rejectに関しても全く同様
NTTは平気で全面的に導入してるが、使ってる奴の一部は理由も知らないままメールが消えてるんだろうな
で、spamは別に減らないんだぜ、馬鹿馬鹿しい
推進なんかするな、こんな現状で
推進するなら、もっとマシになってからにしてくれ
効果も無い物の導入を推進することばかり考えず、もっとマシにする努力をしてくれ
OP25Bの推進は何とでも対応できるから割と賛成だったが、SPF推進は一度しっかり考え直して欲しいわマジで
いいことだ。