web-dev-qa-db-ja.com

SPFの制限が厳しすぎると、メーリングリストは「壊れ」ますか？

最近、自分のメールサーバーを構成しました（Linuxベースのpostfix + dovecotシナリオ）。これは個人的な使用のためだけです-私は大量のメールを送信したり、ホストから自動生成されたメールを送信したりすることはありません。追加のデバッグが楽しい電子メールDNSレコードをすべて構成するのに苦労しました。

@                 IN  TXT  v=spf1 +mx -all
_domainkey        IN  TXT  o=-; [email protected]
mail._domainkey   IN  TXT  v=DKIM1; h=sha256; k=rsa; s=email; p=deadbeef
_adsp._domainkey  IN  TXT  dkim=all
_dmarc            IN  TXT  adkim=s; aspf=s; fo=1; p=none; pct=100; rf=afrf; ri=86400; rua=mailto:[email protected]; ruf=mailto:[email protected]; sp=none; v=DMARC1;

ブラックリストに載っていないIPがあり、PTRが正しく構成されており、DKIM署名が完全に検証され、すべてが正しく設定されていると思いました。

しかし、今はメーリングリストに貢献できません。リストアドレスに送信すると、メッセージがブラックホールに入る場合や、authfail@アドレスにメールが届く場合、またはaggrep@に送信されるレポートに関連すると思われるエントリが表示される場合があります。

私の理論では、SPFポリシーは制限が厳しすぎます。メールマン（または他の）リストサーバーは、私のメッセージのSMTPリレーとして機能していますよね？だから私は変わった

@                 IN  TXT  v=spf1 +mx -all

に

@                 IN  TXT  v=spf1 +mx ~all

デフォルトのアクションをhardfailではなくsoftfailにします。問題は、この変更をテストする正当な理由がないので、スパムリストを回避したくないということです。他の誰かが以前にここにいて、私の理論を検証/反論することができますか？

編集1：

振り返ってみると、@ Alexに私を正直に設定してくれてありがとう、正確な評価を行うのに十分なデータを提供していません。メーリングリストに投稿しようとしたときにauthfail@アドレスで受け取った通知の例を次に示します。

This is a spf/dkim authentication-failure report for an email message received from IP 66.211.214.132 on Thu, 10 Jul 2014 20:58:52 +0800.
Below is some detail information about this message:
 1. SPF-authenticated Identifiers: archlinux.org;
 2. DKIM-authenticated Identifiers: none;
 3. DMARC Mechanism Check Result: Identifier non-aligned, DMARC mechanism check failures;

For more information please check Aggregate Reports or mail to [email protected].



Feedback-Type: auth-failure
User-Agent: NtesDmarcReporter/1.0
Version: 1
Original-Mail-From: <[email protected]>
Arrival-Date: Thu, 10 Jul 2014 20:58:52 +0800
Source-IP: 66.211.214.132
Reported-Domain: example.com
Original-Envelope-Id: w8mowEA5UUwMjr5TlWQfBA--.250S2
Authentication-Results: 126.com; dkim=fail (signature error: RSA verify failed) header.d=example.com; spf=pass [email protected]
DKIM-Domain: example.com
Delivery-Result: delivered

これはDKIM署名の失敗のように見えますが、理由はわかりません。受信サーバーは、myDKIM署名をメーリングリストサーバーのキーに対して検証しようとしていますか、またはその逆ですか？何らかの理由で、これが発生するとは思いませんでした-このリレーなどの場合、これらのタイプの障害が発生しないようにするために、このようなヘッダーを削除/変更することがあることをどこかで読んだことを覚えていますか？

編集2：

Dmarcian.comでDMARCレポート解析ツールを参照してくれた@ChristopherKarelに感謝します。エントリのライオンズシェアはフォワーダーとしてリストされています（これは理にかなっています）。 「preserv [ing] DKIM」としてリストされているサーバー（* .mailhop.org）が1つあります-動作しているRuby言語フォーラムの1つを介してメールを送信しましたが、知っています私の調査によると、彼らはmailhop.orgを使用しています。

「DKIM署名を破る（またはなりすまし署名を作成する）サーバー」というカテゴリの下に、*.archlinux.org、*.google.com、*.mailhop.org（これがここに表示される理由はわかりませんが、私が使用している別のリストでも、別の構成でそれらを使用している可能性があります）などがリストされています。私が最も活発に活動しているリストはArchと、Googleグループによってホストされているいくつかのリストなので、これは理にかなっています。合計で約400件のメッセージ-私はそれほど多くのメッセージを送信していないので、おそらく再試行をカウントしていると思います。

私は落ち込んでいます-現時点では、私の選択は次のように思われます：

  1. SPF、DKIM、DMARC、およびADSPを維持し、メーリングリストの使用をあきらめる、または
  2. このDNSセキュリティ/レポートレイヤーを削除して、通常の送信メールをGoogle、Yahoo！、Liveなどで拒否します。
securityemailsmtpspfdkim
7
Chris Tonkinson

私の設定には何の問題もないようです。何が起こっているのかというと、私のメッセージはmailmanによって正しく処理され、リストに中継されています。ただし、（何らかの理由で）メッセージを拒否する受信者がいくつかあります。私は実際に正しく構成されたSPFを持っているので、メーリングリストリレー自体からではなく、それらの宛先SMTPサーバーからの拒否メッセージが表示されます。

Archコミュニティの何人かの素晴らしい人々は、彼らが前述のMLサーバーにアクセスできたので、私がこれを追いかけるのを手伝ってくれました。

1
Chris Tonkinson

電子メールのセキュリティは最悪です。したがって、最終的には、すべてのオプションがひどいという決定に直面し、さまざまな理由でさまざまなことを破ることになるでしょう。

特にSPFに関しては、メーリングリストがヘッダーを書き換えずにメッセージを転送すると失敗します。リストはそれ自体が好きなように機能するように構成できるため、一般的な答えは適切ではありません。しかし、リストからのメッセージがリスト自体から来ているように見える場合、それはヘッダーを書き換えています。送信者からのものと思われる場合は、おそらくそうではありません。一般に、メーリングリストはSPF自体でうまく機能するはずです。一方、通常のメール転送はそうではありません。

DKIMに関しては、メッセージに変更を加えると失敗します。これはほとんどの場合、メーリングリストで発生します。したがって、DKIMは通常メーリングリストで爆撃します。ただし、メール転送は問題ありません。

それに加えて、 [〜＃〜] dmarc [〜＃〜] を実装しました。これは基本的に、DKIMとSPFを取り巻くレポートインフラストラクチャです。両方の認証手段を実装する場合に最適に機能しますが、一方だけでも正常に機能します。メッセージのドロップ要求を通信するようにDMARCを構成できますが、さらに重要なことに、成功/失敗レポートを受信するためのアドレスを指定できます。これらは、ほとんどの主要な電子メール受信者によってサポートされています。 （GMail、Hotmail、Yahoo）これにより、SPFチェックに失敗しているメッセージとその理由を把握できます。これを使用して-all vs ~all決定。

残念ながら、DMARC仕様では、SenderドメインとチェックされるSPFレコードの間の調整が必要です。あなたの場合、メーリングリストのSPFはチェックされており、合格していますが、ドメインと一致していません。だからDMARC爆弾。これが メーリングリスト管理者からの参照 同じくらい把握しています。

結論は私の冒頭の文章と同じです：Eメールセキュリティは吸います。そして、あなたのすべてのオプションも最悪です。私見、メーリングリストもひどいです、そして私たちがそれらを取り替えれば人生はより良くなるでしょう。 ;-)

7
Christopher Karel

DKIMの部分は見ていません。

SPFレコードに関しては、ほとんどの例で次のように使用されています。

v = spf1 mx -all

これはここに文書化されています： http://www.openspf.org/SPF_Record_Syntax

ただし、「+ mx」もRFC 7208に従って正しいはずです（これを指摘してくれたChrisに感謝します）。多分それは試してみる価値があります...

他に何を提案すればよいか本当にわかりません...すべてのDNSレコード（A/PTR/MX）を再確認してください。あなたはおそらくすでにそうしました。実際のドメイン名を知っていると、少なくともDNSに関連している場合は、トラブルシューティングに役立つ可能性があります。

1
Alex