2024/01/20(土)メールセキュリティ覚書
SPF
envelope from の認証技術であり、ヘッダfromなりすましは、防げない。ドメインのDNS textレコード に メールサーバーのFQDNまたはIPアドレスを記載する。それを受信側で検証し、envelope from の正当性を検証する。
DKIM
メールヘッダー部のDKIMヘッダーに、認証用ドメインを記載、これを認証する。DKIMヘッダーには、認証用ドメイン、秘密鍵で暗号化したメール本文のハッシュを記載。受信側は、認証用ドメインのrextから公開鍵を入手し、メール本文をハッシュと、暗号化ハッシュを公開鍵で解読したハッシュの一致を確認することで、認証用ドメインを確認する。
認証用ドメインは、ヘッダFromを記載する方法と、ヘッダFromではなくenvelope fromを記載する方法（＝第三者認証）がある。第三者認証は、メール配信サービス（ML含む）で使われる。
第三者認証が使える以上、ヘッダfromなりすましを防止できない。
https://salt.iajapan.org/wpmu/anti_spam/admin/tech/explanation/dkim/
DKIMでは、署名するヘッダーを選択できるが、通常、subjectヘッダも含まれており、subjectを変更するタイプのメーリングリストの場合、認証に失敗する。
（署名対象は、当該ヘッダー＋本文）
DMARC
Domain-based Message Authentication, Reporting and ConformanceSPF、DKIMは、envelope from と ヘッダーFromが異なることを許容するが、DMARCは、少なくとも一方において、[認証が成功し、かつ、envelope from と ヘッダーFromが一致していること]を要求する。
これにより、ヘッダーFromなりすましを防止する。
https://maildata.jp/specification/dmarc.html
転送メール、メール配信サービス、メーリングリストサービスを使う場合、SPFは、Alignmentチェックをパスしないので、DKIMにおいて、ヘッダFromを認証する方式を確保しておく必要がある。
しかし、DKIMも万能ではなく、転送、MLサービスによって、本文（可視ヘッダー含む）が改変された場合、ハッシュ一致しなくなるので、DKIMも失敗する可能性がある。特に件名を変更するタイプが要注意であろう。
その欠点を補完するために、ARCがある。
https://maildata.jp/specification/arc.html
これは転送にかかわる経路途中のサーバーにおいて、DMARC認証を行い、その結果を自身の信用情報とともに、受信サーバーにつなげる仕組みである。
Gmail のセキュリティーポリシーの変更 2024/2
https://zenn.dev/ken_yoshi/articles/gmail-new-requirements-20245000通未満と以上で対応が分かれるようだが、要確認
MLサービス参考
https://www.iij.ad.jp/biz/smx/mailboxplus.html#anc02https://www.circle.ne.jp/ml/service.html#sample
http://www.kt.rim.or.jp/~atsato/ml/mlprov.html