Skip to content

Commit b982a6c

Browse files
ma91nma91n
authored
メール設計ガイドライン: RFC追加 (#251)
* メール設計ガイドライン: RFC追加 * fix dead link
1 parent c1e018d commit b982a6c

File tree

1 file changed

+23
-14
lines changed

1 file changed

+23
-14
lines changed

‎documents/forMail/mail_guidelines.md‎

Lines changed: 23 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -51,7 +51,7 @@ head:
5151

5252
## SPF（Sender Policy Framework）
5353

54-
SPF（エスピーエフ）は、現在RFC 7208で標準化されている仕様で、ドメイン所有者がそのドメインを用いてメールを送信できる送信者(Sender)を限定する(Policy)ための仕組み(Framework)である。
54+
SPF（エスピーエフ）は、現在[RFC 7208](https://tex2e.github.io/rfc-translater/html/rfc7208.html)で標準化されている仕様で、ドメイン所有者がそのドメインを用いてメールを送信できる送信者(Sender)を限定する(Policy)ための仕組み(Framework)である。
5555

5656
具体的には、DNSに送信者として許可するホストのIPアドレスをSPFレコードとして記録しておく。受信者はメールに記載されているドメインを用いてDNSにSPFレコードを問い合わせ、送信元IPアドレスと照合することで、受信したメールがSPFに準拠したものであるかを判定できる。
5757

@@ -108,7 +108,7 @@ SPFレコードは複数の要素（ディレクティブと修飾子）から
108108

109109
## DKIM（DomainKeys Identified Mail）
110110

111-
DKIM(ディーキム)は、RFC 6376により定められた仕様で、ドメインに紐づけられた鍵(DomainKeys)を用いて、メール(Mail)の内容と送信者が正当であると証明する(Identified)。公開鍵暗号を用いた認証仕様で、まずDNSに公開鍵を登録しておく。その上で送信者はメール送信時にメールの内容から電子署名を作成し、メールヘッダに含める。受信者はDNSから公開鍵を取得し、電子署名を検証することで、内容と送信者の正当性を確認できる(検証に失敗した場合、なりすまし、あるいは受信経路での内容の改ざんが考えられる)。
111+
DKIM(ディーキム)は、[RFC 6376](https://tex2e.github.io/rfc-translater/html/rfc6376.html)により定められた仕様で、ドメインに紐づけられた鍵(DomainKeys)を用いて、メール(Mail)の内容と送信者が正当であると証明する(Identified)。公開鍵暗号を用いた認証仕様で、まずDNSに公開鍵を登録しておく。その上で送信者はメール送信時にメールの内容から電子署名を作成し、メールヘッダに含める。受信者はDNSから公開鍵を取得し、電子署名を検証することで、内容と送信者の正当性を確認できる(検証に失敗した場合、なりすまし、あるいは受信経路での内容の改ざんが考えられる)。
112112

113113
```mermaid
114114
graph TB
@@ -165,7 +165,7 @@ DKIMレコードは複数のタグと値の組み合わせで構成される。
165165

166166
## DMARC（Domain-based Message Authentication, Reporting, and Conformance）
167167

168-
DMARC(ディーマーク)は、RFC 7489により定められた仕様で、ドメイン認証（Domain-based Message Authentication）の結果を用いて、送信者への認証結果の報告（Reporting）と、受信者へのメールの取り扱いへの準拠（Conformance）を要求する。DMARCはSPFおよびDKIMを前提とした仕組みであり、「SPFおよびSPFアライメント」あるいは「DKIMおよびDKIMアライメント」のいずれかを通過しなかったメールの取り扱い（受信拒否・隔離・受信）をメール送信者が指定できる。
168+
DMARC(ディーマーク)は、[RFC 7489](https://tex2e.github.io/rfc-translater/html/rfc7489.html)により定められた仕様で、ドメイン認証（Domain-based Message Authentication）の結果を用いて、送信者への認証結果の報告（Reporting）と、受信者へのメールの取り扱いへの準拠（Conformance）を要求する。DMARCはSPFおよびDKIMを前提とした仕組みであり、「SPFおよびSPFアライメント」あるいは「DKIMおよびDKIMアライメント」のいずれかを通過しなかったメールの取り扱い（受信拒否・隔離・受信）をメール送信者が指定できる。
169169

170170
SPF/DKIMアライメントとは、各認証に用いたドメインが、ヘッダFROM（主に受信者に表示されるメールアドレス）のドメインと一致しているかの検証を指す。SPFやDKIMは各ドメインが送信者によって管理されていることを保証する仕組みではあるが、ヘッダFROMとは異なるドメインで認証を行っている場合、SPF/DKIMに通過していたとしても、メール送信者の正当性（ヘッダFROMのドメイン管理者であるか）は全く担保されない。そのような状況を検知するため、ヘッダFROMのドメインと認証に用いられたドメインが一致していることの検証がSPF/DKIMアライメントである。SPF/DKIMアライメントを総称してDMARCアライメントと呼ぶ。
171171

@@ -377,13 +377,15 @@ DKIMに関連するヘッダは、`DKIM-Signature`である。複数のタグに
377377
| 2 | 正引きおよび逆引きDNSレコードを登録する | 必要 | 必要 |
378378
| 3 | メール送信にTLS接続を使用する | 必要 | 必要 |
379379
| 4 | 迷惑メール率を最大でも0.30％未満、可能な限り0.10％未満に維持する | 必要 | 必要 |
380-
| 5 | Internet Message Format 標準（RFC 5322）に準拠したメール形式とする | 必要 | 必要 |
380+
| 5 | Internet Message Format 標準（[RFC 5322][RFC5322]）に準拠したメール形式とする | 必要 | 必要 |
381381
| 6 | ヘッダFromのGmailへのなりすましを行わない | 必要 | 必要 |
382382
| 7 | （メール転送サーバやメーリングリストなど、定期的な転送がある場合）ARCヘッダ・List-idヘッダを設定する | 必要 | 必要 |
383383
| 8 | DMARCによる認証を設定する | 不要 | 必要 |
384384
| 9 | DMARCアライメントに合格する | 不要 | 必要 |
385385
| 10 | マーケティング目的・配信登録されたメールについては、ワンクリックで配信停止が行える機能をメール内に搭載する | 不要 | 必要 |
386386

387+
[RFC5322]: https://tex2e.github.io/rfc-translater/html/rfc5322.html
388+
387389
推奨は以下の通り。
388390

389391
- 1日あたりのGmail宛のメール送信数が5,000件以上か否かにより、準拠するべき要件は異なるが、1日の送信件数に依らず、すべての要件に準拠する
@@ -407,11 +409,18 @@ DKIMに関連するヘッダは、`DKIM-Signature`である。複数のタグに
407409
::: tip List-Unsubscribeヘッダ
408410
（利用可否や詳細な挙動は受信者のクライアントアプリケーションに依存するが、少なくともGmailにおいては）`List-Unsubscribe`ヘッダを適切に設定することで、メール上部にワンクリックで配信停止が行える要素が表示される。
409411

410-
![](images/list_unsubscribe_header.png)
412+
**関連する技術仕様:**
413+
414+
- **[RFC 2369](https://tex2e.github.io/rfc-translater/html/rfc2369.html)**: メールヘッダによるリストコマンド（配信停止など）の定義
415+
- **[RFC 8058](https://tex2e.github.io/rfc-translater/html/rfc8058.html)**: ワンクリックでの配信停止機能（One-Click Unsubscribe）のシグナリング
416+
417+
![「メールをブロック」のテキストリンク](images/list_unsubscribe_header.png)
411418

412419
（SP版Gmailでの表示例）
413420

414-
`List-Unsubscribe`ヘッダには、配信停止リクエストをHTTPリクエストで受け取るためのURLか、メールで受け取るためのメールアドレスを記述する。クライアントアプリケーションに依存するが、リクエストボディやメール本文には、配信停止リクエストを行った受信者の情報は含まれないため、URLや宛先メールアドレスにパラメータとして受信者（あるいは配信停止の起因となったメール）の情報を含める必要がある。
421+
`List-Unsubscribe`ヘッダには、配信停止リクエストをHTTPリクエストで受け取るためのURLか、メールで受け取るためのメールアドレスを記述する。特にGmailの要件（RFC 8058準拠）を満たすには、`List-Unsubscribe-Post: List-Unsubscribe=One-Click` ヘッダの付与が必要となる。
422+
423+
クライアントアプリケーションに依存するが、リクエストボディやメール本文には、配信停止リクエストを行った受信者の情報は含まれないため、URLや宛先メールアドレスにパラメータとして受信者（あるいは配信停止の起因となったメール）の情報を含める必要がある。
415424

416425
また、受信者による配信停止リクエストから2日以内に、配信停止処理を完了させることが推奨されている。WEBCASなどのメール配信用サービスを利用している場合、`List-Unsubscribe`ヘッダの付与と、配信停止の仕組みが機能として用意されているケースがある。利用するサービスが対応している場合、当該機能の利用を推奨する（参考：[List-Unsubscribeヘッダ付与機能 | メール配信システムWEBCAS e-mail](https://www.webcas.jp/email/feature/list-unsubscribe/)）
417426

@@ -1143,7 +1152,7 @@ erDiagram
11431152
メールの形式は、歴史的背景から主に3つの種類が存在する。
11441153

11451154
1. **プレーンテキストメール**
1146-
1. RFC 822などで定義された、文字情報のみで構成される形式で、文字の装飾や画像の挿入が不可
1155+
1. RFC 822（現[RFC 5322][RFC5322]）などで定義された、文字情報のみで構成される形式で、文字の装飾や画像の挿入が不可
11471156
2. 視覚的な訴求力は低いが、あらゆる環境で表示できる強みがある
11481157
2. **リッチテキストメール**
11491158
1. Microsoft社のOutlookなどが独自に採用していた形式
@@ -1273,7 +1282,7 @@ HTMLメールは豊かな表現力を持ちエンゲージメントを高める
12731282

12741283
## TO、CC、BCCの使い分け
12751284

1276-
メールの宛先には、RFC 5322で定められた3つのフィールドが定義されている。
1285+
メールの宛先には、[RFC 5322][RFC5322]で定められた3つのフィールドが定義されている。
12771286

12781287
1. **TO (宛先)**: メールの主な届け先を示す
12791288
2. **CC (カーボンコピー)**: 参考として内容を共有しておきたい関係者を指定する。TO、CCに入れられた全員が、CCに誰のアドレスが設定されているかを参照可能
@@ -1306,28 +1315,28 @@ HTMLメールは豊かな表現力を持ちエンゲージメントを高める
13061315
- どちらにしても、電子帳簿保存法の保存要件は守ること
13071316

13081317
::: tip CC的な用途はグループアドレスの利用がおすすめ
1309-
システムの管理者など、常に決まった複数人へ通知を送る必要がある場合は、CCに個人のアドレスを並べるのではなく、admins@example.com のようなグループアドレスを作成し、1つの「TO」に設定する。メンバーの変更もグループアドレス側で吸収でき、運用の柔軟性も高まる。
1318+
システムの管理者など、常に決まった複数人へ通知を送る必要がある場合は、CCに個人のアドレスを並べるのではなく、`admins@example.com` のようなグループアドレスを作成し、1つの「TO」に設定する。メンバーの変更もグループアドレス側で吸収でき、運用の柔軟性も高まる。
13101319
:::
13111320

13121321
::: info 参考
13131322
[電子帳簿保存法が改正されました](https://www.nta.go.jp/law/joho-zeikaishaku/sonota/jirei/pdf/0021012-095_03.pdf) に保存要件が記載されている。
1314-
![](images/保存要件.png)
1323+
![電子取引の保存要件 | 真実性の要件と可視性の要件](images/保存要件.png)
13151324
:::
13161325

13171326
## 送信元メールアドレス
13181327

1319-
メールの送り主を示す、送信元（From）アドレスはRFC 5322上、自由に設定できる。
1328+
メールの送り主を示す、送信元（From）アドレスは[RFC 5322][RFC5322]上、自由に設定できる。
13201329

13211330
### 表示名
13221331

13231332
表示名とは、メールクライアントの受信トレイで、送信元メールアドレスの前に表示される分かりやすい名前のことである。この形式はRFC 5322で定められており、「誰から」のメールかを一目で識別できるようにすることで、ユーザー体験を向上させることができる。
13241333

1325-
- 例: 利用サービス名からのお知らせ \<info@example.co.jp\>
1334+
- 例: 利用サービス名からのお知らせ <<info@example.co.jp>>
13261335

13271336
| \# | 案1：サービス名のみ | 案2：サービス名＋送信目的 |
13281337
| :----------- | :--------------------------------------------------- | :--------------------------------------------- |
13291338
| 説明 | 最もシンプルで、誰からのメールかを伝える基本的な形式 | 誰が、何の目的で送っているのかを明確にする形式 |
1330-
| 例 | \`Future Corporation\` | \`Future Corporation サポート\` |
1339+
| 例 | `Future Corporation` | `Future Corporation サポート` |
13311340
| 分かりやすさ | ✅誰からかは分かるが、目的は不明 | ✅️誰が何の目的で送ったか一目で分かる |
13321341
| 信頼性 | ✅普通 | ✅️具体的な部署名などから安心感が得られる |
13331342

@@ -1831,7 +1840,7 @@ SMSとメールは、下表のように特性が異なるため、要件に応
18311840
しかし、電話番号は利用目的の合意ができていることを前提に収集が可能であり、目的変更には再同意が必要である。そのため、安易に電話番号で名寄せを行うと規約違反の可能性がある。また、同一人物が複数番号を持つ場合や、または電話番号を家族で共有している場合も考えられ、誤った名寄せになる懸念もある。そのため、ユーザーの連携率に依存するが、Google、Apple IDなどソーシャルログインで名寄せなどの案がベターである。
18321841
:::
18331842

1834-
## 有効性
1843+
## 電話番号の有効性
18351844

18361845
ユーザーが入力した電話番号が、実際に使われている有効なものかを確認することで、SMS到達率の向上や、余計なコスト削減、不正利用の抑制などに繋げることができる。大分類として、以下の3つが存在する。
18371846

0 commit comments

Comments
 (0)