↓問題のURL
https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2019h31_2/2019r01a_sc_pm1_qs.pdf

【問題の要約】
メール送信側、転送側、受信側でSPFに対応している。
転送する際にEnvelope-FROMを書き換えないとSPF認証に失敗する理由を述べよ。

【解答】
送信側のDNSサーバに設定されたIPアドレスとSMTP接続元のIPアドレスが一致しないから。

【分からないところ】
解答は理解できますが、Envelope-FROMを転送サーバに書き換えたら認証に成功するということでしょうか。
しかし、それでは転送サーバーから送られてきたことは確認できても、送信元から送られてきたメールかは確認できません。
転送するごとに認証することで、結果的に送信元から送られてきたか認証できそうですが、悪意ある転送サーバーがあると機能しません。

参考書を見たり、ネットで調べたりしましたが、転送サーバーについて書かれているものが少なく理解できませんでした。

お分かりになる方がおられましたら、ぜひご教授ください。

問題番号が抜けていました。
問1 電子メールのセキュリティ対策 です。

↓問題URL
https://www.sc-siken.com/pdf/01_aki/pm1_1.pdf

この投稿は投稿者により削除されました。(2022.02.08 22:32)

この投稿は投稿者により削除されました。(2022.02.08 22:33)

>しかし、それでは転送サーバーから送られてきたことは確認できても、送信元から送られてきたメールかは確認できません。

結局メールエンベロープって封筒と一緒なのはよくある説明なんですが（左門本ではそんな書きかたしてましたね）
hserver-recipe.com/1408/
メール転送で、「迷惑メール」にならないために・・・envelope-FROM 書き換え
の
転送時の心配
と
Envelope fromとは
を読んでほしいのですが
header-senderとenvelope-senderで分かれているように、
実際の送信元から送られてきたメールかどうかは封筒の中身を見て判断するわけです。
>悪意ある転送サーバーがあると機能しません。
送信元IPとかの偽装ですかね？どういうベクトルの悪意かはいろいろあるとは思いますが、そしたら、uRPF（Unicast Reverse Path Forwarding）とか組み合わせたりとかするとは思いますけども。


送信元メールサーバ（203.0.113.25）→受信先メールサーバ（x.y.0.1）
SMTP通信
↓
MAIL FROMコマンド
user@《example.jp》
受信先メールサーバ→DNSサーバ
example.jpのtxtレコードは？
"v=spf/ip4:203.0.113.0/24 -all"

で
送信元メールサーバのIPアドレスとtxtレコードから引いたIPアドレスを照合して合っていたらSMTP通信

回答ありがとうございます。

>悪意ある転送サーバーがあると機能しません。

受信側が転送側にSPF認証して、転送側が送信側にSPF認証して、というふうに芋づる式に認証していき、結局送信側と受信側でSPF認証できているよね、ということだと認識しています。

もしそうなら、転送側が偽のメールを作成して、SPF認証に成功したと嘘をついて、受信側に送信したら危ないのではないかと考えました。

恐らくここが私の勘違いポイントで、実際は転送サーバーは信用できるのだと思います。

よく分からない転送サーバーが勝手に送信者と受信者の間に立って中継すると危ないのではないかと考えていましたが、ユーザーまたは送信者が信頼しているサーバーを使うのではないかと思いいたりました。

「信頼できる中継サーバーを介して芋づる式にSPF認証する」というという認識で正しいでしょうか。

まあ、ふつうは送信者が信頼している（用意したかどこかのサービスか）サーバを使うでしょうね。
信頼できる中継サーバを介して芋づる式にSPF認証する、でとりあえず前提条件はいいとは思ってます。例外を考えるとキリがない話ではあるので

メール送信をするとき、送信側は受信者のドメインのDNSサーバのMXレコードを参照して、
相手が指定するメールサーバに直送しますよね。
直送しているので、普通は転送されません。
受信者側の都合で、別ドメインに転送すること自体が例外です。
→転送サーバーについて書かれている情報が少ない理由ではないでしょうか？
※送信側ドメイン内や受信側ドメイン内での転送は、そもそもSPF認証をしないです。

メールマガジンなどでは、送信者側の都合で転送サーバを利用する場合があります。
その場合は、送信側DNSに転送サーバのIPアドレスを登録しておくことで、SPF認証は成功します。
ただし、業者の（クラウド上の）メールサーバを中継することになることからか、
大量のIPアドレスが登録されている場合もあります。

No.5について
>エンベロープって封筒と一緒なのはよくある説明
エンベロープを和訳すると封筒だから、そうなりますよね。

>"v=spf/ip4:203.0.113.0/24 -all"
v= はバージョン情報です。
v=spf1 とバージョン番号を書かないとパラメータエラーになります。
そして区切り文字は / ではなく、空白です。
"v=spf1 +ip4:203.0.113.0/24 -all"

>IPアドレスを照合して合っていたらSMTP通信
SPFに失敗しても受信を拒否しないのが一般的ではないでしょうか
（拒否したら再送してこないかな？）
SPFの結果は認証の成否にかかわらず、メールのヘッダ Authentication-Results: 
に追記することで、後段の処理でどうにでもできると思います。
（そのままメールボックスに配信する／迷惑メールとして配信する／削除する など）

GinSanaさん・昭和62年さん、回答ありがとうございました。

無事解決しました。

この投稿は投稿者により削除されました。(2022.02.09 16:53)

この投稿は投稿者により削除されました。(2022.02.09 16:58)

>v= はバージョン情報です。
>そして区切り文字は / ではなく、空白です。
すみません、そこらへんがいい加減でした。

>SPFに失敗しても受信を拒否しないのが一般的ではないでしょうか
私が例示したのは原理の話なので、SPFサービスの実装的にどうか？はまた別の問題ではあるのですが、いまのサービスはゆるめに作られているんですね。
それでいいのか（なんのためのSPFなのか）？とは思ったんですが、
>SPFの結果は認証の成否にかかわらず、メールのヘッダ Authentication-Results: 
>に追記することで、後段の処理でどうにでもできると思います。
>（そのままメールボックスに配信する／迷惑メールとして配信する／削除する など）
があるから、いまはそうしたほうが利便性が高いからそうしているのか、と納得しました。