この記事は 2023年10月7日にGmailと米Yahooさんが投げ込んだ新たな闇要素への防衛術 の後編です。前編はこちら。
※というか私がまだ防衛術を検討＆試行中である
※この記事にはSPFやDKIMなどのメール認証に関する用語が出てきますが、それ自体の解説は含みませのであしからず。
※Gmailのガイドラインはこちら
Googleが(大量)送信者に求めていること9つを3つに分類
では、Gmailさんが求めている事項を見てみます(下記キャプチャーは2023/12/9現在)。
上から①②……と番号を振って日本語を意訳し箇条書きにするとこうです
| 項番 | 内容 |
|---|---|
| ① | SPFとDKIMつけてメールを送ってね |
| ② | 送信するIPアドレスを full-circle reverse DNS にしてね |
| ③ | 迷惑メール率を低くしてね(0.3%, 0.1%) |
| ④ | メールのフォーマットは正しく |
| ⑤ | gmailじゃないのに なんとか@gmail.com をFromにしてメールを送るな |
| ⑥ | 転送するときはARCヘッダー付けてね |
| ⑦ | p=noneでいいからDMARCレコードを発行してね |
| ⑧ | 人が送るメールではヘッダFromとEnvelope-From は同じにしてね。同じにならないならヘッダFromのドメインで署名したDKIMつけてね |
| ⑨ | オプトイン(配信許諾)が必要なマーケティング目的のメールは、ワンクリックでの登録解除ができるようにしてね |
この9項目3つに分かれます(全然違うことを順番ごちゃ混ぜに書いたのがまた闇)。 (A)メールを送るシステムのインフラストラクチャーに関することと、(B)メールを送る運用に関するもの、(C)両方に跨がるものです。
※指摘があり、TLSのこともありました。補足1.に付け足しています。
(A)メールを送るシステムのインフラストラクチャーに関するものはこの5つで
| 項番 | 内容 |
|---|---|
| ① | SPFとDKIMつけてメールを送ってね |
| ② | メール送信するIPアドレスを Forward Confirmed Reverse DNS にしてね |
| ④ | メールのフォーマットは正しく |
| ⑥ | 転送するときはARCヘッダー付けてね |
| ⑦ | p=noneでいいからDMARCレコードを発行してね |
(B)メールを送る運用に関するものはこの3つで
| 項番 | 内容 |
|---|---|
| ③ | 迷惑メール率を低くしてね(0.3%, 0.1%) |
| ⑤ | gmailじゃないのに なんとか@gmail.com をFromにしてメールを送るな |
| ⑧ | 人が送るメールではヘッダFromとEnvelope-From は同じにしてね。同じにならないならヘッダFromのドメインで署名したDKIMつけてね |
(C)両方に跨がるものはこの1つです。
| 項番 | 内容 |
|---|---|
| ⑨ | オプトイン(配信許諾)が必要なマーケティング目的のメールは、ワンクリックでの登録解除ができるようにしてね |
この9項目を上から読んで
となった方、無理もありません。だってゴッチャなんですもの……
求めに応じないとなにがあるか？
9つの詳細に入る前に、この求めに応じたときのメリット・デメリットを見ます。件のGmail案内を見ると
2024 年 2 月 1 日以降、Gmail アカウントに 1 日あたり 5,000 件を超えるメールを送信する送信者は、このセクションに示す要件を満たしている必要があります。
とありますから「えっ？ 要件 って書いてあるよ。英語版なら requirement や must ってあるよ。必ずなんじゃないの？」と思うでしょう。下にも言及があります。
この記事の要件を満たしていない場合、メールが想定どおりに配信されなかったり、迷惑メールに分類されたりする可能性があります。
例えば、「AのAPIを呼ぶための要件はBです」とあれば、Bを満たさずにAを呼んだらエラーが 必ず 返る、と捉えますよね。しかし、今回このGmailの求めを満たしていない場合は
- メールが想定どおりに配信されない（ふじた注：おそらくSMTPで一定確率4xxエラー返されて遅延したり、5xx返されて届かなかったりする） 可能性がある
- 迷惑メールに振り分けられる 可能性がある
です。SMTPでGmailにメールを送るとき 4xx, 5xx 返されたり迷惑メールに(誤)判定というのは、いままでもある事象です。なので 本質的にはそれほど変わっていません。可能性の度合いが変わる という話だと理解しています。そして、その度合いは公表されてないし誰にもわからない、と。
※なので、"要件"という表現を避けて書いています。字句通りだと誤解されるんですね。
9つの求めていることの詳解というか補足
その9つを見ていきます。(A)メールを送るシステムのインフラストラクチャーに関することと、(B)メールを送る運用に関するもの、(C)両方に関するもの のカテゴリ順です。
(A)メールを送るシステムのインフラストラクチャーに関すること
①SPFとDKIMつけてメールを送ってね
これは分かりやすいですし、前編で触れた No Auth, No Entry という標語にあった通り、最重要事項なのだと思います。
日本国内へ広くメールを送る場合、SPFは従来から必須の事項でした。これは docomo さんが2007年に実施したSPFを必須とした迷惑メール対策の施行が大きいです。
iモードメールにおける迷惑メール対策機能の拡充について＜2007年9月11日＞
SPFが日本国内で早急に普及した反動か、DKIMの日本国内の採用率は世界平均と比べて低いです。 まずメール送信時の DKIM 付与が一つ大きな対応事項としてあります。
このときDKIMの署名ドメインは、ヘッダFromのドメインにすること＝作成者署名にすることを強くおすすめします。DKIMの署名ドメインには作成者署名と第三者署名の2つの方法があります。
| 作成者署名の場合 | 値 |
|---|---|
| ヘッダFrom（受信者に見えるFrom） | nfujita@example.com |
| DKIMの署名ドメイン(d=) | example.com |
| (推測)Gmailはどこからのメールと判断するか | example.com |
| 第三者署名の場合 | 値 |
|---|---|
| ヘッダFrom（受信者に見えるFrom） | nfujita@example.com |
| DKIMの署名ドメイン(d=) | saas.example.net |
| (推測)Gmailはどこからのメールと判断するか | saas.example.net |
第三者署名はメールサービスをSaasに委託していた場合によくあります。M365も既定は テナントの数字.onmicrosoft.com というDKIMの署名ドメインを使用した第三者署名なDKIMが付与されメールが送信されます。
メールへのDKIMの付与は、それだけでは信頼性を高めるものではありません。素のSMTPでは送信者のドメインを詐称し放題であるインターネットのメールについて、詐称しようのないDKIMの署名ドメインを送信者のドメインとして使用し、ドメイン単位で評価を行うことでメールの信頼性を高める、という枠組みです。
参考）
日本国内のSPF,DKIM,DMARC採用率は2020年時点で、SPFで80%,DKIMが45%
②メール送信するIPアドレスを Forward Confirmed Reverse DNS にしてね
これは下記のことで、こうなってないといままでも問題ありました。念のため再確認というところでしょうか。
- メール送信するIPアドレスを逆引きしてホスト名が出てくること
- そのホスト名を正引きすると元のIPアドレスが出てくること
④メールのフォーマットは正しく
これは言語標準のSMTPライブラリーを使用すれば問題ないはずです(重箱の隅をつつくと色々あるけれど)。
⑥転送するときはARCヘッダー付けてね
これは対応する関係者が限られる事項です。ECサイトや旅行の予約サイトなどインターネットサービス、または、実在する企業などインターネットにメールを送るすべての組織ではなく
- ISP
- 携帯キャリア
- MBP（MailBox Provider - Gmail,Yahoo!メール,outlook,iCloud など）
- 自前でメールサーバーを運用しそのサーバーでは広くメールを転送する
といった利用者の設定に応じて、受け取ったメールを利用者のGmailアドレスへ転送するところが要対応の事項です。SPF・DKIMのメール認証結果を転送先にも伝播させるための仕組みです。
参考)
⑦p=noneでいいからDMARCレコードを発行してね
DMARCというメール認証技術があります。DMARCはメールのヘッダFromと照らし合わせてSPFまたはDKIMがpassしているかを検証します。(別の表現をすると、SPFまたはDKIMがpassしていても肝心のメールにあるFromとは関連がないのです💦）
※DMARCの詳細は検索するとたくさん出てくるので、そちらを参照ください。ここでは割愛します。
DMARCでは、ある組織(ドメイン)がメールとそのメールのDMARC による認証結果による扱い(ポリシー)を、インターネットの各メール受信サーバーに対しDNSを介して公開します。ポリシーは3つです。
- p=none (私の組織から送るメールまたDMARC対応していない、または、対応中)
- p=quarantine (私の組織から送るメールDMARC対応したから、DMARC通らないメールは受信側で隔離して)
- p=reject (私の組織から送るメールDMARC対応したから、DMARC通らないメールは受信側で拒絶して)
今回、 Gmailが求めていることは、DMARC について p=none でもいいから、なんらかのポリシーを公開してね、というものです、p=none であればDNSにこれを書けばひとまず完了 です（Gmailの求めることに対しては）。
_dmarc.example.com IN TXT "v=DMARC1; p=none"
※（指摘を反映）DMARCでは rua や ruf という属性を使い、自組織をヘッダFromとするメールが誰かに悪用されていないかなど観測することもできます。労力や予算が許すならば、そちらも実施したほうがベターです。
※大雑把＆だいぶ端折ると、ある組織が送信するメールについてすべて「①SPFとDKIMつけてメールを送ってね＆DKIMは作成者署名」が完了すると、p=quarantine, reject にでき、その組織のドメインをヘッダFromとしたフィッシングメールが宛先に届くのを遮断できる（DMARC非対応受信ドメイン除く）
(B)メールを送る運用に関するもの
③迷惑メール率を低くしてね(0.3%, 0.1%)
Postmaster Tools で報告される迷惑メール率を 0.3% 未満に維持します
と 日本語版にはありますが、これは古いので信用なりません （2023/12/9時点）。英語版のページから拾ってみます。
Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher. Learn more about spam rates.
そして、迷惑メール率の定義は Get started with Postmaster Tools によると
The spam rate is the percentage of emails marked as spam by users vs emails sent to the inbox for active users. If a substantial number of emails are delivered directly to spam folders, you may see a low spam rate even though users may still be marking your inboxed emails as spam.
とあります。総合すると
- 迷惑メール率を(通常は)0.1%未満に抑えてね
- 迷惑メール率を(高くなったとしても)0.3%以上にならないようにしてね
- 迷惑メール率は「ユーザーによって(受信トレイに届き)迷惑メールとマークされた(振り分ける行動した)メール通数÷全体」が定義だよ。
- (ある組織からのある種の)メールが既に迷惑メールに振り分けられている場合、上の定義より少ない値を迷惑メール率とするかもしれないよ
といったところでしょうか。括弧内は前後の文から意訳するために私がつけたところです。意訳をしてもなおよく分からない説明です、闇深い。
推測ゲームをしても仕方がないので、さっさと Gmail Postmaster Toolsで、送信しているメールの迷惑メール率を見た方がいいです。Gmail Postmaster Tools の迷惑メール率を見てから、0.1～0.3%に近い場合、対応を開始することになると思います。この対応が難しいですよね、おそらく初手は⑨ワンクリックでの登録解除の導入とメール送信頻度の見直しだと思います。
しかし、この迷惑メール率を Gmail Postmaster Tools で見るためには、DKIMが作成者署名でついている必要があります。 （正しくは第三者署名であれば、その送信元の組織のメールではなく、DKIMの署名ドメイン(例：SaaSベンダーのようなのドメイン)で集計される）
9つある項目でぱっと見は関連ない①と③が、実はつながっている。ここはテストにでます。 どんなテストだ。
⑤gmailじゃないのに なんとか@gmail.com をFromにしてメールを送るな
私はこれを見たとき「何を当たり前のことを言っているんだ？犯罪者でもない限り、誰がそんな馬鹿なことをするんだ？」と思いました。ご丁寧にこうも書いてあります(英語版も同じことが書いてある)。
Gmail の From: ヘッダーのなりすましをした場合、メール配信に影響する可能性があります。
知ってる。そんなこと知ってる……というところです。今回のガイドラインは英語版を元に各国版に訳されているので、ガイドラインに書かれるということは、どこかの国にそういう"馬鹿なこと"をする人達がいるのでしょう。(予想はアメリカ)
⑧人が送るメールではヘッダFromとEnvelope-From は同じにしてね。同じにならないならヘッダFromのドメインで署名したDKIMつけてね
これもわかりにくい。原文を見るとこうあります（意訳すると上になる）。
For direct mail, the domain in the sender's From: header must be aligned with either the SPF domain or the DKIM domain. This is required to pass DMARC alignment.
"direct mail"はどうも人がMUAを介して1通1通誰かに送るメールを指しているようです(MUA＝PCのOutlook、iPhoneの標準メールアプリ、AndroidのGmailアプリ、様々なWEBメールなど)。
MUAから送る際は、ヘッダFromとEnvelope-Fromは通例同じ(宛先不明ならヘッダFromのメアドにbounceメールが届く)なので、なにか変わった構成を取るメールでなければ気にしなくていいと思います。
(C)両方に関するもの
⑨オプトイン(配信許諾)が必要なマーケティング目的のメールは、ワンクリックでの登録解除ができるようにしてね
あぁぁ、メールを送信する側(というか送らない組織なんてないのだけれど)からすると、説明も実施も段違いで大変なものがこれです。 (なので、実施コストを考えたときここまで踏みきるか懐疑的な考えを私は持っています)
こうあります。日英とも同じことが書いてあります。
マーケティング目的のメールと配信登録されたメールは、ワンクリックでの登録解除に対応し、メッセージ本文に登録解除のリンクをわかりやすく表示する必要があります。
Marketing messages and subscribed messages must support one-click unsubscribe, and include a clearly visible unsubscribe link in the message body.
そして 詳細・Learn more の先には
ワンクリックでの登録解除を設定するには、送信メールに次の両方のヘッダーを含めます。
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: https://solarmora.com/unsubscribe/example
To set up one-click unsubscribe, include both of these headers in outgoing messages:
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: https://solarmora.com/unsubscribe/example
とあります。 この組み合わせ解釈が2つあると思っています。
List-Unsubscribeヘッダー＋List-Unsubscribe-Postヘッダー を使用したワンクリックでの登録解除に対応してね、ということと思います。
「ワンクリックでの登録解除に対応してね。ワンクリックでの登録解除はList-Unsubscribeヘッダーを使用するとできるよ(他の方法でもよいが)」と読めなくもないけれど強引な解釈だから避けておきましょう。
離れた2つのページを続けて読んだもの。2.は"ワンクリックでの登録解除" の実行に重きを置いた読み方です。
この「ワンクリックでの登録解除」「List-Unsubscribeヘッダーの付与」を行うかどうかは後述の「すごく頭痛い one-click unsubscribe」で触れます。まずは「List-Unsubscribeヘッダーを使用したワンクリックでの登録解除」を説明します。
List-Unsubscribeヘッダー は RFC 2369, RFC 8058 で定められた従来からあるメール配信停止の仕様です。このヘッダーがあるメールをGmailで受け取ると、こんな「メーリングリストの登録解除」リンクが送信者の右に表示されます。
登録解除をクリックすると（手元にあったHPさんの例です。特にHPさんは利害関係者でもなければ、恨みもありません、あしからず）、このような表示がされます。
でGmailの利用者が登録解除を押すと、利用者ではなく Gmail のサーバーが List-Unsubscribe ヘッダにあるURLへHTTPSでPOSTを行います。このPOSTを受けて、メールを送った組織は「この利用者が配信停止(オプトアウト)を求めたので、配信停止しよ」と対応して、配信停止が実現されます。
このため、メールを送る際に、List-Unsubscribeヘッダー は個々人を特定できるパラメーターを含んだメールとして送信する必要があります。
（フィッシングに気を付けようよ言われてる昨今、そんな1306115.xt.localとか意味不明なこと書いてあるボタンなんて押さないでしょ、このI/Fでいいのかよ？ってのは後段で出てきます……。ちなみにある外資のメール配信システム、全部 ***.xt.local です。）
Googleの求めと実際に開きがあるもの＠日本国内 ≒ 要対応箇所
Gmailへ1日5,000通メールを送る組織において、通例、気を付ける必要が無い④⑤⑥⑧を除いた
| 項番 | カテゴリ | 内容 |
|---|---|---|
| ① | インフラストラクチャー | SPFとDKIMつけてメールを送ってね |
| ② | インフラストラクチャー | 送信するIPアドレスを full-circle reverse DNS にしてね |
| ⑦ | インフラストラクチャー | p=noneでいいからDMARCレコードを発行してね |
| ⑨ | 運用 | オプトイン(配信許諾)が必要なマーケティング目的のメールは、ワンクリックでの登録解除ができるようにしてね |
| ③ | インフラ・運用両方 | 迷惑メール率を低くしてね(0.3%, 0.1%) |
が、日本国内で、Googleの求めと実際に開きがあり要対応箇所 と言えそうです。比較的容易な②⑦を削ると
- ①のDKIM付与を作成者署名で行って
- ③の迷惑メール率を取得し
- (③が高かったら)⑨のワンクリックでの登録解除で迷惑メール率低下させる（少なくとも一つの手段ではある）
とキレイにつながります。（ISPさんや携帯キャリアの中の人は⑥のARCが大変そうです）
すごく頭痛い one-click unsubscribe
で、話を ⑨オプトイン(配信許諾)が必要なマーケティング目的のメールは、ワンクリックでの登録解除ができるようにしてね に戻します。
昨今、オプトイン(配信許諾)が必要なマーケティング目的のメールは自社ではなくSaasのサービスで送る場合が多いです。海外のメール送信サービスでは List-Unsubscribeヘッダー に従来から対応しているものが多く、日本国内のメール送信サービスも List-Unsubscribeヘッダー に近々対応するのだと思います。
ならば、うちが使ってるSaaSのサービスが List-Unsubscribeヘッダー に対応すれば話はおしまいなんじゃないの？それで終わるでしょ、と思いきやそうは問屋が卸しません。
UIが良くない
簡単に配信停止できますよ、というものですが、登録解除押して、こんなのが出てきても押さないじゃないですか……
別のメール送信するシステムの例
List-ID というヘッダーでこのどこからかを制御できるのですが、そこまでしている例がありませんでした（どなたか良さげな実例を教えてください）。これ本当に2024/2/1までに間に合うのかね。
そして、受信者がある組織(企業・学校などなど)から複数のメールを受け取っていた場合、 配信停止で何が停止されるかも分かりません。 例えばアパレルのECサイトが
- 注文完了通知や発送通知
- ポイント期限切れなどポイント、クーポンの案内
- マークした商品の再入荷のお知らせ
- 好きなブランドの新入荷や値下げのお知らせ
- セール情報（いわゆるメルマガ）
といったメールを送っていて、ある利用者「4.好きなブランドの新入荷や値下げのお知らせ」の配信停止を押されたとき、1.を止めるのはないとして、2.～5.全部止めたらいいのか、4.を止めたらいいのか、List-Unsubscribe のURLを受けたシステムでは分かりません。
というか利用者が何を止めたいのかも分からないでしょうから、サイトで
といった画面を出して、そこで選ばせる方がずっといいと思います。このようなページへの導線に、現状ログインが必要なサイトは多いです。ここを、メールの送信から来た場合、メールのリンクのパラメーターでログインすっ飛ばせばいいはずです。
また、全メールをまとめて制御は無理としても、メールに
この「好きなブランドの新入荷や値下げのお知らせ」の配信停止はこちらから
https://(ワンクリックでの登録解除URL - このメールを送るシステムが受け持つ)その他のメールを含めた配信停止はこちらから
https://(サービスサイトに飛ばすURL)
といった案内を出す案もあります。こちらならメールの文中で必要な説明ができますし、このような配信停止は多くのシステムであるので、実施のコストもさほどではないと思います。
このページの上の方で
この組み合わせ解釈が2つあると思っています。
1. List-Unsubscribeヘッダーを使用したワンクリックでの登録解除に対応してね
1. ワンクリックでの登録解除に対応してね。ワンクリックでの登録解除はList-Unsubscribeヘッダーを使用するとできるよ(他の方法でもよいが)
と書いたのは、書いてある内容をそのまま繋げて読めば前者だけど、大意やサービス面、実施のコストを考えたら後者の方が良いからです。
このように List-Unsubscribeヘッダー で止めるのは何？案内はどうするの？ということを、組織でキチンと決める必要があります。
※ちなみに、GmailをiPhoneの標準メールアプリで読んでいる場合、このHTTPでPostするタイプの List-Unsubscribe には対応していません。
ある組織が複数のシステム使っていた場合、I/Fが面倒
あまり目立ちませんがある組織が広告目的のメールについて、複数のシステムを使っている場合も取り扱いが厄介です。上の例にあげたアパレルのECサイトをまた使うと
- 注文完了通知や発送通知
- ポイント期限切れなどポイント、クーポンの案内(A社のSaaSで送る)
- マークした商品の再入荷のお知らせ(A社のSaaSで送る)
- 好きなブランドの新入荷や値下げのお知らせ(A社のSaaSで送る)
- セール情報（いわゆるメルマガ）(B社のSaaSで送る)
といったように、メールの種類で送るシステムが違うことを仮定します。
List-Unsbscribeヘッダーを付けることができるのは、SaaSのサービスを利用する組織のシステムではなく、メールを送るSaaSのサービス側です。
「好きなブランドの新入荷や値下げのお知らせ(A社のSaaSで送る)」で List-Unsbscribeヘッダー を受けて配信停止したとき、受信者にとっては、2.～4.だけではなく5.も止めてほしい可能性があります。これを行う場合、A社のSaaS → サービスサイト本体 → B社のSaaS と、システム間の外部I/Fを増やす必要が生じます。
このように List-Unsubscribeヘッダー で止めたことをどこに連携するか、も組織でキチンと決める必要があります。
Subscribeの定義も違うので、アメリカ以外の国にあてはまらない
なぜ海外（というかアメリカ）では、List-Unsbscribeヘッダーの使用例が多いのか？これは、広告目的なメールの登録のさせ方が日本とアメリカで異なるからです。
アメリカのサイトで多いメールの登録は、このようなサイトにメールアドレス入力欄とボタンがあって、ニュースレターの登録が終わる形です（メールマガジンではなくニュースレターなんですよね）。サイトのアカウントと結びついてないです。
上のM3AAWGのサイトの例
アメリカのデパート Macy’s の例。サイトへの登録とEmailでの通知申込は別
そしてアメリカでは日本の特定電子メール法あたる CAN-SPAM Act はいまでも広告目的のメールについて「オプトインは不要だが、オプトアウトは必須」と定めています。
参考）
サイトと登録が別＆オプトアウトあればOKなので、気軽に登録(自分でだったり、サイト運営者だったり) ⇒ たくさん送る(どのメールが必要か？なんてない) ⇒ 気軽に解除 ⇒ メールがほしかったらまた登録、そういう習慣であるため、アメリカでは List-Unsbscribe ヘッダーでとにかく簡単に解除することが重要視されます。
今回のGmailの案内、英語版だけ内容が最新であることからアメリカのGoogleで策定されていると思うのですが、おそらくこういう文化・慣習を元に決めたのだろうと憶測しています（なんで2023年にもなって、オプトイン必須にしてないのはアメリカくらいです。そこを基準にルールを作らないでほしい）。
日本だと、様々なメールの送信は、サイトのサービスの一部、としているところが多いので上の枠組みと合いません。「なんでGmail上でボタンを押したら、うちの組織と受信者間のサービスに変更が起きるの？どういうこと？」という反応、ありました。
Marketing messages and subscribed messages must support one-click unsubscribe, and include a clearly visible unsubscribe link in the message body.
の subscribe に関する捉え方がそもそも違うよ……という背景も、この対応を難しくしている一因です。
プランAとプランB
そういうわけで、Gmailと(米Yahooさん)が投げ込んだ新たな闇要素への防衛術、をつらつら書いてみました。
- ⑨オプトイン(配信許諾)が必要なマーケティング目的のメールは、ワンクリックでの登録解除ができるようにしてね
を すぐに対応する(プランA) 、 様子見する いったん状況をみながら 対応をゆっくり進める (プランB) 、どちらか頭の痛いところです。まずはDKIM、DMARCといったインフラストラクチャーに関して着手し、迷惑メール率を取得してから List-Unsubscribe の実施時期を決める判断が現実的かなぁ…… と今のところ (2023/12/09 02:00 書いてて力尽きた) 、考えているところです。
補足その1：もう1つ求められてることあった(TLS)
2023年12月になってもう1つ追加されたことがありました。英語版ページに大量送信かどうかにかかわらず必要と記載されているこの項目です。
Starting February 1, 2024, all senders who send email to Gmail accounts must meet the requirements in this section.
2024年2月1日以降、Gmailアカウントにメールを送信するすべての送信者は、このセクションの要件を満たす必要があります。
という節の中に
Use a TLS connection for transmitting email. For steps to set up TLS in Google Workspace, visit Require a secure connection for email.
メールの送信には TLS 接続を使用します。Google Workspace で TLS を設定する手順については、「メールに安全な接続を使用する」を参照してください。
という求めを掲げる。Google Workspace の利用者に向けた案内なのか、インターネット全体に向けた案内なのか、 ぱっと見では分からないのが闇ですが 、インターネット全体に向けた案内なのだと思います。
求めとしては 「インターネットの民に告ぐ。2024/2/1以降にGmailにメール送るときは StartTLS で暗号化して送って」 ということです。
しかし、StartTLS なしで Gmail に送るとすでに(5年くらい前から？)
と赤い鍵が外れたマークが表示される影響もあり、観測する範囲ではすでに StartTLS が使用されたものばかりでした（上の画像はスパムから見つけた）。このタイミングで対応というのは少なそうです。RHEL7, CentOS7 以降の postfix ならインストールだけで自己証明書が作成され StartTLS なSMTPを話します。
もし、「特定少数あてにレガシーなサーバーを運用していて宛先にGmailがある」そういうケースでは、対応する必要があるかもしれません。またはそういう特定少数の送信なら宛先をGmailから別のものに変えるというのもあるかもしれません。
補足その2:Googleさんは Gmail の求める one-click unsubscribe しているか
Google さんから来る Marketing で subscribed なメールは、Gmail の求める one-click unsubscribe を使っているか。例えば、Google マップで投稿した結果をお知らせするこのメールにも「メーリングリストの登録解除」がしっかりある。
試しに押すと、あれ？ 何か違うものが表示されます （登録解除ではなく、ウェブサイトに移動）
で、このリンクをクリックすると、Googleのサイトへ飛ばされ「登録解除」がなされます。one-click unsubscribe の 問題点としてあげた「UIが良くない」が解消されているUIです。
- List-Unsubscribe ヘッダーにURLがある (RFC2369を実装した一形態)
- List-Unsubscribe-Post ヘッダーはない (RFC8058使用しない)
そういうメールを作って送ると、Gmail ではこのようになります。
Google マップで投稿した結果をお知らせするメールは Marketing なメールじゃないんだ、と Google さんは考えているのでしょうが、そんなことを言い出すと、「じゃあ Marketing で subscribed なメールってなによ？」と大戦争が始まるので、これ以上言及しません。
※私の心中はこんなところです。
なにか、ご指摘、参考情報などあれば、ぜひお寄せください。ご清聴ありがとうございました。
※そういえば、TLSのことを書きそびれた後で足そう…… → 反映しました