(Mailsploitは『Display NameをRFC1342的にホゲることで正規のメールアドレス部分を隠蔽する』という手段で差出人アドレスをホゲるのであって、正規のメールアドレス自体をホゲる訳ではないのだが、素人さんはいろいろなことを言っているようだなぁw)
連載目次 メールサーバを運用しているなら、そこから送信した「正当な」メールが誤って迷惑メール(スパムメール)として判定されないよう、管理者として注意を払う必要がある。例えば、SPFやDKIMといった送信元認証、さらにはDMARC(認証に失敗したメッセージの取り扱いをコントロールするための仕組み)も適切に設定することが望ましい。 ただ、これらの判定結果を検証するには、受信側に届いたメールからいちいち複雑なメールヘッダを読み解かなければならず、なかなかに面倒な作業だ。 そんな場合はGmailを利用すると、送信元認証の判定結果を簡単に確認できる。具体的には、まず受信用のGmailのアカウントを1つ用意して(いつも使っているGmailアカウントでよい)、管理下のメールサーバからそのGmailアカウントに対してテストメッセージ(内容は何でもよい)を送信する。 そして次のようにGmail側でその「メッ
センドメール株式会社 (Sendmail, K.K.) 末政 延浩 2010年1月 1. SPFの背景 2. SPFの標準化 3. SPFの仕組み SPF送信側の設定 4. SPFレコードの記述法 5. SPF受信側の処理 6. SPF認証結果 7. SPFにおける課題 転送問題 第三者サーバ利用問題 8. Sender ID とSPF spf2.0とspf1 9. SPFの実装 10. SPFレコードの記述例 11. SPFレコードの間違い 有用な参照先 電子メールの送信者偽称を防ぐ送信ドメイン認証技術には、ここで説明する「Sender Policy Framework(SPF)」のほかに、「DomainKeys Identified Mail(DKIM)」、「Sender ID」など様々な方式が標準化されている。その中でもSPFは、他の方式に比べて既存システムに影響を与えず早期に導入で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く