4 ms·

> 1. Email delivery latency This is particularly true when the recipient has enabled Greylisting[0] and delivery has to be attempted multiple times (which is p

> 1. Email delivery latency This is particularly true when the recipient has enabled Greylisting[0] and delivery has to be attempted multiple times (which is perfectly fine from the point of view of the RFC standards). In view of this, email delivery rather resembles real-world postal package delivery (and not so much the instantaneous delivery of, say, phone calls). [0] https://en.wikipedia.org/wiki/Greylisting_(email) https://en.wikipedia.org/wiki/Greylisting_(email)

ytch 6y ago
Is it possible to solve by some kinds of warming up? AFAIK greylist is IP-based. We can send email at regular time so all the sender IP can keep in list. But email does has many uncertainty like spam detection and others to slow the process after SMTP server receive it.
- jethro_tell 6y ago
  How would that work? Send an email to every customer (domain, so pick a single customer at every domain) and send them an email with a fake login, or a note that says please disregard? Aside from that being spam, it's also likely to get legit emails stuck in spam filters as people start marking them as spam. Secondly, I think most of the largest providers don't really grey list any longer. They seem to have moved to inbound throttling. So your first email goes through but then if you send a rash of mail, you end up seeing the throttle on the back side.
  - ytch 6y ago
    > Send an email to every customer (domain, so pick a single customer at every domain) Greylist is allow/block based on sender IP, not receiving metadata, so I guess pre-send mail from the IP might help, but yes, other rules might slow down.
    - jethro_tell 6y ago
      It's not just connect based, you have to connect and send an email. Which would be spam. Most systems I've worked on score based on how much your server looks like it's doing its job and moving on. Long connection with inactivity get tagged, scored and disconnected. Connecting without sending an email leaves you in the grey list queue. There is to my knowledge not a great way to pre-warm for grey-listing
iggldiggl 6y ago
This can be particularly fun if the sender uses Amazon SES for example, because Amazon randomly rotates through its mail servers on each retry attempt, so a simple greylisting implementation (based on exactly matching the full IP) delays the mail by not just one, but possibly multiple retry intervals until by chance Amazon happens to use to original server again. So you either need to whitelist Amazon SES (and possibly a few other providers behaving similarly), or use a greylisting implementation which doesn't match the full IP (I think Mailcow by default e.g. uses /19 for matching IPv4 addresses). A previous mail hoster of mine did the former, i.e. Greylisting based on the full IP, and what was even worse, their support staff totally denied any knowledge of it and tried to claim it wasn't their fault that any e-mails from Amazon (Amazon itself and anything using SES) would arrive with random amounts of large delay.

ytch 6y ago

Is it possible to solve by some kinds of warming up? AFAIK greylist is IP-based. We can send email at regular time so all the sender IP can keep in list. But email does has many uncertainty like spam detection and others to slow the process after SMTP server receive it.

jethro_tell 6y ago
How would that work? Send an email to every customer (domain, so pick a single customer at every domain) and send them an email with a fake login, or a note that says please disregard? Aside from that being spam, it's also likely to get legit emails stuck in spam filters as people start marking them as spam. Secondly, I think most of the largest providers don't really grey list any longer. They seem to have moved to inbound throttling. So your first email goes through but then if you send a rash of mail, you end up seeing the throttle on the back side.
- ytch 6y ago
  > Send an email to every customer (domain, so pick a single customer at every domain) Greylist is allow/block based on sender IP, not receiving metadata, so I guess pre-send mail from the IP might help, but yes, other rules might slow down.
  - jethro_tell 6y ago
    It's not just connect based, you have to connect and send an email. Which would be spam. Most systems I've worked on score based on how much your server looks like it's doing its job and moving on. Long connection with inactivity get tagged, scored and disconnected. Connecting without sending an email leaves you in the grey list queue. There is to my knowledge not a great way to pre-warm for grey-listing

iggldiggl 6y ago

This can be particularly fun if the sender uses Amazon SES for example, because Amazon randomly rotates through its mail servers on each retry attempt, so a simple greylisting implementation (based on exactly matching the full IP) delays the mail by not just one, but possibly multiple retry intervals until by chance Amazon happens to use to original server again. So you either need to whitelist Amazon SES (and possibly a few other providers behaving similarly), or use a greylisting implementation which doesn't match the full IP (I think Mailcow by default e.g. uses /19 for matching IPv4 addresses). A previous mail hoster of mine did the former, i.e. Greylisting based on the full IP, and what was even worse, their support staff totally denied any knowledge of it and tried to claim it wasn't their fault that any e-mails from Amazon (Amazon itself and anything using SES) would arrive with random amounts of large delay.