このCSSコードは、メッセージが読み取られた場合、およびメッセージが読み取られた期間を公開しますか？
電子メールには、http://example.com/[tracking_id].pngなどの外部でホストされている画像への参照が含まれており、追跡会社が画像をホストするサーバーを制御します。会社は、一意の各画像URLがメールクライアントによってロードされる方法と時期を記録します。
お気づきのように、印刷操作は@media print CSSディレクティブの追跡画像によって記録できます。これは、ユーザーが実際に電子メールを印刷するまで追跡画像が読み込まれないことを前提としています。
表示時間の長さは、理論的にはゆっくりと読み込まれる画像によって追跡できます。サーバーはHTTP応答を永久に未完成のままにし、ユーザーが電子メールから離れてナビゲートしたときにのみ終了します。サーバーは、クライアントが接続を終了するのにかかった時間をログに記録できます。ただし、HTTPでこのようなスローロードの動作を確認していません。 TCPソケットで同様のことを行うことができる場合があります。これは、HTTPリクエストが完了した後も開いたままになる可能性があります（画像はConnection: keep-aliveで提供されるため）） TCP接続は、そのキープアライブリソースを要求したページから移動した後も維持される可能性があることを示唆しています。
この可能性を除いて、あなたが含めたコードはしないメールの検索に費やした時間を追跡しているようです。おそらく時間追跡は、このトラッカーでは有効になっていないプレミアム機能です。
検討できる他の唯一の（少しばかげた）可能性は、ナビゲーションアクションが実行されるときに/Fリソースが何らかの方法でロードされることです（つまり、ナビゲーションアクションにより、CSSルールが適用されるドキュメント構造が操作されます）。 。ただし、この（まったく存在しない）理論が当てはまる場合、時間追跡はWebベースのメールでのみ機能します。
最後に、削除を検出する機能はありません。この記事は、メールを見るのに2秒もかからなかったユーザーがメールを削除したことを前提としています。
私はクライアントからこれらの質問を定期的に受け取ります。基本的な問題は、電子メール追跡技術にはクライアントからの協力が必要なことです。他の答えは画像追跡を分析したので、ここでは繰り返しません。ただし、クライアントがサーバーから画像をロードする必要があることを指摘します（このサーバーは現在、ブロックリストにあります）。
Webベースの電子メールクライアントは、CSSの問題を徹底的に解決するため、おそらくインラインオプションを使用するか、受信者のMXレコードに基づいて配信を調整します。デスクトップクライアントには通常、「イメージのダウンロード」オプションがあり、簡単にオフにすることができます。
したがって、読者があなたと協力していれば、読者があなたのメッセージをどう処理したかを知る（または推測する）ことができます。メッセージの40％が「未読」として返された場合、メッセージが読まれなかったことを意味するのではなく、クライアントがメッセージを読んだかどうかを通知しなかったことを意味します。同様に、ウイルススキャナーが「読み取りと削除」と解釈されて処理するためにすべてを取得しているのを見ることができます。