ウェブメールの活用

統合受信トレイ:転送せずに複数のアカウントを確認

著者:Alexey Bulygin
複数のメールアカウントをまとめた統合受信トレイ

統合受信トレイは、複数のアカウントのメールを受信時刻順に並べ、各行に元のアカウントを表示する一覧です。転送でメールをまとめようとして、その限界に気づいた人が探すことの多い仕組みです。

設定によっては送信者の表示が変わり、一部のメールが迷惑メールに入り、返信が相手の知らないアドレスから届くことがあります。結局、別のアカウントは専用のブラウザータブに戻り、日に何度も確認することになります。

ルールを変えるだけでは解決しない場合があります。転送は配送経路を変えるため、メール認証に影響することがあります。SRS、保持された DKIM 署名、受信側が信頼する ARC チェーンは役立ちますが、転送を複数アカウント用のメールクライアントに変えるわけではありません。

別の方法は、クライアントから各メールボックスを直接読むことです。デスクトップのメールソフトでは以前から使われてきました。サーバー側の統合受信トレイも同じ考え方で動きますが、スマートフォンとノートパソコンに同じ一覧を表示できます。

転送がクライアントの代わりにならない理由

転送では、元の送信者が通常 SPF で許可していないサーバーからメールを再送します。そのため SPF 検証が失敗することがあります。署名対象の部分が変更されなければ、DKIM は有効なまま残ることが多いです。DMARC には、SPF または DKIM の検証成功と From アドレスとの整合が必要です。どちらも満たさなければ、p=reject ポリシーは受信サーバーに拒否を推奨します。最終的な処理は受信側が決めます。転送による配送問題は、このように起こります。

Sender Rewriting Scheme は、エンベロープ送信者を転送サーバーの使用を許可するドメインに書き換えます。本記事で説明するシステムでは SRS が自動適用され、新しいエンベロープ送信者の SPF 検証を助けます。ただし、元の From との整合を成立させたり、壊れた DKIM 署名を修復したり、以前のアドレスからの返信を可能にしたりするものではありません。

最後の点は見落とされがちです。転送は一方向にしか働きません。you@oldcompany.com 宛てのメールが新しい受信トレイに届いても、以前のアドレスから送信する設定を別途行わなければ、返信は you@newcompany.com から届きます。顧客とのやり取りでは混乱を招くことがあります。転送ルールだけでは、以前のアドレスを使って送信する権限は得られません。

保存容量も考える必要があります。転送先のコピーは転送先の容量を使い、元のメールは転送元に残る場合があります。転送後に元のメールを削除する設定なら、その場所から復元する手段が失われます。ルールの誤設定によって復旧が難しくなることもあります。バックアップは転送とは別に用意すべきです。

転送は、独立したメールボックスを持たないアドレスには便利です。たとえば invoices@ から請求書の担当者に届ける用途です。ただし、日常的に使う複数のアカウントで読むことや送ることの代わりにはなりません。詳しくはエイリアス、メールボックス、転送の違い転送メールにおける SRSをご覧ください。

POP による取得と従来機能の終了

従来のもう一つの方法は、外部アカウントに POP3 で定期的にログインし、新しいメールをダウンロードして手元に保存することです。Gmail の Mail Fetcher はこの方式でした。Outlook.com の接続済みアカウントも、似た目的の機能でした。

原文では、これらの機能の終了を説明しています。Microsoft は Outlook.com の接続済みアカウントを廃止し、Google もGmail Mail Fetcher と Gmailify の終了を発表しました。現在の提供状況と日程は各社で確認してください。対象は特定の機能であり、複数アカウントへのアクセス方法すべてがなくなるわけではありません。

定期取得には技術的な限界があります。メールは次の確認が行われるまで表示されません。原本を残せば、両方のサービスで容量を使います。状態もずれることがあります。一方では既読、もう一方では未読になったり、片方で削除しても他方には残ったりします。POP3 は元のフォルダー構成を引き継ぎません。

統合受信トレイを実現する三つの方式

それぞれの方式に制約があります。転送はメールを再送するため、認証に影響することがあります。コピーの取得は確認間隔や保存条件に左右されます。リアルタイムの IMAP プロキシは各アカウントで認証し、必要なときに読み出すため、恒久的なコピー保管庫を作りません。無効な認証情報は、接続を試みた際に検出されます。

方式動作主な制約
転送転送元が各メールを転送先に再送する認証に影響することがある。転送だけでは元のアドレスから送信できない
コピーの取得取得先が POP3 で取得元を定期確認し、ダウンロードする遅延、容量の重複使用、状態のずれ、フォルダーがないこと
リアルタイム IMAP プロキシサーバーが IMAP で各アカウントを認証し、必要に応じて読む接続先の稼働状況に依存する。アクセスエラーは取得時に表示される

TrekMail は三つ目の方式を使い、メールの恒久的なコピーを作りません。統合ビューを開くと、サーバーが各アカウントに IMAP 接続し、必要なヘッダーを取得して内部日時順にまとめ、結果を短時間キャッシュします。メールを読むと、権限や設定で変更が許可されている場合、接続先でも既読になります。

アカウントを接続しても、そのホスティング先は変わりません。Gmail は Google にあり、従来の容量、フィルター、ウェブ画面を引き続き使えます。接続は MX や受信経路を変更しません。切断後にコピー保管庫を整理する必要はありませんが、クライアントで既に実行した操作は接続先に残ります。

実際の使い方

ビューは二種類あります。一つは全体を確認するための一覧、もう一つは特定のアカウントだけを見る画面です。作業に合わせて切り替えられます。

すべての受信トレイは、メールボックスと接続済みアカウントを受信時刻順の一覧にまとめます。各行には提供元のロゴ、または TrekMail メールボックスの色付き頭文字が表示されます。返信時には対応する送信者があらかじめ選ばれますが、使えるかどうかは権限と送信設定によります。

アカウント別ビューはサイドバーから選びます。アカウントをクリックすると、そのフォルダー、下書き、送信済みメールが表示されます。

接続先への問い合わせは並列に行います。八台の IMAP サーバーに順番に問い合わせると、ページが明らかに遅くなるためです。認証情報の失効や障害で接続できないアカウントはスキップし、対象を画面に表示します。他の接続先のメールは引き続き確認できます。

正しいアドレスから送信する

接続済み Gmail アカウントのメールに返信すると、あなたのアカウントで認証して Google の SMTP サーバーに返信を渡します。接続と送信権限が正しく設定されていれば、弊社の送信サーバーではなく Google の基盤から送信されます。

これは認証に関わる点です。Gmail の SPF は Google のサーバーを許可しています。許可されていない外部の基盤から @gmail.com として送っても、有効で整合の取れた SPF または DKIM を期待できません。アカウントの許可されたサーバーを使うことが、適切な検証につながります。DMARC は From と整合した有効な SPF または DKIM を要求しますが、両方の成功は必須ではなく、受信トレイへの配達も保証しません。

他のアカウントも同様です。Fastmail のアドレスは Fastmail から、自前のサーバーのアドレスはその SMTP から送ります。差出人メニューには、メールボックスのアドレス、送信を有効にしたエイリアス、返信権限のある共有メールボックス、接続済みアカウントだけが並びます。アドレスがない場合は権限や設定が不足している可能性があり、将来の認証エラーが確定しているという意味ではありません。送信して二分後にエラーを知るより、事前に確認してください。

アプリパスワードと OAuth

大手の提供元は、通常のパスワードによる IMAP アクセスを制限する傾向にあります。接続にはアプリパスワード、OAuth、その他の対応方式を使います。手順は提供元によって異なります。現在のルールと組織のポリシーも確認してください。

提供元接続方法補足
Gmail / Google Workspaceアプリパスワード先に Google の 2 段階認証が必要。利用可否はアカウントのポリシーによる
Outlook.com、Hotmail、Live、MSNMicrosoft OAuth原文では、個人用アカウントの通常パスワードとアプリパスワードによる IMAP アクセス終了を 2024 年九月としている
iCloud Mailアプリ用パスワードApple Account のセキュリティ設定で作成する
Yahoo Mail、AOL Mailアプリパスワード
Fastmailアプリパスワード原文ではデバイスキーと呼んでいる
Yandex Mailアプリパスワード
Zoho Mail、GMXアカウントのパスワード原文の説明による。現在の IMAP と多要素認証の要件を確認する
その他IMAP と SMTP を手動設定cPanel ホスティング、社内 Dovecot、自前のメールサーバーなど

アプリパスワードは、通常はメインのパスワードを変えずに個別に無効化できる、独立したランダムな文字列です。権限が一つのプロトコルだけに限られるとは限らず、提供元によって異なります。アプリにメインのパスワードを渡さずに済みます。設定ウィザードから、認識されたサービスの作成ページへ移動できます。

提供元は自動で判別します。ドメインを既知の提供元と照合し、独自ドメインなら MX レコードを確認します。これにより、@gmail.com で終わらない Google Workspace や Microsoft 365 のアカウントも認識しやすくなります。判別できないときはサーバー情報を手入力します。この確認で DNS が変更されることはありません。

手動接続では、IMAP はポート 993 の暗黙的 TLS または 143 の STARTTLS、SMTP は 465、587、2525 に対応します。TLS 証明書の検証は必須です。信頼されていない自己署名証明書や名前の不一致があると接続できません。メールへのアクセスを許可する接続なので、信頼チェーン、有効期限、サーバー名を確認してください。

アカウントを接続する

  1. ウェブメールを開き、設定 → 接続済みアカウントに進みます。
  2. アカウントを接続をクリックし、アドレスを入力します。
  3. 提供元が認識されたら、アプリパスワードの作成案内に従います。Outlook.com なら Microsoft にサインインします。認識されない場合は、提供元の文書に従って IMAP と SMTP のサーバー、ポート、暗号化方式を入力します。
  4. 接続をテストをクリックします。読み取りと送信を個別に確認するため、どちらで失敗したかが分かります。
  5. 保存します。アカウントがサイドバーに表示され、メールがすべての受信トレイに加わります。

フォルダーの対応付けは初回接続時に行います。提供元によって [Gmail]/Sent MailSent ItemsSent など名前が異なるため、特殊用途のフラグがあればそれを使い、なければ名前を照合します。Gmail のすべてのメールなどの仮想ビューは、同じメールを重複表示しないよう非表示にします。ラベルがあることは、メールが物理的に複数保存されていることを意味しません。

提供元別の手順は、GmailOutlook と MicrosoftiCloudYahoo と AOLその他の IMAP サーバーの文書をご覧ください。

よくある問題と表示

アプリパスワードの失効。よくある原因です。Google のメインパスワードを変えると、アプリパスワードが無効になることがあります。画面はアカウントを隠さず、再接続を促します。新しいアプリパスワードを作り、設定を更新してください。

提供元で IMAP が無効。Google Workspace や Microsoft 365 のポリシーでアクセスが制限される場合があります。クライアント側では回避できません。管理者が権限を確認する必要があります。

OAuth の承認が無効。Microsoft のトークンは、許可が続く間は更新されます。同意の取り消しやセキュリティ設定、ポリシーの変更によって再承認が必要になることがあります。案内が出たら再度サインインしてください。

接続先サーバーの応答が遅い。各接続先にはタイムアウトがあります。応答が遅すぎると、そのページ表示ではスキップして通知します。他のメールボックスを犠牲にして再試行を続けることはありません。

詳しくは接続済みアカウントのトラブルシューティングをご覧ください。

制限

原文の説明では、外部アカウントの接続は Starter 以上のプランで利用できます。

プランメールボックスごとの接続可能アカウント数
Nano利用不可
Starter5
Pro10
Agency30

統合ビューは最大 25 の接続先に同時に問い合わせます。それ以上では、アカウント別ビューのほうが実用的です。接続したメールの恒久的なコピーはプランの容量を使わず、メールは元の場所に残ります。ただし、画面用データの一時キャッシュまでないという意味ではありません。

よくある質問

統合受信トレイはメールを移動しますか?

いいえ。恒久的なメール保管庫をコピーしたり移動したりせず、元の提供元から IMAP で読みます。切断しても元のメールボックスは削除されませんが、既読化など既に実行した操作は元に戻りません。

メール移行とは何が違いますか?

移行は、以前の提供元から離れるためにメールを TrekMail へコピーします。統合受信トレイは保存先を変えず、共通の画面を提供します。完全に移すなら、一括移行を使ってください。

返信は正しいアドレスから届きますか?

権限と設定が正しければ、接続したアドレスの SMTP から送信され、相手には従来のアドレスが表示されます。有効で整合した SPF または DKIM は提供元の設定次第です。接続だけで認証や配送が保証されるわけではありません。

Gmail でサインインボタンではなくアプリパスワードを使うのはなぜですか?

この連携はアプリパスワードで IMAP を使います。Gmail API は制限付き権限の審査や、データの扱いによっては外部のセキュリティ評価を必要とする場合があります。アプリパスワードは別のアクセス方法で、アカウントのポリシーが作成を許可していれば、Google で個別に無効化できます。IMAP と API が同じ権限を与えるとは限りません。

自分のサーバーのメールボックスも追加できますか?

はい。IMAP と SMTP のサーバー、ポート、暗号化方式を手入力します。証明書は信頼性と名前の検証を通る必要があります。信頼されていない自己署名証明書は交換してください。公的な認証局の証明書は、チェーン、有効期限、名前が正しければ使えます。

スマートフォンでも使えますか?

はい。接続設定はローカルのプロフィールではなくサーバーに保存されます。対応する端末でログインすれば、再設定せずに同じアカウントと一覧を表示できます。

接続済みアカウントに対応しないプランへ変更するとどうなりますか?

取得が止まり、アカウントは利用不可と表示されます。プラン変更で接続先のデータが削除されることはありません。対応プランに戻したとき、認証情報と権限が有効なら再びアクセスできます。

この記事を共有

投稿 共有 共有

TrekMail の運用と保護に必要な技術を使用します。確認すると、Cookie ポリシーに記載された限定的な分析と広告測定も許可されます。

TrekMail にサインイン

ダッシュボード、メールボックス、DNS にアクセスできます。

または

12 文字 パスワードが一致

または

再設定メールを送信しました

このメールアドレスのアカウントが存在する場合、パスワード再設定の手順をお送りしました。

続行すると、TrekMail の 利用規約 および プライバシーポリシーに同意したものとみなされます.