Sender ID：送信者側の設定作業
SPFレコードの定義 SPFレコードの定義には「+mx」や「+ip4:xxx.xxx.xxx.xxx」のように、メールを送信する可能性のあるサーバの条件を記述するディレクティブか、「redirect」や「explanation」などのモディファイヤを指定できる。 ディレクティブはメカニズムとクオリファイヤで構成される。メカニズムには対象となるホストのパターンを、クオリファイヤにはパターンにマッチするホストの扱いについて指定する。 例えば、 とした場合、「+」がクオリファイヤで「ip4:xxx.xxx.xxx.xxx」がメカニズムになる。 受信側の認証処理では、メールを送信してくるホストのIPアドレスがメカニズムの定義にマッチするかどうかをチェックし、マッチした場合はクオリファイヤに示される値を認証結果とする。受信側での認証結果の判断について詳しくは次回に説明する。 クオリファイヤは省略可能
よくある質問｜@niftyメール
なりすまし・偽装メール対策について @niftyのメールアドレスで送信されるメールに対して、「SPF（Sender Policy Framework）」を適用し、メールアドレスのなりすまし防止に努めています。 また、@niftyのメールアドレスに受信するメールに対して、「Authentication-Results」ヘッダーを付与し、なりすまし・偽装メールの受信防止に着手しています。 【送信ドメイン認証とは】 送信されたメールの身元を検証するため、ドメイン名の部分での認証を行うことです。 @niftyでは、お客様から送信される@niftyメールに「SPF（Sender Policy Framework）」によるIPアドレスに基づく認証方式を適用し、送信元の証明を行っています。 また、@niftyのメールアドレスに受信するメールに対して、「SPF（Sender Policy Framewor
間違いから学ぶSPFレコードの正しい書き方 : 迷惑メール対策委員会
岡山大学 山井成良 2011年4月 1. はじめに 2. 典型的な誤りと正しい書き方 2.1 SPFレコードが複数行存在する 2.2 機構（メカニズム）の記述に誤りがある 2.3 参照方法に誤りがある 2.4 必要な空白文字がない 2.5 その他の間違い 3. チェック方法 1. はじめに 迷惑メールは、現在のところ、送信元アドレスが詐称された状態で送られるものが大多数を占めます。これにより、迷惑メールの送信源追跡を困難にしたり、フィッシング詐欺に利用されたりします。そこで、送信元アドレスの詐称を防止する送信ドメイン認証技術が開発されました。 現在までに実用化されている送信ドメイン認証技術はいくつか存在しますが、そのうち最も普及しているものがSPF（Sender Policy Framework）です。平成22年6月時点におけるjpドメインでの普及率はドメイン数ベースで約40パーセントであ
smtpサーバが迷惑メールサーバと思われないようにする
DNSの逆引き設定 今まで逆引き設定していなかったメールサーバから送ったメールには Received: from sv.domain.com (sv.domain.com [127.0.0.1]) by mail.domain.com (Postfix) with SMTP id… のようなヘッダとなっていて、localhost(127.0.0.1)から送られたものだとされていた。 これが迷惑メールとされる一因なので、mail.domain.com はちゃんとしたサーバですよー、と知らせるためにグローバルなIPアドレスをあててあげる。 DNSの逆引きはドメインの管理とは関係ないので、回線業者が提供するサイトなりツールから設定。メールサーバのドメインが mail.domain.com、IPアドレスが111.222.33.4 の場合。 111.222.33.4にmail.domain.comを
Amazon EC2のサーバからメール送信をするまでにやるべきこと (スパムメール扱いを回避する！) - 元RX-7乗りの適当な日々
先日のデブサミ2010でも話した(デブサミ2010の資料"クラウドサービスAmazon EC2を活用した「SKIPaaS」構築事例"を公開します＋α)のですが、Amazon EC2のサーバからメールを送信すると、一部分の宛先(メールサーバ)では、迷惑メール(SPAM)扱いされ、突き返されちゃう事があります。 それをどう解決したかという話。 Twitterを見ていて、まだきちんとした情報がまとまっていない気がしたので、経験談をまとめてみます。 課題 Amazon EC2のサーバがスパムメール送信に利用されるケースが増えているようで、Amazon EC2で利用されているIPアドレスのレンジ(ネットワーク)が、スパムメールのブラックリストにまるっと載ってしまっているため、メールサーバによっては、門前払いによる受信拒否となるケースがあります。 参考： Amazon EC2を悪用したセキュリティ攻撃
仙石浩明の日記: SPF (Sender Policy Framework) チェックをパスしてしまう迷惑 (スパム) メールが増えている
私の自宅サイト 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」というのは、 このメール (実は迷惑メー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.qunea.com/blog/log/20080801-1749.html