On Thu, 27 Nov 2025 23:50:33 +0900 Norikatsu Shigemura <[email protected]> wrote:
> 重村法克です。 > > On 2025/11/22 21:25:42, Masachika ISHIZUKA wrote: > > すみません。同じメールへの2回目のreplyです。 > > 先程、書き忘れたのですが、上記のメールですが、 > > Received: from mx2.freebsd.org (mx2.freebsd.org [96.47.72.81]) > > by peach.ish.org (8.18.1/8.18.1) with ESMTPS id 5AM4DCZC076545 > > (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL) > > for <[email protected]>; Sat, 22 Nov 2025 13:13:14 +0900 (JST) > > (envelope-from [email protected]) > > Authentication-Results: peach.ish.org; > > dmarc=fail (p=none dis=none) header.from=ninth-nine.com > > Authentication-Results: peach.ish.org; > > spf=pass smtp.mailfrom=FreeBSD.org > > Authentication-Results: peach.ish.org; > > dkim=pass (2048-bit key; > > unprotected) header.d=freebsd.org [email protected] > > header.b=vo5SeNI6; > > dkim=permerror (0-bit key) header.d=ninth-nine.com > > [email protected] header.b=KGZoeKzv; > > dkim=temperror (0-bit key; > > unprotected) header.d=ninth-nine.com [email protected] > > header.b=DQd5crrU > > とdmarcがfailしてしまいます。spfとdkimは正常にpassしています。(dkimの > > 2個目、3個目のエラーはもちろん気にする必要はありません。) > > 自分がfreebsd-user-jpへ送ったものやその他のMLもdmarc=passなのでこち > > らのサーバの設定は大丈夫なんだろうと思っていたのですが、何か設定をミス > > っているのか不安になりました。 > > 何かお気づきの点があればご教示戴けると幸いです。 > > エラーメッセージとか、この手のヘッダーの解析をＡＩに説明させると参考になるので今度試してみてください。 > 二つ以上で確認するのが吉です（回答が不安定の時があるので）。今はジェミニが安定的かな。 > > > Authentication-Results: peach.ish.org; > > peach.ish.org がこの認証結果を生成しています。 > ご自身のメールがＭＬを経由して戻ってきたケースで失敗しているのは以下の理由からです。 > > > dkim=pass (2048-bit key; unprotected) header.d=freebsd.org > > [email protected] header.b=vo5SeNI6; > > ＭＬサーバー（FreeBSD.org）自身が付与したＤＫＩＭ署名は正常にパスしています。ＭＬが正当な中継者であることは担保されています。 > > > dkim=permerror (0-bit key) header.d=ninth-nine.com > > [email protected] header.b=KGZoeKzv; > > dkim=temperror (0-bit key; unprotected) header.d=ninth-nine.com > > [email protected] header.b=DQd5crrU > > 送信元ドメイン（ninth-nine.com）のＤＫＩＭ署名が恒久的エラーと一時的エラーとなっているのは、 > ＭＬによってメールの件名や本文を改変したため（ＭＬの正常な動作）、元の署名が破損したことによるものです。 > 一時的エラーについては、おそらくＥＤ２５５１９署名のせいだと思います（未対応が多いので）。。 > いずれにせよＭＬ経由で署名が壊れた結果を意味する程度の話なので、それ自体は無視して問題ありません。 > > > dmarc=fail (p=none dis=none) header.from=ninth-nine.com > > そのため、石塚さんのサーバー「では」、元の署名が破損かつＳＰＦ認証のアライメントも不一致 > （header.from と smtp.mailfrom の内容が不一致）となったため、ＤＭＡＲＣは失敗と判定されました。 > > これが懸念なのはその通りで、ＭＬ経由のメールを、あるいは転送されたメールが、ＤＭＡＲＣ成功と判断させる仕組みがＡＲＣとなります。 > > 例えばこの（石塚さんが送った）メールのヘッダーの結果は、自分の所では下記の通りとなります。 > > > Authentication-Results: dummy; > > arc=pass (ams.1.freebsd.org=pass, as.1.freebsd.org=pass) > > smtp.remote-ip=96.47.72.81; > > dkim=pass (1024-bit rsa key sha256) header.d=ish.org [email protected] > > header.b=ISyh3tQw header.a=rsa-sha256 > > header.s=54d26185-a057-8857-582c-09c040ed7013; > > dkim=pass (2048-bit rsa key sha256) header.d=freebsd.org > > [email protected] header.b=TXsGg0Mt header.a=rsa-sha256 header.s=dkim; > > dmarc=pass policy.published-domain-policy=reject > > policy.applied-disposition=none policy.evaluated-disposition=none > > (p=reject,has-list-id=yes,d=none,d.eval=none) policy.policy-from=p > > header.from=ish.org; > > iprev=pass smtp.remote-ip=96.47.72.81 (mx2.freebsd.org); > > spf=pass > > smtp.mailfrom="[email protected]" > > smtp.helo=mx2.freebsd.org; > > x-ptr=pass smtp.helo=mx2.freebsd.org policy.ptr=mx2.freebsd.org; > > x-return-mx=pass header.domain=ish.org policy.is_org=yes (MX Records > > found: mail4.ish.org,mail.ish.org,mail6.ish.org); > > x-return-mx=pass smtp.domain=freebsd.org policy.is_org=yes (MX Records > > found: mx1.freebsd.org,mx66.freebsd.org) > > ＭＬ側で受けた時のＤＫＩＭ情報（この場合石塚さんのサーバーからのメール）をＭＬ側でＡＲＣ署名して保存します。 > 自分のメールサーバーではＭＬが付与したＡＲＣ署名を検証し、ＤＭＡＲＣの結果を pass に「救済」しています。 > > ＡＲＣ情報（署名）についてはＭＬにて付与されていますので、石塚さんのサーバーでもＡＲＣの検証機能を実装することで、このＤＭＡＲＣ失敗の問題を解消できます。 > この辺りの対応は p5-Mail-Milter-Authentication を導入、ＡＲＣ検証するのが確実です。 > > 現在の石塚さんのサーバーがＤＭＡＲＣ失敗を元に何らかの処理（破棄や迷惑メール判定など）を行っていなければ、運用上の問題はありません。 > ただしメールを転送すると、メール転送を受け入れてくれる相手メールサーバーが、今後どんどん少なくなっていく可能性はあります。 > そこまで考慮すると石塚さんのメールサーバーでＡＲＣ署名まで設定頑張る価値はあります。 > > 以上よろしくお願いいたします。 > > -- > Norikatsu Shigemura <[email protected]> 青木@名古屋です。 この手の話で毎度思うのですが、検証の必要なものは全部きちんと頭だけ 追加でなく完全な入れ子の構造になっていれば発生しないのに。 対象ファイル（この場合メール）内で完全にユニークなデリミタを検証 して欲しい対象の前後に追加して、そのデリミタの間を検証するための 情報が頭かお尻に付いている形で規格化していれば。 多重化検証したい場合、一番外側を検証して、その中身を検証して、 という形なら、個々の階層の中身は不変ですから。 -- 青木 知明 [Tomoaki AOKI] <[email protected]>
