5 ms·

This sounds like a nightmare, mostly because the implication is that refreshing my inbox would amount to pulling emails from thousands of 3rd party servers, any

by lukevp 5y ago

This sounds like a nightmare, mostly because the implication is that refreshing my inbox would amount to pulling emails from thousands of 3rd party servers, any one or more of which may be down at any given time.

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 ago
  Greylisting is good stuff. I have found similar results.
  - cm2187 5y ago
    Until 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 ago
    You 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 ago
    2FA 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.
markstos 5y ago
Odds are more likely that you have less than 100 messages waiting and more than 80 of them are stored on major, reliable hosts like Gmail, Amazon and Microsoft.
ttyprintk 5y ago
Well, maybe your preference is not to leak your confirmation time. In which case, you’d set up a background process to automatically retrieve and store. This is congruent to the traffic shape today. And it wouldn’t be bad if store-and-forward catches on, because it relieves the storage pressure for big, free services, which would be the largest burden attempting free, anonymized messaging at scale.

by lukevp 5y ago

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 ago
Greylisting is good stuff. I have found similar results.
- cm2187 5y ago
  Until 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 ago
  You 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 ago
  2FA 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.

markstos 5y ago

Odds are more likely that you have less than 100 messages waiting and more than 80 of them are stored on major, reliable hosts like Gmail, Amazon and Microsoft.

ttyprintk 5y ago

Well, maybe your preference is not to leak your confirmation time. In which case, you’d set up a background process to automatically retrieve and store. This is congruent to the traffic shape today. And it wouldn’t be bad if store-and-forward catches on, because it relieves the storage pressure for big, free services, which would be the largest burden attempting free, anonymized messaging at scale.