如上所述，Gmail预取仅在有限的情况下发生。其他邮件客户端不会发生预取。相反，这种行为特定于Gmail用户在其网页浏览器中打开Gmail应用程序或积极使用移动应用程序时。 我们最好的猜测是这是在将电子邮件显示给用户之前进行的安全扫描。这种预取行为也突显了为什么邮件文件大小优化对于更快加载和更好的用户体验很重要。

图像请求的完整请求标头如下详细说明。您会注意到以下几点：

• 引用地址设置为http://mail.google.com。有趣的是，即使用户使用的是https://，Gmail在发出请求时仍然将引用地址设置为http://协议。 

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

• 与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的邮件隐私保护一样，发送者应谨慎对待所有打开事件。专注于整体电子邮件质量，包括防止电子邮件地址输入错误，并保持干净的列表以获得更好的可送达性指标。打开只是众多参与指标之一，通常不是最好之一，发送者在进行用户参与决定时应监测并包括这些指标。