今まで読み逃してたかも！iPhone版Gmailアプリで「転送メール」が表示されないバグ？について（message/rfc822）

実験のために、（後述するとある方法で、）転送メールを自分のメールアドレスに転送してみました。

Web版Gmailの場合（成功）

まず、こちらがGmailで受信したメールの内容です。

転送メール本文の後半に、「転送メッセージ」という区切りがあって、その後ろに「From」や「To」「Subject」など、転送されたメールの内容が表示されています。

これは、正しく転送内容が表示された例です。

iPhone版Gmailの場合（おかしい）

これと全く同じメールを、iPhone版Gmailからも見てみます。すると、次のように表示されます。

こちらでは、どういうわけか、転送されたメールの内容が、一切表示されていません。

今回気になったのは、この挙動です。

※今回のテストは、「iPhone版Gmail 3.1415926」+「iPhone 6 Plus + iOS 8.1.3」で行いました。

さて、先ほど「とある方法で転送」と書いたのですが、実は「転送」には、２つの方法があります。その内の片方でしか起こらないので、今回はそちらの方法で実験しました（よく使われる「Yahoo!メール」から！）。

転送方法１：本文に書く

まず一つ目は、「本文に書く」という方法です。

それ以外何があるの？と思うかもしれません。実際そうかと思います。

こちらの転送方法では、単純に送信メールの本文の後ろに、転送したいメールの内容を書いているだけ、というものです。

つまり、手動でも簡単にできるような方法です。

こちらでは、問題が起こりません。

転送方法２：「添付」を使用する

もう一つの方法が「添付」という機能を使うものです。

今回の問題や、この「添付」を理解してもらうには、そもそも電子メールが、どんな形式でメールを送信しているのか、という仕組みを少し理解する必要があります。

なので、その解説をちょっと交えつつ、説明します。

といっても、私も今回初めて「マルチパート」という名前を知りました。

先ほどのテストメールのソース（詳細）を表示すると、次のようになります。

…（省略）…
To: "xxx@gmail.com" <xxx@gmail.com>
In-Reply-To: <xxx>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0-1234567890-1234567890=:12345"

0-1234567890-1234567890=:12345
Content-Type: text/plain; charset=iso-2022-jp

転送テスト。

メールを転送します。
0-1234567890-1234567890=:12345
Content-Type: message/rfc822

X-Apparently-To: xxx via xxx.xxx.xxx.xxx; Wed, 28 Jan 2015 11:19:32 +0900
…（省略）…

前提：「メール」の本当の中身をメールアプリが「解釈」して表示している

「電子メール」というシステムの中では、実際には、このような文字の列（文字列）がやりとりされています。

そして、この難しい文字列を、各メーラー（メールアプリ）が解釈して、メールは表示されています。

中身が「マルチパート」！

今回知って欲しいメールの仕組みを理解するポイントは、先ほどのメールの中身の「Content-Type: multipart/mixed; boundary="0-1234567890-1234567890=:12345"」という部分です。

「multipart/mixed」は、簡単に言えば、「このメールの中身が複数の部分（パート）から成るよ」ということを示しています。

そして、「パートの区切り（boundary）は、『0-1234567890-1234567890=:12345』という文字列で表現しているよ」ということを意味しています。

つまり、この区切りの文字列に注目すると、先ほどのメールの中身は、

Content-Type: text/plain; charset=iso-2022-jp

転送テスト。

メールを転送します。

という部分と、それより後ろの

Content-Type: message/rfc822

X-Apparently-To: xxx via xxx.xxx.xxx.xxx; Wed, 28 Jan 2015 11:19:32 +0900
…（省略）…

というパートに分けて考えられます。

マルチパートなメールの解釈方法

さて、この２つのパートのうち、前者がよく言う「メール本文」です。

「Content-Type」は、各パートの「中身の形式」を宣言している行です。

ここが「text/plain」となっているので、これは「単なる文章」という意味になっています。（というわけで、）ここが本文に相当します。

転送メールは第２パートに

しかし、この「本文」には、先ほどPC版Gmailで表示されていた「メールを転送します」より後ろの部分がありません。

実は、転送メールの内容は、２つ目の部分（パート）に含まれているのです。

ここでは、「Content-Type」が、「message/rfc822」と書かれています。

この「message/rfc822」は、「このパートは、『メール』ですよ」ということを意味しています（重要）。

つまり、メールの中にメールが入れ子になっているような状態を表しています。この中身には、本当にメールの形式が入れ子されていて、続きを読むと、転送内容の本文も含まれています。

添付ファイルもこの仕組み

実は、添付ファイル、例えば画像なんかも、このマルチパートの仕組みが利用されています。

画像を添付する場合では、「Content-Type」が「image/jpeg」のパートを作成して、「ここから画像のデータだよ」と宣言することで、画像が添付されたりします。

さて、「マルチパート」と「ContentType」の中身がざっくり分かってもらえたかと思います。

今回表示できなかった転送メールは、転送メールが「ContentType: message/rfc822」となっていました。

どうやら、iPhone版のGmailが、この「ContentType: message/rfc822」となっているパートを、解釈してくれない（表示できない）ようなのです。

おそらく、多くの人が使用する「転送」は、単に本文パートの後ろに、転送メールの内容を書いただけだと思われます。

しかし、身近なところでも、この「message/rfc822」によるメールの転送が行われています。

なので、読み逃していた人が結構いるかも、と思うのです。

Yahoo!メール

Yahoo!メールでは、「転送」ボタンをクリックすると、「そのまま転送」と「添付ファイルとして転送」が選択できるのですが、このうち「添付ファイルとして転送」を選ぶと、転送メールが「ContentType: message/rfc822」となって、「添付」されます。

多くの人は「そのまま転送」を選択するとは思うので、こちらを選択していた人が、今回の問題に遭遇して「送ったはずなのに読んでもらえてなかった」とはならないと思います。

しかし、「添付ファイルとして転送」を使って送られてきたメールの添付メールを、思いっきり読み逃していた可能性はあります。

実は、「添付ファイルとして転送」を使うと、本文の編集画面に転送メールの中身が表示されないため、一度使うと、使いやすい、と思う人もいるかも知れず、こちらを優先的に使っている人もいるかもしれません。

Mew （Emacsで動くメールリーダ）

私が実際に「添付メールが見られない！！」となったのが、こちらの「Mew」を使用して送信されてきたメールです。

私はMewを使ったことはないのですが、少なくともMewを使用してBCCでメールを転送すると、添付ファイルとしてメールが転送されるようです。

• MIME の基礎

今回は、ちょっと気になって調べてみた、「転送メールが表示されない」という現象について紹介しました。

今のところ、iPhone版Gmailアプリが、「ContentType: message/rfc822」のパートの表示に失敗しているバグ（もしくは非対応）なのではないか、と考えています。

2008年ごろはPC版のGmailでもmessage/rfc822に対応していなかったなんて話や、message/rfc822で検索してみると、関連するアプリのバグ報告が複数引っかかったりしたので、利用者の多いiPhone版Gmailアプリですが、このバグ（or非対応）＆理由（message/rfc822）が正解、という可能性はそこそこありそうだな、と思っています。

ちなみに、Android版Gmailアプリ（バージョン4.9(1271612)）では、問題ありませんでした。

今回MIME（メールの中身、と言っていたあれの形式の名前）についていろいろ勉強できました。今まで、添付ファイルもテキスト（base64）で送信されているという話は知っていたのですが、ここまで詳細を見ることはなかったので。

こういう「表示できない」という現象から、「こんな原因（meessage/rfc822を解釈できない）のバグかな？」と推定するプロセスは楽しかったです。