私の自宅サイト GCD (と勤務先の KLab) では、 qmail にパッチをあてて、 外部から届くメールのヘッダに SPF (Sender Policy Framework) チェックの結果を挿入するようにしている。 例えば以下のような感じ: Received-SPF: pass (senri.gcd.org: SPF record at thelobstershoppe.com designates 89.215.246.95 as permitted sender) Message-ID: <34f301c7df7d$2e65ece5$5ff6d759@unknown.interbgc.com> From: "Sales Department" <sales@thelobstershoppe.com> 「Received-SPF: pass」というのは、 このメール (実は迷惑メー
今日まっちゃさん(id:ripjyr)から、最近SPF設定してる日本語スパムが届いてない？という連絡をいただきました。 そこで、自分のスパム溜めを漁ってみると、確かに日本語スパムでSPFが通っているものがいくつかありました。 自分のところに着弾してたのはみな、裏DVDを売るスパムでした。 過去のメールも見てみると、どうも6/3あたりからSPFが設定されて出されているようです。 SPFって、誤解を受けやすいのですが、直接スパムを排除する仕組みではありません。 単に、その送信元のメールアドレスが正しいメールサーバから出されているか、を検証するだけの仕組みです。つまり、メールアドレスを騙られないようにするためのものです。 実は、スパマーが自分で取得したドメインにSPFを設定してスパムを出してくる、というのは想定されている事態です。 世のまっとうなサーバもスパマーのサーバもみなSPFを設定してくる
前回から 4 ヶ月ぶりとなる第２回 静岡 IT Pro 勉強会ですが、おかげさまで無事終了しました。 参加者・スタッフの皆さん、そして、講師の佐藤さん、umq さん、須藤さん、ありがとうございました。 今回は参加者 46 名（講師・スタッフ込み）と、第１回の 18 名から大幅に増えました。 最年少は 16 歳のSupaki さん。 関連サイト 静岡ITPro勉強会 第2回静岡IT Pro勉強会のご案内 静岡ITpro勉強会メーリングリスト 公式タグ ynagao さんに言われた公式タグですが、とりあえず、『静岡ITPRO勉強会02』でお願いします（って、ynagao さん、mixi 以外で書いてるんですか？）。 静岡ITPRO勉強会02の最新人気記事 10件 - はてなブックマーク いい感じの略称募集します! 勉強会レポ 「誤検知を減らし、安定した迷惑メール対策を行なうには」 佐藤さん（i
昨日、知人から言われて気がついたのですが、Gmail で転送の設定をしていると、転送の際に SMTP MAIL FROM を gmail.com に書き換えていますね。 SPFと転送の相性問題に対する解決案の案1と案2のいいとこ取りみたいな感じかな。 Gmail では転送した結果のエラーメールと、単なるエラーメールを区別するために、転送の際にローカルパートを書き換えています。 たとえば、Gmail が以下のようなメールを受け取ったとします。 MAIL FROM: RCPT TO: <ユーザ名1@gmail.com> example.com へ転送する設定では、以下のように転送します。 MAIL FROM: <ユーザ名1+caf_=ユーザ名2=example.com@gmail.com> RCPT TO: <ユーザ名2@example.com> このメールに対し、バウンスが起これば、こうなり
メールアドレスの詐称を判断できるようするドメイン認証には、いくつか種類があり、それぞれに長所短所があります。たとえば、こんな感じです。 SPF は、転送に弱いが、メーリングリストに強い DKIM は、転送に強いが、メーリングリストに弱い DKIM よりも SPF の方が簡単なために、SPF の転送を解決する方法がいくつか提案されてきました。これらはいずれも転送サーバに手を加える必要があり、やはりなかなか普及しません。 また、これらの問題を解決しないことには、受信側のドメイン認証は普及しないでしょう。正しいメールを誤って受信拒否する可能性があるからです。 2005年に SPF の父 Meng Wong 氏が日本を訪れた際に、直接会ってこの問題について尋ねたところ、「複数のドメイン認証の結果から総合判断すればいいのではないか」というアイディアを頂きました。 宿題を片付けるのに長い時間がかかりま
インターネットイニシアティブ（IIJ）は2008年08月28日、メールシステムに送信ドメイン認証技術「SPF/Sender ID」を実装したメールフィルタプログラムを独自開発、オープンソースソフトウェアとして無償公開した。ライセンスはBSD。送信元を詐称した迷惑メールへの対策として、企業やISPへの導入を促進する。 公開したのは、SPF/Sender ID認証用ライブラリと、このライブラリを利用したSendmail/Postfix用のメールフィルタプログラムの2点。ともにメール受信側に導入する。同社が2006年から商用サービス向けに適用しているメールフィルタ機能がベースで、厳しい商用サービス環境下でも安定稼働する品質という。 今後は、電子署名ベースの送信ドメイン認証技術「DKIM」に対応したメールフィルタプログラムの公開など、企業やISPの要求仕様にあった機能を随時強化していく予定。 送信
ドコモ同士はもちろん、他社のケータイやパソコンにも文字や静止画などが送れます。絵文字を組み合わせたメールを送ることもできます。 iモードメールへ
2007年10月21日(日) ■ 無題 _ まさかそんなことができるはずないだろうと思ったけど、まあ試すだけならタダだから、とやってみた。 _ ……できちゃった。えー。 _ えーと、ニコニコ動画は、プレミアム会員にならなくても混雑時間帯にエコノミーモードで画質を落とされずに閲覧できます。アカウントを取得したばかりのそもそもその時間帯にログインできないような人はさすがに無理だけど。 _ さすがに影響がデカいと思うのでその方法をバラすのはやめとくけど、そんなに難しいことはしない。 この前のスクリプトの場合だと1行修正するだけ。っていうか、ぱっと見てすぐに思いついたけどまさかほんとにそれでできるとは思わず、1週間ほど試さず放置してたわけで。あまりにカンタンすぎる方法なんだけど、greasemonkey や proxomitron のフィルタを公開しているサイトを探しても見つからないね。ニコ動の運
Overview These tools are meant to help you deploy SPF records for your domain. They use an actual RFC 7208 compliant library (pyspf) for tests and will dynamically test for processing limit errors (no other testers I'm aware of do this). This site uses a caching DNS resolver, so for tests that use live DNS, results will be cached for the Time To Live of the DNS record. For most basic uses, these t
About SPFWelcome to the Sender Policy Framework project!Read an introduction to what SPF is, or about how SPF fits into the bigger picture of e-mail authentication. Further ReadingStatistics on the adoption of SPF.SPF vs Sender ID – Is SPF the same thing as Sender ID? Which is better?FAQ – Frequently Asked Questions.Avoid these common mistakes made by domain owners (senders) and by receivers.Best
上記の「ステータス」というのは、メール配信時に付加される "Received-SPF:" ヘッダに表記される文字列です。 Received-SPF ヘッダに関する詳細は後述します。また、「メールの扱い」はあくまで代表的な例ですので、すべてのサーバーが上記のような動作をするとは限りません。最終的には受信側サーバーの裁量にいかんです。 Mechanism Mechanism はディレクティブの Qualifier を除く部分で、ホストのマッチングルールを指定します。多くの指定方法がありますので、それぞれ個別にご紹介します。 ip4 : IP アドレスによるマッチ "ip4" は送信元 IP アドレスが指定された IP アドレスと一致するかを確認する Mechanism です。書式は以下のようになります。 ip4:<IPアドレス> 例えば、 "+210.251.253.231" というディレクテ
送信ドメイン認証SPFレコードについて 送信ドメイン認証SPFレコードとは、メールを送信するサーバの情報をDNSサーバ上で公開し、送信されたメールのドメイン名とDNSサーバのSPFレコードとの整合性を受信サーバ側で確認することで、そのメールが正当なメールサーバから送信されたものかを認証する技術です。これにより、正当なメールサーバから送信されたメールと「なりすましメール」とを判別することが可能となります。その為には送信されているメールのドメイン (エンベロープFrom) と送信IPアドレスの関連をSPFレコードに記述していただく必要がございます。 RFC4408 (英文) Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 EZwebにSPFレコードを公開してメールを送信され
NTTドコモグループ9社（以下ドコモ）は、現在提供している迷惑メール対策に加え、新たに、なりすましメール対策として、インターネットからの送信元情報を詐称したメールを拒否する機能と、送信元アドレスに指定したドメイン部分が含まれる場合に受信を拒否する「ドメイン指定拒否」機能、さらに、迷惑メール対策機能の充実に伴い複雑かつ多岐にわたるようになった設定方法を、特に初心者やお子さまに簡易にご利用いただけるようにするための「かんたんメール設定」機能を2007年11月1日（木曜）より提供いたします。 ドコモでは、今後もお客様からのご要望をふまえ、安心してiモード®メールをご利用いただけるよう迷惑メール対策を積極的に推進してまいります。 なお、詳細は以下のとおりです。 「なりすましメール対策」について 機能提供開始日 2007年11月1日（木曜） 機能概要 お客様に本機能を設定していただくことで、パソコン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
