web-dev-qa-db-ja.com

カスタムリターンパスはSPFを冗長にすることができますか

私の理解では、SPFを使用して、ドメインに代わって送信メールを送信することが許可されているIPアドレスのセットを定義できます。許可されたIPアドレスのセットに含まれていないメールサーバーが電子メールを送信する場合、受信サーバーはfromドメインでTXTレコードルックアップを実行し、レコードを検査して、それが受信メールをソフトフェイルまたはハードフェイルする必要があります。

例えば。

Dig my-site.com TXT
"v=spf1 include:_spf.google.com include:servers.mcsv.net -all"

このレコードは基本的に「TXTレコードで示されるサーバーは許可し、それ以外は失敗します。

次に、これに遭遇しました： https://www.intercom.com/help/configure-intercom-for-your-product-or-site/configure-intercom-for-your-team/a-guide- to-sending-email-from-your-own-address

SPFは必要ですか？いいえ、インターコムが処理します。インターコムから送信されるメールには、return-pathヘッダーが含まれています。受信者のメールサーバーが私たちの電子メールの1つを受信し、リターンパスでドメインのSPFレコードを確認すると、送信者のIPアドレスが承認された送信者であることがわかります。つまり、インターコム経由で送信されたメールは自動的に認証を通過し、自分でレコードを設定する必要はありません。

これは私を混乱させます。これは、この場合のインターホン（同じ手法を使用しているインターネット上の誰もが）がmy-site.com私がホワイトリストに登録したIPアドレスのセットにないものを失敗させるはずのSPFレコードを使用したという事実にもかかわらず、電子メールを受け取った人は、これが「から」であることを認識しないでしょう[email protected] AND SPFパスとして、送信サーバーのIPアドレスが許可されたIPアドレスの1つではなかったとしても？

なお、私はDKIMとDMARCも使用していますが、この議論をSPF側だけに限定したいと思います。

emailemail-spoofingspf
2
David

私たちが電子メールに関して「から」について話しているとき、それは2つのことを指すことができます：

  1. "From："ヘッダー
  2. 接続を確立するときに電子メールサーバー間で直接交換される「エンベロープFrom」。
  3. それらは同じである必要はありません。

クライアントがサーバーに接続してメールを送信する場合、クライアント間の簡単なやり取りは次のとおりです。

client: HELO client.example.com
server: Hello, client.example.com, Nice to meet you
client: MAIL FROM: <[email protected]>
server: Okay
client: RCPT TO: <[email protected]>
server: Okay, go ahead with the message, terminate with a single '.'
client:
From: Junie B. Jones <[email protected]>
Subject: Important discussion

Hello, Claire...
...blah...
...blah...
.
server: Okay, accepted for delivery

上記では、「From」が2回表示されていることがわかります。1回目はMAIL FROMの一部として、2回目はFrom:としてメッセージの本文に表示されます。メールサーバーに関する限り、重要なのは最初の1つ（ "Envelope From"または "Return Path"と呼ばれます）だけです。2つ目は主に外観用です。実際、完全に欠落している可能性があります。

インターコムが言っていることは、彼らがメッセージを送るとき、彼らはこのようにそれを送るということです：

client: HELO foo.intercom.com
server: Hello, foo.intercom.com, Nice to meet you
client: MAIL FROM: <[email protected]> # <-- envelope-from
server: OK
client: RCPT TO: <[email protected]>
server: OK, proceed, terminate with a single "."
client: 
From: Junie B. Jones <[email protected]> # <-- cosmetic "From:"
Subject: Mailing from intercom

...blah...
...blah...
.
server: OK, accepted for delivery

多くのメールクライアントでは、メールを表示するときに、「Junie B. Jones <[email protected]> via foo.intercom.com」と表示されます。 Envelope-FromとコスメティックFromの間の不一致を示しますが、電子メールに関してはコーシャの慣習と見なされます。

SPFは特にEnvelope-Fromのみを処理し、表面的な "From："フィールドを無視します。

3
mricon

Return-Pathヘッダーは、SMTP（ RFC 5321 ）で発行されたmail fromコマンドを表し、「エンベロープ送信者」とも呼ばれます。 Sender Policy Framework は、SMTP情報のみをチェックします。SMTPEHLOまたはHELOコマンドで識別されるホストとエンベロープ送信者。

SMTP情報に直接アクセスできないシステムによって実行されるSPFは、Return-Pathヘッダーからエンベロープ送信者を抽出し、適切なReceivedヘッダーからHELOホストを抽出する必要があります（または、信頼します Received-SPF ヘッダー）。

エンベロープ送信者は、インターコムでの認証に使用するアカウントを表していると思います。つまり、IntercomのSPFを渡しますが、「調整」されません"for [〜＃〜] dmarc [〜＃〜] はFromヘッダーのドメインと一致しないため。

これは、インターコムのアウトバウンドサーバーを祝福する独自のSPFレコードが必要であることを意味します（必ずしもレコード全体ではありません。マーケティング担当者もyourマーケティング担当者）。上記のレコードで十分です。 ruaキーを使用してDMARCレコードを設定し、集計レポートを専用のメールボックスに送信すると、ドメインを使用するすべてのものが（長期間にわたって）Fromヘッダーに表示されます。ドメインに合わせたSPFまたはDKIMを渡す。

1
Adam Katz