RFC5322: メールの基準を理解する - 必須ヘッダから正規表現まで

RFC RFC5322 技術情報

RFC（Request for Comments）はインターネット上の通信や技術、運用に関するさまざまな仕様をまとめた文書シリーズになります。Request for Comments - Wikipediaによれば、RFCのコンセプトは1969年に生まれており、現在もコンピュータネットワーク研究者の公式発表の場となっています。

インターネットに関わるエンジニアであれば、RFCには一度は触れたことがあるでしょう。アプリケーション層であっても、たとえばRFC 8259はJSON（JavaScript Object Notation）に関する定義が書かれています。そうしたRFCの中でもメールに関する仕様がまとめられたのが、今回紹介するRFC 5322です。

RFC5322とは

RFC5322はInternet Message Formatとなっており、電子メールの形式を定義しています。原文はこちらで、日本語訳された内容はこちらで読めます。一つ前の標準であるRFC822をベースに、2008年10月に公開された標準です。

RFC5322ではメールの形式について詳細に定義されており、メールのヘッダ、本文、添付ファイルなどについての仕様が記載されています。RFC5322に準拠したメールを作成することで、メールの配信成功率を向上させることができます。逆に言えば、RFC5322に準拠していないメールは配送エラーになったり、受信者のスパムフォルダに入ってしまう可能性があります。そのため、メール送信に関わるエンジニアはRFC5322についての理解が必要です。

RFC5322の遵守は、メール通信の効率性と信頼性を保証します。特に、メールのヘッダフィールドには「必須（最低一つ）」であるものと、「最大1つ」存在してよいものがあり、これらの制約を理解し適用することが重要です。メッセージIDなどのフィールドはグローバルに一意である必要があり、メール送信ライブラリのデフォルト設定がローカルホスト名を使用する場合、適切なドメイン名を指定して一意性を保証する必要があります。これらのガイドラインに従うことで、メールは適切に解釈され配信され、受信者にとっての信頼性が高まります。

本記事の目的と対象読者

本記事はRFC5322にて取り扱っている内容を解説します。メール送信はSMTPサーバーに送信したり、APIなどを使って実行されることが多いので、その内容について詳細を確認するケースは多くないでしょう。しかし、仕様を把握しておくことで、何らかのエラーが発生した場合のトラブルシューティングがしやすくなります。また、ユーザーからの要望に対してRFC5322に準拠しているかどうかを検証することで、外部のメールサーバーに対して信頼性の高いメール配送が実現するでしょう。

メール送信機能を開発するエンジニアの方はぜひご覧ください。

電子メールの構造

電子メールは以下の3つのパートに分かれています。

  1. ヘッダー
  2. 本文
  3. 添付ファイル

メールの必須ヘッダー

RFC5322によると、メールには以下のヘッダーが必須とされています。他のヘッダーはすべてオプションです。

  • Date:
    発信日時
  • From:
    送信者アドレス
  • Message-ID:
    メッセージID
RFCではMessage-IDについて『SHOULD be present』と記載されており、必須とは一概には言えないですが『含めるべき』と考えられますので必須に記載いたしました。

Message-IDヘッダー
Message-IDは、RFC5322において非常に重要なヘッダーの一つであり、各メールメッセージにグローバルに一意な識別子を割り当てることが目的です。これにより、メッセージの追跡や重複の検出が容易になります。Message-IDの形式は、一意性を保証するために特定の構造に従う必要があります。

形式
Message-IDは、通常の形式を取ります。ここで、unique-partはそのメッセージが一意であることを保証する部分であり、domainはメッセージを生成したエンティティのドメイン名です。一意性を保証するためには、unique-partがそのドメイン内でユニークである必要があります。

グローバル一意性
Message-IDがグローバルに一意であることは、メールの追跡や管理を容易にするために重要です。このため、メールを生成する際には、ランダム性や時刻などを用いてunique-partを生成し、適切なドメイン名を用いることが推奨されます。

ローカルホスト名の問題
また、多くのメール送信ライブラリやシステムは、デフォルト設定でローカルホスト名をMessage-IDのドメイン部分として使用します。これは、インターネット上で一意ではない可能性があるため、グローバルに一意なMessage-IDを生成する上で問題となることがあります。特に、ローカル開発環境や内部ネットワークで使用されるドメイン名は、外部との重複の可能性があります。Message-IDがグローバルに一意であることを保証するためには、メール送信ライブラリの設定を調整し、適切なドメイン名を明示的に指定することが重要です。これにより、ローカルホスト名の代わりに、インターネット上で一意性が保証されたドメイン名を使用することができます。

その他のヘッダー

電子メールで使われるヘッダーは多種多様で、サービスによって追加される場合もあります。よく使われるものを以下に紹介します。

  • To:
    宛先
  • Cc:
    カーボンコピー
  • Reply-To:
    返信先
  • Subject:
    件名
  • Sender:
    送信者（代行する場合に使用）
  • Received:
    メール受信時の経路情報
  • References:
    スレッドの参照
  • In-Reply-To:
    返信先のメッセージID
  • Comments:
    コメント
  • Keywords:
    キーワード
  • Resent-Date:
    再送信日時
  • Resent-Message-ID:
    再送信メッセージID
  • Resent-To:
    再送信先
  • Resent-From:
    再送信元
  • Resent-Cc:
    再送信カーボンコピー
  • Resent-Sender:
    再送信者（代行する場合に使用）
  • Return-Path:
    エラーメールの送信先
※上記で記載している『Return-Path』および、『Received』に関してはメール送信時にはヘッダーに記載されません。受信したメールサーバーに記載されます。
『Return-Path』に関しては最終到達先のメールサーバだけが記載し、
『Received』に関してはメールリレーの経路途中の各メールサーバにも記載されます。
特にReturn-Path は送信時に記載すると、そこにエラーメールが返ってくるのではなく、エラーメールの返信先はエンベロープFromになります。 （最終到達先のメールサーバに届くとエンベロープ情報は失われるので、Return-Path に記載されます。）

追加ヘッダーについて

サービス独自のメールヘッダーを追加する場合、 3.6.8. Optional Fields で規定されている内容に沿う必要があります。とはいえ、規定は柔軟で、「既存のフィールド名を使わないこと」「ヘッダーの値はスペースとコロン、そしてASCII文字列のみ」となっています。

なお、特に規定は見つかりませんでしたが、ヘッダーの名称は英字とダッシュのみを使うことが一般的なようです（数字も使われていません）。

メールアドレスの構成

メールアドレスの仕様はRFC5322はもちろんのこと、RFC5321にも記述されています。以下の内容はどちらも含めた形です。

メールアドレスの書式基準

メールアドレスは、以下のような構成になっています。

local@domain
  • local は64文字まで指定できます。 domain は最大255文字です。
  • 大文字・小文字は区別されますが、実際には区別しない実装がほとんどです。
  • dot-atom形式（ local ）とquoted-string形式（ "local" ）があります。
    • dot-atomではラテン文字、数字、一部の記号が利用できます
    • quoted-stringではほとんどのASCII文字が利用できます
  • @の前に . を置くことはできません。
  • . を連続しておくのも違反です。

メールアドレスの検証

メールアドレスの検証を実装するのは非常に大変で、各プログラミング言語向けに専用ライブラリや関数が用意されています。

各プログラミング言語別のメールアドレス検証方法 - Customers Mail Cloud ブログ

正規表現での検証として、Email Address Regular Expression That 99.99% Works.というサイトがあります。ここで紹介されている正規表現を用いると、99.99%正確に検証できるそうです。ただし、0.01%の可能性で判定をミスしてしまうくらい、メールアドレスの検証は複雑とも言えます。

以下は一般的な正規表現の例です。

(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])

メール本文の構成

メール本文はRFC5322に基づいて、以下のような仕様があります。

  • 各行は998文字以下
  • CRLFを除いて78文字以下

フューチャーフォンなど、昔のメールクライアントでは自動的にメールを改行する場合がありました。この時、78文字で区切るケースが多いです。そのため、78文字までにしておくことで、自動改行を防ぎ、意図せぬ表示になるのを防止できます。

1行あたり998文字を超えたメールを送るとRFC違反となって受信拒否される場合もあるでしょう。

他の標準について

インターネット上でのメッセージ送受信については、RFC5322以外にも標準があります。

RFC5321との違い

RFC5321はSimple Mail Transfer Protocol（SMTP）についての仕様を定めています。つまりサーバー間でのメッセージ送受信に関するプロトコル、データ構造について定義されています。RFC5322はメールの形式についての仕様であるため、その点がRFC5321とは異なります。ただし、RFC5321に準拠していないメールは配信エラーになる場合もあるので仕様に則る必要があります。

RFC822との違い

RFC822は古いインターネットメッセージに関する標準です。現在はRFC5322になります。RFC822はエンベロープフィールドとヘッダーフィールドを明確に区別していなかったなど、RFC5322に比べて不明瞭な部分があります。ただし、RFC822は広く使われていたため、完全に作り直すことはできなかったようです。

RFC5322の実装をチェックする

メールが正しい実装になっているかどうか検証することで、メールの到着率が変わってきます。検証ツールや、スパムチェッカーサービスが利用できます。

チェックツール

外部サービスのメール検証サービスです。多くの場合、指定されたメールアドレス宛にメールを送信することで検証されます。

準拠したサービスを利用する

自分たちで実装するのではなく、元々RFC5322に準拠したサービスを利用するのも一つの手です。私たちの提供するCustomers Mail CloudはRFC5322に準拠したメールをAPI、SMTP経由で送信できます。

Gmailにおける「新しいメール送信者のガイドライン」の概要について - Manual - Customers Mail Cloud

ライブラリを利用する

メール全体に対してRFC5322準拠をチェックするライブラリは見つかりませんでした。メールアドレスの検証については、前述の各プログラミング言語別のメールアドレス検証方法 - Customers Mail Cloud ブログなどを参考にしてください。ライブラリを用いずに正規表現で検証する場合には、Email Address Regular Expression That 99.99% Works.が参考になるでしょう。

Customers Mail Cloudを使ってRFC5322に準拠したメールを送信するには

Customers Mail Cloudでは、メール送信に際して2つ方法を用意しています。

  • SMTPリレー
  • Email Sending API

SMTPリレー

SMTPリレーを使用する際、送信者はメールの形式や内容に完全な自由を持ちます。これは、企業が特定のニーズに合わせてカスタマイズしたメールコンテンツを作成できることを意味します。この柔軟性により、ユーザー固有のニーズに合わせたメール設計が可能になります。

しかし、自由度が高い一方でRFC5322に準拠したメールを作成するためには、いくつかの技術的な知識が必要になります。特に、メールヘッダ内の必須ヘッダが不足していると、メールが正しく送信されないか、受信者のスパムフォルダに入ってしまう可能性があります。これは、ビジネスコミュニケーションにおいて大きな問題を引き起こす可能性があります。

Customers Mail Cloudはこの問題を解決します。SMTPリレー経由で送信されるメールに不足している必須ヘッダがある場合、自動的に検出して足りないヘッダを追加してRFC5322に準拠させます。これにより、送信者はメールの形式や内容に集中することができ、技術的な詳細について杞憂する必要がなくなります。

これは、特に技術的なバックグラウンドがないユーザーや、迅速かつ効率的なメールコミュニケーションを必要とするビジネスにとって、非常に価値があります。Customers Mail CloudのSMTPリレー機能により、メール送信のプロセスはより簡単かつ確実になり、メールの配信成功率も向上します。

Email Sending API

Email Sending APIを利用すれば、メールはクラウドで直接生成されます。もちろん、生成されるメールはRFC5322に準拠しています。開発者はメールのフォーマットやRFC5322への準拠を気にする必要がありません。また、一括配信を行う際にSMTPリレーではメールの送信数分リクエストが必要ですが、APIの場合は数回の呼び出しで完了できます。マーケティングキャンペーンや、メールマガジンなどの大量メール配信に対して特に価値を発揮します。

APIを利用する最大のメリットは、生成されるメールが必ずRFC5322に準拠していることです。メールの形式や準拠性について心配することなく、メールの内容や送りたいメッセージに集中できます。例えば、マーケティングキャンペーンや顧客への通知メールを作成する際、メールのデザインやコンテンツにフォーカスして、技術的な側面はCustomers Mail Cloudに任せられます。

Email Sending APIは、メール送信のプロセスを自動化し、効率化するのに役立ちます。APIを通じてプログラマブルにメールを作成、送信できます。外部システム連携や、自社システムからのメール送信など、様々なシナリオでメール送信効率を向上できるでしょう。

まとめ

本記事のまとめです。

  • メールをシステムから送信する際には、RFC5322に準拠したメールを送信しましょう
  • RFC5322に違反していることで、送信先のメールサーバーに除外されてしまう可能性があります
  • RFC5322に準拠しているかどうかは、検証ツールやライブラリを使って確認できます
  • RFC5322に準拠したメール送信サービスを利用するのもお勧めです

メールの到達率を向上させる上でも、Customers Mail Cloudの利用を検討してください。

Customers Mail Cloudの資料ダウンロードはこちらから