アカウント名:
パスワード:
spammerが自分のspam送信用ドメインにSPF設定することもできるわけ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
大賛成 (スコア:1, 参考になる)
何か問題あるの？
ちゃんと規格の進化をフォローアップして適宜新しい設定を加えていくのは当然のことだろう。
Re:大賛成 (スコア:2, 興味深い)
TXTレコードの編集に対応していないところもまだあるんですよね。早いところなんとかして欲しい。
Re:大賛成 (スコア:2, 参考になる)
# 使ってるのでAC
Re:大賛成 (スコア:2, すばらしい洞察)
spammerが自分のspam送信用ドメインにSPF設定することもできるわけ。
DNSキャッシュ汚染攻撃とかと組み合わせれば、自分のドメインだって
持っている必要もない。
spammerがSPFを活用することに気づいていない、またはほとんど使われて
いないから無視している今の状態ならば、若干の効果は見込める。
でも、SPFが一般化したら、spammerもSPFに対応するだけかと。
Re:大賛成 (スコア:4, すばらしい洞察)
SPFってspamに対して効力を発揮するのではなく，
なりすましに対して効力を発揮するものではないの？
Re:大賛成 (スコア:2, 興味深い)
別にそれでいいんです。
Japan Email Anti-Abuse Group [jeag.jp]のドキュメントにもあることだけど、今やれる事をやる事によって、spammerのoptionをたとえ一時的にでも減らす事ができればいいのです。
今やれる事はSPFだけじゃないです。実際SPFだけでなくSenderIDやDomainkeysを採用するISPもあるし、Outbound Port 25 Blockingは多くのISPが採用(して|し始めて)います。
このニュースはそういう流れのごく一部に過ません。
Re:大賛成 (スコア:1)
BOTネットを使っていないspammerなら、それもいえるでしょう。
ただ、BOTネットを使っているspammerの場合、ciderが/2とか/4とかの、ありえない設定になっちゃいませんか？
つまり、大規模なspam屋さんがSPF使った場合、spam判別を簡単にするだけだと思うのですが、どうでしょう。
Re:大賛成 (スコア:0)
> spammerが自分のspam送信用ドメインにSPF設定することもできるわけ。
> でも、SPFが一般化したら、spammerもSPFに対応するだけかと。
スパマーがどんなにSPF設定していても、そのドメインを受信者に受信許可してもらわないとスパムは送信できないと思う。
Re:大賛成 (スコア:3, すばらしい洞察)
ドメイン管理者はSPFを自分のドメインに対して設定することで、管理下のサーバ以外(つまりspammer御用達のサーバ)からそのドメインを用いたメールを送信できないようにできます。
つまりspammerが自前のドメインとサーバを持っているなら、無力です。
Re:大賛成 (スコア:1)
ノビタノビ.comがブロックされると
ノビスケ-ノビ.comのドメインで
さらに、コイビトタチ.comなど、そして....
ブラックリストにも載ったようで、せっせとドメインを変えてはspamを発信していましたが消えていきました。
自前ドメインは対策しやすいので無力とはいいがたいのでは。
#どちらかというと、ご苦労様というかマヌケなspamerに見えたものです。
Re:大賛成 (スコア:0)
そのドメインを受信者に受信許可してもらわないとスパムは送信できないと思う。
そのドメインを受信者に受信許可してもらっていないのに、どうやって受信者に受信してもらうの？
Re:大賛成 (スコア:1)
>そのドメインを受信者に受信許可してもらわないとスパムは送信できないと思う。
SPF以外に「ドメインの受信許可」という手段(ホワイトリスト？)を用いるのであれば、受信許可してもらわないとスパムは送信できないでしょうね。
それともSPFは受信許可ではなく送信許可だというのが通じていない？
SPFとセットでブラックリストやホワイトリストを設定する場合もあるけど、あくまでSPFと併用しているだけで、SPFにはブラックリストやホワイトリストによるドメインごとの受信(許可|拒否)という概念はありませんよ。
Re:大賛成 (スコア:0)
受信許可だろうが、送信許可だろうが、受信者が受信許可していなければ受信者には届かない。
Re:大賛成 (スコア:0)
Re:大賛成 (スコア:1)
SPFに「受信者が受信許可する」という概念はありませんからね。
とひたすら書いているのに通じないということは、単にSPFを知らずに書いてるんじゃなくて、何か別の技術とSPFとを混同しているんだろうか。
それはそれで興味深い…。
Re:大賛成 (スコア:1)
気持ちはわかるし、それもこれも SPF とは別の話だということもわかってるけども。
Re:大賛成 (スコア:1)
実際このトピックの主題はSPFの話ではなくてそのメールを受信者側が受け入れるか、条件付で受け入れるか、全部拒否するか選べるようになるって話しですし。
だからあなたも元コメントの人も別に間違ってはいませんよ。認識があっていないだけで。
Re:大賛成 (スコア:0)
Re:大賛成 (スコア:1, フレームのもと)
>ドコモにメールを出す場合はDNSサーバでSPFの設定をしろ
というように強要するならね。
じゃなくて、コメントつけるなら「」の中じゃなくその外側の問いに対して、
>これって「ドコモにメールを出す場合はDNSサーバでSPFの設定をしろ」という事にならないでしょうか。
ならない、と答えてあげればすむ事です。
Re:大賛成 (スコア:0, フレームのもと)
でも、他者にそれを強制したりクレームつけるような奴が現れるのは願い下げ。だって、Experimental RFCなんだから。
Re:大賛成 (スコア:2, 興味深い)
モバイルで「どこでも同じメールアドレス」してるとSPFはあまり好きになれません。
送信側でヘッダをつければどこからでも出せるようになる DomainKeys の方が好みです。
こっちは送信側MTAの対応が必要っていう面倒くささがありますが…
Re:大賛成 (スコア:5, 興味深い)
どういう場合にこれが必要なのかわかりませんが。普通にsubmission portに繋いで認証の上、送ればよいかと思います。
こういう個人的な趣味はさておき、SPFはメーリングリストやメールの転送のように送信元のメールアドレスを使って再送信する場合に問題になります。メーリングリストマネージャなどがSPFを考慮していれば、エンベロープfromを書き換えて、対応することは出来ます。しかし、メーリングリストマネージャが書き換えないと、SPFに基づき受信拒否されることもあるでしょう。
かといって、DomainKeysやDKIMが万能というわけではありません。メーリングリストのようにSubjectの書き換えをする場合にはヘッダの内容が変わるため、そのメールが捏造されたものと認識されますので。
Re:大賛成 (スコア:1)
>身近なSMTPサーバ
とちゃんと断ってるって事はわかってるとは思うけど、一応
つ[SMTP Authentication + STARTTLS or SMTP over SSL]
でもしておきましょう。
Re:大賛成 (スコア:0)