使い捨てメールの添付ファイル：上限3.5MBの内訳・ダウンロードと安全性

添付ファイルとして届くのはどんなファイルか

メッセージはパーツのツリー構造になっていて、そのうちファイルなのは一部だけです。ここでのルールは意図的に緩めに設定されています。というのも、送信元が正しくラベル付けしてくれることを信頼する代わりの方法だと、メールクライアントなら表示していたはずの添付ファイルを、気づかないうちに取りこぼしてしまうからです。

そう明示されているもの

Content-Dispositionがattachmentになっているパーツです。もっとも一般的なケースで、どのメールクライアントも一致して添付ファイルと認識します。

ファイル名を持つもの

他のラベル付けがどうであれ、filenameを持つパーツです。送信元によるラベルの付け間違いは頻繁に起こりますが、名前を持つファイルはファイルです。

テキストではない、名前付きのパーツ

nameを持ち、かつタイプがtext/…ではないパーツです。これによって、HTML署名内のロゴ画像などが拾われます。そのため、想定していなかった添付ファイル、送信元自身も添付ファイルだとは思っていなかったものが、メッセージに含まれて届くことがあります。

そのため、実際に表示される添付ファイルの数は、送信元が意図していた数より多くなることがよくあります。1通のメッセージが保持する添付ファイルは最大20個までです。ファイル名を持つパーツが20個を超えるメッセージでは、最初の20個だけが保持され、残りは破棄されます。何かを組み立てる前に知っておく価値のある仕様です。

受信したファイル名がそのままパスとして使われることはありません。ファイルは生成された名前で保存され、元のファイル名はデータとして別途保持されます。そのため、送信元がファイル名にスラッシュを含めることで、ファイルの保存先を自分で選ぶことはできません。

添付ファイルの容量上限は実際どこにあるのか

公開されている数字は5 MBですが、これが何を測っているのかは正確に理解しておく価値があります。測定対象は、エンコード後のメッセージ全体です。添付ファイル単体でも、添付ファイルの合計でもなく、MIMEエンコードによってすでに膨らんだ状態で、送信サーバーが引き渡すすべてです。

base64は、バイナリデータがテキスト用に作られたプロトコルを通過するための仕組みで、3バイトごとに4バイトへと変換します。そこに必要な改行を加えると、ファイルはディスク上にあったときより約3分の1、改行の分を数えるともう少し大きくなって届きます。5 MBから逆算すると、実質的な上限はおよそ3.5MBのファイルになり、署名やHTMLパートを含むメッセージではさらに小さくなります。

何を測っているか

ヘッダー、テキストパート、HTMLパート、そしてすべての添付ファイルです。いずれもエンコード後の状態で測定されます。

1通あたりの添付ファイル数

20個です。実際には、これより先に容量の上限に達することがほとんどです。

テキストパート

デコード後、それぞれ最大2MiBまで保持されます。これを超える本文は切り詰められて保存されます。通常のメールがこれに近づくことはまずありませんが、自動生成されたレポートなら話は別です。

ファイルが大きすぎるとどうなるのか

何も保存される前に、SMTPのやり取りの段階で門前払いされます。サイズを事前に申告してくる送信サーバーは、その場で即座に拒否され、やり取りはおおよそ次のように終わります。

>>> MAIL FROM:<news@example.com> SIZE=7602176
<<< 552 5.3.4 Message size exceeds fixed limit

これは見た目以上に重要な仕組みです。仮にメッセージをいったん受け入れてから後で破棄するサービスだったなら、送信元は配信されたと思い込み、あなたは決して現れないものをいつまでも待つことになります。SMTPの時点で拒否されるということは、実際の失敗が実在の人物に報告されるということです。送信元には理由の書かれたバウンスが返ります。

サイズを事前に申告しない送信元の場合は、メールサーバーが自分でバイト数を数え終えたメッセージの末尾で、同じ答えが返されます。いずれの場合も、メールボックスには何も届かず、途中で切れた状態で届くこともありません。

受信箱から添付ファイルをダウンロードする方法

ブラウザ上では、予想どおりの場所にあります。メッセージを開くと、その下に添付ファイルが一覧表示され、それぞれに送信元が付けた名前と、実際に届いたサイズが表示されます。

1. メッセージを開く。一覧は自動的に更新されるため、メールボックスを見ている最中に届いたファイルも、再読み込みなしで表示されます。
2. クリックする前に、名前とサイズを確認する。どちらも実際に届いたものについての事実であり、ファイルが自分のマシンに載る直前に見られる最後の情報です。
3. クリックする。ファイルがダウンロードされます。自分が何であると名乗っていようと、ブラウザ内で開かれることは一切ありません — これが欠点ではなく仕様である理由は、次のセクションで説明します。

メッセージ本文内のリモート画像は、こちらが許可するまでブロックされますが、これは添付ファイルとは別の話です。ブロックされた画像は、許可した瞬間に送信元自身のサーバーから取得されるのに対し、添付ファイルはメッセージと一緒に届いており、どこからも取得されません。

APIから添付ファイルをダウンロードする方法

メッセージを読み取ると、添付ファイルが一覧として返され、それぞれにあらかじめ組み立てられたURLが付いています。

"attachments": [
  {
    "id":       "01JR8W2K4QATT1",
    "filename": "invoice.pdf",
    "mime":     "application/pdf",
    "size":     184320,
    "url":      "/api/v1/attachment/01JR8W2K4QATT1?mailbox=k7fq2m%40grabmail.io"
  }
]

そのURLはメールボックスをクエリパラメータに持つ、ただのGETリクエストです。公開ドメインでは、それ以外に何も必要ありません — キーもセッションもアカウントも不要です。

curl -OJ "https://grabmail.io/api/v1/attachment/01JR8W2K4QATT1?mailbox=k7fq2m%40grabmail.io"

-OJは、curlに対して、idではなくサーバーが送ってくる名前でファイルを保存するよう指示するオプションです。このエンドポイントが返すのは次の3つのいずれかです。ファイル本体、そのメールボックスに該当する添付ファイルが存在しないか期限切れの場合の404、そして1秒に1回を超えてリクエストした場合の429です。

添付ファイルのidはメールボックスごとに閉じているため、あるアドレスのidを別のアドレスで使うと404になります。添付ファイルだけを一覧するエンドポイントは存在せず、常にメッセージと一緒に届き、そこから読み取ります。メッセージ応答の完全な形式はAPIリファレンスに載っています。

なぜ添付ファイルはバイナリとしてダウンロードされるのか

送信元がファイルを何と名乗っていようと、それはapplication/octet-streamとして返され、開かれるのではなくダウンロードされます。これはコンテンツタイプの扱いが雑なのではなく、見知らぬ相手から届いたファイルに対する唯一の安全な答えだからです。

送信元が指定したタイプはそのまま返さない

ファイルにtext/htmlというラベルを付け、それが当サイトのオリジン上でレンダリングされてしまえば、送信元はあなたのセッションの中で、当サイトになりすまして自分のページを動かし、それによって到達できるものすべてに手を伸ばせることになります。そのため、このラベルは破棄され、ファイルが何であるかは、呼び出す側が添付されたメタデータから判断します。

常にダウンロードのみで、表示はしない

すべての応答にContent-Disposition: attachmentが付くため、ラベルが何であれ、その場で表示されることはありません。

タイプの推測も、実行もさせない

X-Content-Type-Options: nosniffがブラウザによるタイプの推測を止め、default-src 'none'; sandboxというContent-Security-Policyにより、万が一何かがレンダリングされたとしても、何も読み込めず何も実行できません。

ファイル名がヘッダーに化けることはない

ファイル名は応答にそのまま貼り付けられるのではなくエンコードされるため、改行を含む名前のファイルであっても、勝手にヘッダーを追加することはできません。

ファイル本体には一切手を加えていません — 送信元が送ったとおり、1バイトも違わずそのままです。意図的に無味乾燥にしてあるのは、その周りの枠組みのほうです。ファイルはウェブルートの外に保存されているため、パスを推測しても侵入経路にはなりません。ファイルが読み取られる前に、必ずメールボックスの解決と認可が行われます。

添付ファイルはウイルスチェックされているのか

ウイルス対策ソフトも、サンドボックスでの実行検査も、レピュテーションチェックもありません。これは見落としではなく、明言された制約であり、届いたものに対して安全にできることの範囲を変えます。

• 公開アドレスには誰でも送信できます。相手はあなたを知っている必要はなく、アドレスを知っていればよく、短いアドレスは推測されます。公開メールボックスにあるファイルは、初期状態では差出人が不明です。
• 実行ファイルやスクリプトの危険性は、他の場所とまったく変わりません。拡張子によるフィルタリングは行われず、アーカイブの中身を覗いて確認することもありません。
• 何かを実行できる文書ファイルこそが、実際にはよくあるケースです。マクロ付きのオフィスファイルや、アクションが埋め込まれたPDFが実際の被害の大半を占めており、わかりやすい実行ファイルではありません。
• 名前からは何もわかりません。invoice.pdfという名前のファイルであっても、実体はそのバイト列が示すとおりのものであり、拡張子は送信元が自由に選んだものにすぎません。

添付ファイルはいつまで残るのか

添付ファイルには、それ自体の寿命はありません。メッセージに属していて、メッセージが消えるときに一緒に消えます。

5日後

既読・未読にかかわらず、メッセージと一緒に削除されます。カウントは届いた時点から始まります。アーカイブもエクスポートもありません。

メッセージを削除したとき

即座に消え、URLは404になります。受信箱から削除しても、APIから削除しても同じです。

元に戻す方法はない

削除の取り消しも、猶予期間も、問い合わせ先のサポートメールボックスもありません。明日また必要になりそうなものは、今日のうちにダウンロードしておく必要があります。

メールでの添付が向かないケースとは

ここでの添付ファイルの使い方の中には、上限を回避すれば済む話ではなく、そもそも道具の選び方が間違っているものがあります。

• 上限を超えるファイル。それを引き上げる方法はありません。代わりにリンクを送ってください。
• 来月また必要になるもの。5日という期限は、設定ではなくジョブによって強制される絶対的な上限です。今のうちに取得しておくか、本物のメールボックスを使ってください。
• 見知らぬ人に読まれると困るもの。公開ドメインでは、アドレスだけが唯一の鍵であり、しかもそれは短い鍵です。

独自ドメインを使えば、この3つ目だけが変わり、最初の2つは変わりません。容量の上限も保持期間もまったく同じですが、アドレスがこのサイト上のどこにも登場しない名前の上に置かれるため、誰かが当てずっぽうでファイルを送りつけてくることはなくなります。必要なのはMXレコード1件だけです。

お使いのドメイン用のMXレコード10 smtp.grabmail.ioコピー

詳しい手順はこちら。レコードの内容、それを公開することで何が証明されるか、そしてパスワードのないメールボックスの正直な限界について解説しています。

質問