I've seen the same issue. The links in emails opened in outlook seem to be crawled immediately by the 'BingPreview' bot.

Especially users working with Microsoft Office 365 and therefore Outlook noticed very often that login is not possible. Upon closer analysis, it was found that the MS/Bing crawlers are particularly persistent and repeatedly call the reset links, regardless of server configuration or the like. For this reason, a text field was implemented in the backend via the Drupal State API, in which selected user agents (always one per line) can be entered. These are checked by 'Shy One Time', in case of a hit a redirect to the LogIn form with a 302 status code occurs, the reset link is not invalidated.

Another suggestion some senders are trying is to set up a “stealth” link, that human readers won’t see or click on but that parsing software might. Clicks on that link are a sign that the click was not done by the recipient.

This behaviour may affect one-click unsubscribe links. If clicking the link in an email automatically processes the unsubscribe, then Barracuda may unsubscribe users without their knowledge.

This behaviour may affect opt-in confirmation links.

I’ve implemented a form on the landings page that auto-submits (on DOMContentLoaded) and posts the token to the next page. Passwordless login is now working for my client despite their mail scanner.

In June 2021 I can confirm Microsoft seem to be running a product that completes client side activities, like automatically submitting a form. I guess they are running a headless browser to do the scanning.

When fetch runs on the server, the resulting response will be serialized and inlined into the rendered HTML. This allows the subsequent client-side load to access identical data immediately without an additional network request.

For dynamic routes, such as our src/routes/blog/[slug].svelte example, that's not enough. In order to render the blog post, we need to fetch the data for it, and we can't do that until we know what slug is. In the worst case, that could cause lag as the browser waits for the data to come back from the server. We can mitigate that by prefetching the data. Adding a sveltekit:prefetch attribute to a link... <a sveltekit:prefetch href="blog/what-is-sveltekit">What is SvelteKit?</a> ...will cause SvelteKit to run the page's load function as soon as the user hovers over the link (on a desktop) or touches it (on mobile), rather than waiting for the click event to trigger navigation. Typically, this buys us an extra couple of hundred milliseconds, which is the difference between a user interface that feels laggy, and one that feels snappy.