正しいメールを送るためのRFC復習〜スパマーと間違われないために〜
Vade Japan株式会社

関根 章弘

⾃⼰紹介
関根 章弘
• 1995年頃 インターネット接続ブーム時に構築⽀援を⾏う
要件を満たすために必要に迫られてsendmail.cfをカスタマイズ• 2000年頃 商⽤サービス向けの⼤規模メールシステムの構築に関わる• 海外のメール製品ベンダに所属し⽇本のサービスに導⼊• 2003年 迷惑メール対策カンファレンスの運営に携わる• 2019年 Vade Japanに⼊社、顧客サポートを担当

2

⾃⼰会社紹介• Vade Japan株式会社（本社はフランス共和国 リール）
• AIエンジンを⽤いた予測的メール防衛の世界的リーダー• 全世界で14億を超えるメールボックスを保護• ⽇本国内にメール脅威の分析を⾏う技術チームを保有
本社オフィス外観

3セッションの⽬的
古き良き時代にデザインされたメールシステムは、多くのMTA/MUAが良きに計らってくれているために、なんとなく送っても⼤部分のメールは問題なく届けられています。しかし、その中にはルール違反でエラーになっても仕⽅がないようなものも⾒られます。
しかし、スパムやフィッシングが⼤量に送られるようになり、最近はルール違反のメールは受信しないという⽅針のシステムもあります。
そのような厳格なシステムにブロックされてないようにRFCの内容をチェックします。間違いやすい点を例⽰して、正しいメールを確認します。

4

内容
1. メールの基本構造を確認します
2. メールを構成する各パートに対応したRFCの概要を確認します• SMTP - 5321
• Message Format - 5322
• MIME - 2045, 2046, 2047, 2048, 2049

3. 実際に送信されているメールでベストプラクティス、バッドプラクティスを確認します※RFCの定義は⾮常に多岐にわたっています。このセッションでは細かな解釈には踏み込まず、基本的な項⽬を取り上げます5メールの基本構造

メール関連RFC (1)
メールの構造と対応するRFC
エンベロープ

メール本体〇〇様5322 - Internet Message FormatVade Japan
株式会社2045, 2046, 2047, 2048, 2049 ‒Multipurpose Internet Mail Extensions(MIME)
XXより

5321
Simple Mail Transfer Protocol

7メール関連RFC (1)
メールの構造と対応するRFC
エンベロープ

メール本体〇〇様5322 - Internet Message Format
Vade Japan株式会社

2045, 2046, 2047, 2048, 2049 ‒Multipurpose Internet Mail Extensions(MIME)
XXより

5321
Simple Mail Transfer Protocol

SPF

DKIM
8

RFC5321 Simple Mail Transfer Protocol• メールを転送する（送る）ための約束事• クライアントーサーバ間のコマンド/レスポンスを定義しています• 何度も更新、修正、拡張され、現在は認証、暗号化、バイナリ・データ転送、および国際化された電⼦メールアドレスのためのさまざまな拡張機能を持つ、拡張可能な構造を持っています9メール関連RFC (2)
メール本体

ヘッダー

〇〇様

5322 - Internet Message Format

本⽂（text、HTML)
2045, 2046, 2047, 2048, 2049 ‒Multipurpose Internet Mail Extensions(MIME)

XXより添付ファイル

10

RFC5322 Internet Message Format• メールの形式を定義している• ヘッダー、本⽂の構成• アドレス、⽇付などのフォーマット

• メールの形式
メール(message)はヘッダー(fields)とボディから構成されるボディに使える⽂字はCR、LFを除いたASCII⽂字

11

ヘッダー
• 必須のヘッダー• Date• From• Message-ID• 件名や宛先は無くても良い• 複数書いてはいけないヘッダーがある• Gmailは違反したメールをブロック

12

ヘッダー
• 宛先ヘッダー(To/Cc/Bcc)• ヘッダーには1つ以上のアドレスを書く(one or more addresses)• 複数のアドレスはカンマ区切りで1つのヘッダーに書く• ヘッダーは無くても良い(0~1個)
アドレスが無ければヘッダーを付けない

13

ヘッダー
• Message-ID• メッセージに固有の識別⼦• リプライ元の特定などに利⽤• フォーマットの定義はシンプル• ただし
The message identiﬁer(msg-id) itself MUST be a
globally unique identiﬁer fora message.
送信者はグローバルに⼀意な識別⼦であることを保証する必要がある→ ＠の右側にドメイン名やIPアドレスを⼊れることが推奨されている
14

RFC2045-2049 MIME
• Multipurpose Internet Mail Extensions
メールで英語(ASCII)以外のコンテンツを扱えるようにするための拡張• RFC 2045, specifies the various headers used to describe thestructure of MIME messages.
• RFC 2046, defines the general structure of the MIME media typing
system and defines an initial set of media types.
• RFC 2047, describes extensions to RFC 822 to allow non-USASCII text data in Internet mail header fields.
• RFC 2048, specifies various IANA registration procedures forMIME-related facilities.
• RFC 2049, describes MIME conformance criteria as well as
providing some illustrative examples of MIME message formats,15

RFC2045 MIME Part One• MIMEヘッダの定義• メッセージヘッダでMIMEであることを宣⾔• 例︓ MIME-Version: 1.0
Content-Type: text/plain; charset="Shift_JIS”
Content-Transfer-Encoding: base64• Content-Type: データの説明、テキストやファイル単体か、複数要素か• text, image, audio, video, application, message, multipart, 他• Content-Transfer-Encoding: エンコーディング（符号化）の種別• 7bit, 8bit, binary, quoted-printable, base64

16RFC2046 MIME Part Two• メディアタイプ• Content-Typeに指定するタイプ、サブタイプの詳細を説明• タイプ︓text, image, audio, video, application,message, multipart• 複数要素で構成される場合にはパラメータで区切り⽂字列を指定します
Content-Type: multipart/alternative; boundary="1fbcea0106f295f9d6ac352fb6584b8e4"

17

RFC2046 MIME Part Two
シンプルなmultipart構成例• パラメータで区切り⽂字列を指定します“simple boundary”• 先頭に“--”を付けて使⽤します• 終端は後ろにも“--”を付けます※複数階層の複雑な例がRFC2049 Appendix A にあります18

RFC2047 MIME Part Three• メールヘッダーで⾮ASCII⽂字を扱う⽅法• ヘッダーを変えてしまうと互換性がなくなってしまうため、ヘッダー値(Header
Field Body)を印刷可能なASCII⽂字に変換します• エンコードされたデータのフォーマットとエンコードの⽅法が定義されています• エンコードは2種類• "B" encoding - BASE64エンコーディング
データを6bitずつの64進数に分割して、数字、英字と⼀部の記号64⽂字で表します。
• ”Q“ encoding - Quoted-Printableに類似
8ビットのデータを =XX のような16進数2桁の形式で表します。7ビットの印字可能な⽂字は変換されません。

19

RFC2047 MIME Part Three• 例（RFC2047 - 8. Examples より）
From: =?US-ASCII?Q?Keith_Moore?= <moore@cs.utk.edu>
To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <keld@dkuug.dk>
CC: =?ISO-8859-1?Q?Andr=E9?= Pirard <PIRARD@vm1.ulg.ac.be>
Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?==?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=• デコード結果
From: Keith Moore
To: Keld Jørn Simonsen
Cc: André Pirard
Subject: If you can read this you understand the example.

20

RFC2047 MIME Part Three
⽇本語への適⽤例
Subject: サンプルx• Bエンコーディング
Subject: =?UTF-8?B?44K144Oz44OX44OrCg==?=• Qエンコーディング
Subject: =?UTF-8?Q?=E3=82=B5=E3=83=B3=E3=83=97=E3=83=AB?=※⽇本語にはBエンコーディングが効率的なため、⼀般的に利⽤されています。
21

サンプル
バッドプラクティス

必須ヘッダがない• Dateがない• Date:とMessage-ID:は忘れずに

23

ヘッダーのフォーマット不正
メッセージIDがユニークでない• @以降がプライベートIP
Message-ID: <14893673.102.1693547857043.JavaMail.postﬁx@192.168.22.246>• @以降がドメインでない
Message-ID: <6E51BE867EFAC354FC809C3B3EE1AF7B@kmua>

24

ヘッダーのフォーマット不正
Date:フォーマットは古いRFCと⽐較して明確に定義されています• 年は4桁• タイムゾーンは数字
古いフォーマットの例
Date: 21 Nov 97 09:55:06 GMT

25

ヘッダーのフォーマット不正• From:のメールアドレスに@ドメインがついていない

26

ヘッダーのフォーマット不正• 宛先（To/Cc）が空

27

ヘッダーのフォーマット不正• アドレス含めて丸ごとエンコードしてしまっている

To: DUPUIS Rémy <r.dupuis@coopetb
From: Gaëlle Le Breton <g.lebreton@c28未定義のMIMEタイプ• multipartのサブタイプ(2046)• mixed• alternative• digest• parallel• 未定義のものはmixedとして扱うことになっていますが…
• multipart/mixed• text/plain29Thank you