> * the delay makes 2FA super frustrating I think you misunderstand. If I'm expecting to log in via 2FA with my email client, I'll have my email client open (

> * the delay makes 2FA super frustrating I think you misunderstand. If I'm expecting to log in via 2FA with my email client, I'll have my email client open (and polling for email in IM2K, or in an SMTP-world, my MX points directly at my email client) so the message won't be delayed if I'm expecting it. I think it's okay to delay unsolicited mail, after all, I have to sleep some time... > * a number of the larger services have pools of mailservers; when they retry the send, they retry from a different random host in the pool. Naturally this breaks greylisting completely. I don't think this is true; Can you explain a little why you think this is a problem? Back in the late 1990s and early 2000s I ran a large mail server (queue on NFS) and had this problem, and I solved it by hashing the authenticated sender and using that to choose the pool of addresses to try for that week. This way, a bad actor might burn 3-4 IP addresses by spamming and get me added to one of the popular blacklists, but they don't take out my entire system, and that gave me time to correct the problem. When Greylisting started becoming popular, I had some slightly longer delays than the more popular single-node mail servers out there, but I tweaked this to simply prefer the same address until seeing some headers then retry on the alternate to see if we get a different answer. Now it's 2022, and I suspect any big mail server knows these tricks and more, and any operator who doesn't know about greylisting in 2022 is going to have other problems.