web-dev-qa-db-ja.com

DMARCが原因で、Gmailへの転送はMicrosoft.comからのメールでは機能しませんが、Paypal.comでは機能します

UNIXシステム経由で転送される特定のメールがGmailとYandex.Mailで受信されないことに気付きました（ [〜＃〜] srs [〜＃〜] —送信者書き換えスキームがまだベストプラクティスかどうかわからない？DMARCでは、メール自体の実際のFrom:ヘッダーにも適用する必要があると思うので、DMARC-から有効な送信者。

私は何が起こっているのか完全に理解できません。Microsoft.comと他の一部は拒否されます（受信側にDMARCを実装していないシステムにローカルに配信されるだけです）一方で、常に通過するメールにはPaypal.comが含まれます。

% echo _dmarc.{Microsoft.com,Paypal.com} | xargs -n1 Dig -t txt | fgrep v=D
_dmarc.Microsoft.com.   3302    IN      TXT     "v=DMARC1\; p=reject\; pct=100\; rua=mailto:[email protected]\; ruf=mailto:[email protected]\; fo=1"
_dmarc.Paypal.com.      3311    IN      TXT     "v=DMARC1\; p=reject\; rua=mailto:[email protected]\; ruf=mailto:[email protected]"
%

両方のドメインが同じrejectポリシーを持っている場合—および Googleは、Paypalが明確な拒否ポリシーを持っていると具体的に言及しています —私は違います私自身の設定に問題があるのか​​、それとも送信側のせいなのかを正確に確認します。何か案は？

それは、SPFのフェイルとソフトフェイルのどちらが原因なのか、それともそれ以上のことなのか？

% echo {Microsoft.com,Paypal.com} | xargs -n1 Dig -t txt | fgrep v= | sed 's#[^[:space:]]*:[^[:space:]]*#:#g'
Microsoft.com.          3332    IN      TXT     "v=spf1 : : : : : : : : : : -all"
Paypal.com.             300     IN      TXT     "v=spf1 : : : : : : ~all"
%

転送を介して配信されるPaypalメールについてGmailが報告する内容は次のとおりです。

ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass [email protected] header.s=pp-epsilon1 header.b=K96c6GUZ;
       spf=fail (google.com: domain of [email protected] does not designate 2001:470:7240:: as permitted sender) [email protected];
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=Paypal.com
Return-Path: <[email protected]>
spfgmaildkimdmarcsrs
2
cnst

DMARCポリシーは、From:ヘッダーで使用されているドメインを保護しています。DMARCチェックに合格するには、DKIMまたはSPFでこれをalignする必要があります。 SPFの場合、これには、合格したSPFテストと一致するエンベロープ送信者（つまり、Return-Path、つまり、SMTP MAIL FROMコマンドで使用されるアドレス）が必要です。

DMARCを使用すると、メールを転送すると（最終的なサーバーがそれを認識せずに）、いずれかの方法で問題が発生します。

  • envelope senderを変更しない場合、SPFチェックに合格せず、
  • 変更すると、From:アドレスと一致しなくなります。

Paypalからのサンプルメッセージは、DMRCテストに合格しています。これには、Fromヘッダーと整合する有効なDKIM署名が含まれているためです。他のドメインのエラーは標準のDMARC拒否だったため、メッセージに有効なDKIM署名がないか、Fromヘッダーと一致していないと考えられます。

唯一の回避策は、転送サーバーがSPF、DKIM、DMARCをすでにチェックしていることを信頼し、そのサーバーからのすべてのメッセージを盲目的に受け入れることです。これは、セカンダリサーバーを介して受信されるメッセージの標準のプライマリ/セカンダリMX構成で行われる方法です。また、両側で受け入れられる転送シナリオでそれを行う必要があります。

残念ながら、Gmailヘルプコミュニティでの「 DMARCをオフにしてください 」に関する議論に基づいて、GmailではDMARCテストに例外を追加することはできません。 結論：Gmailに転送しないでください。

1
Esa Jokinen

Microsoft SPFのすべての「ハードフェイル」が原因である可能性があるように思えます。受信側のシステムにSPFとDMARCの両方を強制するメカニズムがある場合、DKIMパスが原因でDMARCがそれを渡しても、SPFの「ハードフェイル」によりこのメッセージが失敗します。 SPFは独自のものであり、DMARCの前に存在していたことを覚えておいてください。しかし、それを使用する際の問題の1つは、「ソフトフェイル」と「ハードフェイル」を解釈する方法に受信システムの標準がなかったことでした。したがって、受信者は自分自身で、どちらかと言えば両方をどうするかを決定しました。 Microsoftは引き続き受信メールに対してSPFを機能させている可能性があり、「ハードフェイル」と評価されるメッセージをドロップする可能性があります。 Paypalは「ソフトフェイル」を使用しますが、これはSPFメカニズムでブロックするほど重要ではないと解釈される場合があります。どちらもDMARCによって評価される可能性がありますが、SPRCチェックは、DMARCがメッセージを通過する前にメッセージを強制終了する場合があります。

1
JoeMullarkey

ここでは実際に2つのポリシーが機能しています。 1つはMicrosoft SPFのハードフェイルポリシーであり、envelope.fromアドレスを変更しないため、GmailはSPFに基づいてアドレスを削除するだけです。

これに取り組むには、envelope.from a.k.a return-pathを書き換えることが賢明です。ただし、これにより、DMRCがSPFに基づいて渡す​​ために必要な配置が崩れます。したがって、DKIMはそのパスを取得する必要があります。

転送シナリオでは、DMARC準拠はDKIM署名が転送にどれだけうまく耐えるかに基づいているため、この状況は「DKIM Survival」と呼ばれることもあります。生き残ったフォワーダーは、フォワーダーが変更するヘッダーフィールド、または元の署名を削除するかどうか（およびオプションで独自の署名に置き換えるかどうか）に大きく依存します。

あなたのケースでは、PaypalメッセージのDKIM署名が転送を存続させます。そのメールのヘッダーの他の部分には、DKIM自体への署名、特に署名されたフィールドに関する情報があります。 Microsoftから受信するメールの種類（マーケティング、調査など）に応じて、これらは署名されたヘッダーフィールドである可能性があります。h=From:To:Subject:Date:MIME-Version:Reply-To:List-ID:Message-ID:Content-Type;メッセージの転送中にシステムがどのフィールドに触れるかを理解することが重要です。実際に署名するヘッダーを推奨するDKIMのRFCへの参照を次に示します。 https://tools.ietf.org/html/rfc4871#section-5.5

そして、ARC（Authenticated Received Chain）があります。まだドラフト段階ですが、通常、Googleなどの大規模なメールボックスホスティング会社は、これらの新しいガイダンスをすぐに実装します。 DMARCアナライザーはそれが何をするかの良い説明があります： https://www.dmarcanalyzer.com/arc-is-here/

これがお役に立てば幸いです。

0
Reinto