Who really cares what it was designed to do? The fact is, almost the entire userbase is going to receive that email before they can switch tabs to their email inbox. So even though it wasn't designed to be immediate, it is in practice, and we have a whole list of technologies that we use despite intent (HTTP wasn't designed to be stateful, and yet we use it as such constantly).
Mail transmitting is only sometimes encrypted, which is disappointing, but I've yet to hear of an instance where a user account was compromised when the forgotten password link was hijacked by listening to the wire between two mail servers. If it really is a problem, this could also be mitigated easily by only allowing the link to work on the browser that initiated the request.
Frankly, though, I'd love it if this system were implemented if for no other reason than to encourage mail servers to enable TLS on their SMTP backend.
> So even though it wasn't designed to be immediate, it is in practice,
But that's by accident, not really by design, and because email isn't supposed to be immediate, and is often outside the user's control, there are very many things that can delay it.
Mail transmitting is only sometimes encrypted, which is disappointing, but I've yet to hear of an instance where a user account was compromised when the forgotten password link was hijacked by listening to the wire between two mail servers. If it really is a problem, this could also be mitigated easily by only allowing the link to work on the browser that initiated the request.
Frankly, though, I'd love it if this system were implemented if for no other reason than to encourage mail servers to enable TLS on their SMTP backend.