3 ms·
You make that sound like a negative. I run my own email server and have implemented greylisting [1]. Greylisting easily drops my incoming email by 50%, but th
by spc476 5y ago
You make that sound like a negative.
I run my own email server and have implemented greylisting [1]. Greylisting easily drops my incoming email by 50%, but that 50% was being sent by non-compliant SMTP "servers" (probably, a program running on an exploited box somewhere to spam email). Legitimate email servers will always queue email and try again when they encounter a transitory error.
[1] https://en.wikipedia.org/wiki/Greylisting_(email) https://en.wikipedia.org/wiki/Greylisting_(email)
- rascul 5y agoGreylisting is good stuff. I have found similar results.
- cm2187 5y agoUntil we need mail for 2FA, then it becomes an unworkable pain in the arse.
- tsukikage 5y ago* the delay makes 2FA super frustrating * 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.
- yrro 5y agoYou don't have to use the full IP address of the relating party when matching greylist entries. Even just ignoring it, and greylisting solely on (sender, recipient) is better than nothing... especially if you're already enforcing based on the sender's SPF record.
- geocar 5y ago> * 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.
- spc476 5y ago2FA has never been an issue with me. If it's a one-time thing (like signing up for a website) the wait doesn't bother me, and no services have ever rejected me because I didn't respond within five minutes. If it's a recurring thing, I can always whitelist the domain, the IP, the sender, or all three. Even the senders with pools of mail servers hasn't been an issue---the email will eventually get through. As far as I can tell, in the fifteen years I've been using greylisting, that has just not been an issue. When I first started with greylisting, I set the embargo time (minimum time to reject emails) to an hour. I later dropped it down to 25 minutes, but that's just me being a bit over-cautious. Just a one-time temporary reject is enough to filter out something like 80% of what I catch with 25 minutes.