DMARCがエンベロープ送信側（Return-Path）ではなくFromアドレスで動作するのはなぜですか？
ウェブサーバーからFrom:アドレスが[email protected]のGmailアドレスに送信されたいくつかのメールが、Gmailによってスパムとしてマークされています。 From:フィールドはフォームデータから入力され、訪問者の実際のメールアドレス（多くの場合Gmailアドレス）に対応しています。 Return-Path:は常にアドレス[email protected]を指しているため、SPFとDKIMのチェックが機能します。
Gmailアカウントで未加工のメールを検査すると、次のように表示されます。
Delivered-To: [email protected]
...
Return-Path: <[email protected]>
Received: from mywebserver.com (mywebserver.com. [my:ipv6:address])
by mx.google.com with ESMTPS id xxx
for <[email protected]>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 02 Feb 2016 00:40:02 -0800 (PST)
Received-SPF: pass (google.com: domain of [email protected] designates my:ipv6:address as permitted sender) client-ip=xxx;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of [email protected] designates my:ipv6:address as permitted sender) [email protected];
dkim=pass [email protected];
dmarc=fail (p=NONE dis=NONE) header.from=gmail.com
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mywebserver.com; s=mydkim;
h=Date:Message-Id:Sender:From:Subject:To; bh=w2snQznwxlVRVACmfQELC7VGmD1dcYdiCXbCIRYFKRs=;
b=a0Vy3Ky43J5FdiWSuQ4qvTTH47G+Js0W/qtRU5gMlxfesNqrlyaIyExaIZlWvHNL4o0LNOF1GI94w4C41mmH+2JIkMEQZazw0MainP7UyUgsm/RZbAWoRuecPv+k108FlsWMP/l1UttXAdlvBVJmV2UGsYYlSSjKErQEF8tv3K0=;
Received: from Apache by mywebserver.com with local (Exim 4.80)
(envelope-from <[email protected]>)
id 1aQWVF-00009b-2X
for [email protected]; Tue, 02 Feb 2016 09:40:01 +0100
To: [email protected]
From: Website User <[email protected]>
Sender: [email protected]
...
SPFとDKIMの両方のチェックに合格していますが、DMARCチェックには合格していないことに注意してください。 スタックオーバーフローに関するこの回答 に従って、いくつかの検索の後、From:アドレスを使用して参照ドメインを取得し、DMARCまでこれを追跡しました。
3つの質問：
- 確かに
dmarc=failがGmailによってスパムに割り当てられているメールの原因である可能性がありますか？ - DMARCがSPFおよびDKIMのように
From:（エンベロープ送信者）ではなくReturn-Pathアドレスで動作するのはなぜですか？ - ここで
From:ヘッダーもアドレス@mydomain.comに対応する必要がある場合、actual（logical、fleshと血）メッセージの送信者？
SPFとDKIMはメールパスを検証する方法と考え、DMARCはメッセージ送信者も検証する拡張機能と考えてください。これはFedExの書簡の配信と考えてください。封筒がどこから発送されたのか、および宅配便が合法であったことを確認するのは簡単ですが、封筒の中の文字が本当に名前が印刷されている人からのものであることを証明する方法はありません。
あなたのウェブサーバーはmywebserver.comの有効なSMTPサーバーであり、あなたの送信者アドレスは正当ですが、他のサーバーがあなたが[email protected]として送信する許可を持っていることを信頼するのに十分ではありません。サーバーがハッキングされていないか、悪意のある目的で使用されていないことをGMailはどのようにして知るのですか？ Gmailのサーバーは、ユーザーの1人としてメールを送信することを盲目的に信頼するつもりはありません。ホストされている場合を除き、Yahooへの送信に問題が発生する可能性があります。
質問の最初の部分に対処するために、はい、Gmailがスパムとして分類しているのはこのためです。最も古い形式のスパムは、「差出人」アドレスのなりすましを中心としています。これは、ほとんどのユーザーがメッセージを受け取ったときに表示されるものであり、信頼したい主要なフィールドです。正当なメールサーバーからのメッセージが、そのメールサーバーに属していない差出人アドレスを使用して送信された場合、それは依然として赤旗です。
ご指摘のとおり、DMARCは仕様の一部としてFromアドレスを操作します。確かに、誰かに代わって送信するWebアプリを作成することは難しくなりますが、それは要点です。 whyについては、それを行います。まあ、それは仕様の設計者次第ですが、トレードオフです。彼らは高い道を進んでいて、その制限内に留まれば非常にうまく機能するシステムを作っています。おそらく、将来のメカニズムがこれを回避する方法を見つけるでしょう。
不幸な解決策はあなたがコントロールできるアドレスだけを使うことです。 3番目の質問に対処するには、ドメイン名を使用してメッセージに署名し、website-user @ gmail.comに代わって送信されたことを本文に記載します。それ以外の場合は、受信者にアドレスをホワイトリストに追加するように要求する必要があります。正規のWebアプリ開発者にとってはそれほど楽しいことではありませんが、受信者の受信トレイの神聖さを保護します。 Webユーザーの電子メールアドレスでReply-Toヘッダーを使用して運が良かったかもしれません。
このDMARCスレッド に関するこの制限についての議論があります。
当面は、RBLでサーバーがブラックリストに登録されていないことを確認してください。 DMARCに失敗しても、十分な評判がある場合は一部のスパムフィルターを通過する可能性がありますが、私はそれに依存しません。
1）はい、おそらくdmarcの失敗により、Gmailがメールをジャンク化します
2）この回答にも興味がある
3）顧客アドレスの返信フィールドを使用します（使用します）。メールは次のようになります。
from：[email protected]
件名：お問い合わせフォーム
お役に立てれば
「なぜ」という2つの質問があります。
- なぜ受信メールサーバーがこの方法でチェックを実行するのか
- それが RFC 7489のセクション3.1 が行うように言っていることだから
- DMARCがそのように設計されたのはなぜですか？
- それを設計した人々はどうやら RFC 5322のセクション3.6.2 を読まなかったか、誤って解釈したか、無視したためです。
このセクションでは、Sender:ヘッダーが存在する場合、メッセージの送信を担当する当事者を特定するために、From:ヘッダーよりも優先されることを明確に規定しています。
「Sender：」フィールドは、メッセージの実際の送信を担当するエージェントのメールボックスを指定します。たとえば、秘書が別の人にメッセージを送信する場合、秘書のメールボックスは[送信者]フィールドに表示され、実際の作成者のメールボックスは[差出人]フィールドに表示されます。メッセージの発信者を単一のメールボックスで示すことができ、作成者と送信者が同一の場合、「送信者：」フィールドは使用しないでください。それ以外の場合は、両方のフィールドが表示されるべきです（SHOULD）。
これを RFC 7489 で与えられた理論的根拠と比較してください：
DMARCは、認証済み識別子と一致する（一致する）ことを要求することにより、RFC5322.Fromドメインの使用を認証します。 RFC5322.Fromドメインは必須のメッセージヘッダーフィールドであり、したがって準拠メッセージに存在することが保証されているため、DMARCメカニズムの中心的なアイデンティティとして選択されました、およびほとんどのメールユーザーエージェント（MUA）は、RFC5322.Fromフィールドをメッセージの発信元として表し、このヘッダーフィールドのコンテンツの一部またはすべてを利用者。
RFC 5322 がこのエラーを明示的に呼び出すため、このロジックには欠陥があると私は主張します。
注：トランスミッター情報は常に表示されます。 「Sender：」フィールドがないことは、メッセージの送信を担当するエージェントが指定されていないことを誤って解釈していることがあります。この不在は、送信者が作成者と同一であることを意味するだけであり、「送信者：」フィールドに重複して配置されることはありません。
DMARCは設計上、壊れていると思います。
- 送信する権限および著者の証明;
- 以前のRFCを誤って解釈し、
- その際、独自の
Sender:ヘッダーを追加することにより、以前に準拠していた自身を識別したリストサーブを破壊します。
Sender:フィールドが存在する場合、DMARCは that フィールドを認証し、From:フィールドを無視するように指示する必要があります。しかし、それはそれが言っていることではないので、私はそれが壊れていると考えています。
RFC 7489 続行：
したがって、このフィールドは、メッセージのソースを識別するためにエンドユーザーが使用するフィールドであり、したがって乱用の主なターゲットになります。
これは単に間違っています（Sender:ヘッダーを無視することを正当化するコンテキストでは）。 DMARCが設計された当時、一般的なメールクライアントはSender:とFrom:フィールドの情報の組み合わせをFrom name-for-mailing-list @ server に代わって[email protected]。そのため、見ているメッセージの送信を担当したユーザーにとっては、常に明確でした。
Reply-To:が適切な置換であるという提案にも欠陥があります。そのヘッダーは「置換受信者」ではなく「追加受信者」として広く誤解されており、元の送信者のReply-To:を置換すると、 those users。