如上所述，Gmail 的预取仅在有限的情况下发生。其他邮件客户端不会发生预取。这种行为仅在 Gmail 用户在网页浏览器中打开 Gmail 应用或积极使用移动应用时出现。 我们最佳的猜测是这是在用户浏览器中显示电子邮件之前进行的安全扫描。

下方详细列出了图像请求的完整请求标头。您将注意到几件事情：

• 引用来源（referer）被设置为 http://mail.google.com。有趣的是，即使用户在 https:// 上，Gmail 仍然在发出请求时将引用来源设置为 http:// 协议。 

• 请求来自 Gmail 的服务器，而不是用户的浏览器。客户端 IP 始终解析为 Google 拥有的 IP 空间。

• 与 Google 图像缓存不同，用户代理字符串没有标识请求来自 Google 的机器人之一。相反，用户代理字符串看似一个实际的用户图像请求。但是，我们已确认此用户代理字符串确实标识了 Google 预取机器人。

• 打开请求发生在邮件传递后的几秒钟内。此外，该请求发生在电子邮件出现在用户的 Gmail 界面之前。这种行为使我们相信请求是出于安全目的。

• 预取似乎仅发生在未读的 Gmail 邮件线程中。经过广泛测试后，一旦用户阅读了消息，任何进入该线程组的未来邮件都不会启动预取请求。

• 此预取与 Google 图像缓存分开。我们的测试表明，即使在图像被预取之后，当用户打开电子邮件时，仍会发出单独的 Google 图像缓存请求。

• 如果用户打开了 Gmail 移动应用，即使在关闭移动应用后，预取仍会在短时间内继续发生。

以下是从 Google 预取机器人请求图像时请求标头的示例：

  headers: {
    host: ‘{redacted}.m.pipedream.net’,
    ‘x-amzn-trace-id’: ‘Root={redacted}’,
    ‘accept-language’: ‘en-US’,
    referer: ‘http://mail.google.com/’,
    accept: ‘image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8’,
    from: ”,
    ‘user-agent’: ‘Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.246 Mozilla/5.0’,
    ‘accept-encoding’: ‘gzip, deflate, br’
   },
   body: {},
   inferred_body_type: ‘FORM’,
   method: ‘GET’,
   url: ‘https://{redacted}.m.pipedream.net/header-1641a1.gif’,
   client_ip: ‘66.249.92.1’,
   query: {}

正如 Apple 的邮件隐私保护情况下的情况一样，发件人应谨慎对待所有打开事件。打开只是发件人应该监控和包括在对用户参与度进行判断时需要考虑的众多参与指标之一，通常不是最好的一个。