我在这里阅读了一些有关电子邮件客户端预取电子邮件中URL的问题。解决方法似乎是添加一个新的确认页面，用户必须在其中单击按钮以确认所需的操作。
但是，this答案指出以下内容：
截至2017年2月，Outlook（https://outlook.live.com/）扫描电子邮件到达您的收件箱，它将所有找到的URL发送到Bing，以便由Bing搜寻器索引。
这有效地使所有一次性使用链接如登录/通过重置/等无用。
（我的服务用户抱怨一次性登录链接不正确为其中一些工作，似乎BingPreview / 1.0b正在用户甚至打开收件箱之前的URL）
Drupal似乎遇到了相同的问题：https://www.drupal.org/node/2828034
我主要关注的是此声明：
截至2017年2月，Outlook（https://outlook.live.com/）扫描电子邮件到达您的收件箱，它将所有找到的URL发送到Bing，以便由Bing搜寻器索引。
[在这种情况下，电子邮件中的任何URL都用于确认操作，例如确认登录，订阅或取消订阅后，可能会在搜索引擎中被搜索到，前提是上面引文中的indexed意味着什么。在这种情况下，是Bing。甚至用户确认所需动作的专用确认页面也无法真正缓解此问题。
如果我通过电子邮件向用户发送在URL中带有一次性令牌的登录链接，则该URL将以Bing结尾。该令牌的寿命很短，可以说是5分钟，所以我怀疑有人会设法在Bing上搜索并在用户单击该URL或URL过期之前找到该URL。
用户会收到一封带有链接的电子邮件，以确认订阅。该链接可能在24小时内有效。这可能足以让其他人迷失在搜索引擎上的链接，并偶然（或故意）代表用户确认订阅。
场景2并不少见，据我所知，甚至最好使用双重选择加入。
取消订阅新闻通讯底部的URL。也许永远有效？您不希望在搜索引擎中公开搜索此内容。
假定所有一次性确认链接都落在用户确认所需动作的确认页面上。
确实是由搜索引擎（至少是必应）为电子邮件中的URL编制索引的问题吗？他们最终会公开搜索吗？如果不是，那么上面引用中的indexed是什么意思？
为了完整起见，我补充说我自己在使用网络时不会对此有很多问题，所以我的直觉是这种情况不太可能。
确实是由搜索引擎（至少是必应）为电子邮件中的URL编制索引的问题吗？
我不能肯定地说是否对它们进行了索引，只有Bing可以回答这个问题，但是至少通过一个简单的GET请求，它们肯定会被访问。我刚刚进行了测试，向自己发送了指向我网站上一个页面的链接，该链接记录了针对它的请求，确实，我看到一个来自207.46.13.181的GET（反向DNS表示msnbot-207-46-13-181.search.msn.com），这表明一个search.msn.com中的自动程序正在抓取链接。这使我相信，是的，他们正设法以某种方式索引链接的内容，但这只是我的意见。
它们实际上最终会被公开搜索吗？如果不是，那么上面引用中的“索引”是什么意思？
同样，除非您为Bing工作，否则无法说。在任何情况下，“索引编制”都完全符合您的想法：解析页面的内容以可能将其包含在搜索结果中。
这里的真正问题是：这是否以某种方式表示安全问题，或者是否会损害我网站的功能？
它肯定有潜力：如果您的确认/重置/订阅/任何过程仅依靠具有适当GET参数的单个GET请求，那么您肯定应该重新访问该策略，因为它显然允许任何人执行操作（甚至恶意地举报GET参数的可能ID）。
如果您尝试发送的链接包含明智的信息，或者可用于更改网站用户的重要数据，那么您至少应将其放在仅允许感兴趣的用户访问的登录页面后面。这样，想要访问它的任何人（包括搜索引擎）都将被重定向到登录页面（如果尚未登录）。
[如果您尝试发送的链接只是某种无害的确认链接（例如，从新闻通讯订阅/退订），则至少使用网页内的表格通过POST请求进行实际确认（可能也使用CSRF令牌），否则您肯定会以假阳性结果结束。