How is preventing delivery of legitimate email due to the sender's software being misconfigured "good for you"?
Also, RFC 5321 [0] says:
> SMTP clients that [...] do not maintain queues for retrying message transmissions that initially cannot be completed, may otherwise conform to this specification but are not considered fully-capable.
> In many situations and configurations, the less- capable clients discussed above SHOULD be using the message submission protocol (RFC 4409) rather than SMTP.
In my 19 years of greylisting, I have yet to have legitimate email fail due to it. And it was one of the easiest ways to significantly decrease the amount of spam. It's been worth it in my opinion.
You may have not realised that legitimate email has failed (and it might even be true) but my experience suggests it's unlikely that it hasn't happened. I only have a handful of users, but when I was greylisting I'd get reports of missing mail at least annually.
Which isn't to say it's not worth it, although nowadays I'd recommend that https://www.postfix.org/POSTSCREEN_README.html pre-greet checks are just as good at stopping spam and better at not blocking legit mail.
Greylistibg is very effective in my experience, but there are definitely some confirm your email loops that won’t work without whitelisting. It’s a combination of multiple ip addresses and retry times greater than the life of the code.
In greylisting the 451 is sent from the recipient's SMTP sender to the sender's SMTP server. The client software is irrelevant. They have bigger problems if their server doesn't implement a retry queue.
Also, RFC 5321 [0] says:
> SMTP clients that [...] do not maintain queues for retrying message transmissions that initially cannot be completed, may otherwise conform to this specification but are not considered fully-capable.
> In many situations and configurations, the less- capable clients discussed above SHOULD be using the message submission protocol (RFC 4409) rather than SMTP.
[0] https://www.rfc-editor.org/rfc/rfc5321