I have a few email addresses that seem to be bouncing according to
/admin/email/bounced/ but when I check the SparkPost logs, they are listed as delayed (because they are greylisted). Now, from what I understand, as annoying as that delay may be, it does not necessarily mean that the email has definitely bounced. If your mailserver is configured correctly, it will simply retry to deliver after the time indicated by the receiving server and it will then be accepted. I’m assuming that SparkPost is properly configured in that sense so that the emails will eventually be delivered.
So my point here is: if they are eventually delivered (and looking at the SparkPost logs, this seems to be the case - with the exception of one email which ended up being rejected based on system policy) then the bounce notification in Discourse is misleading.
My first thought on this was that discourse should not list delayed emails under bounced because if they are ultimately rejected, there will be another event registering that. However, the problem with that solution is that it assumes that the email provider is actually correctly configured (i.e. re-attempts delivery). If it is not, then the greylisting delay turns into an actual bounce (and according to this page, there are some known non-compliant mail-servers).
So I don’t know whether discourse should care about those false negatives but I guess the better alternative would be that discourse continues to list those delays under bounces but to also provide more information about the nature of the bounce (e.g. in a new column which would state “delay”, or “policy rejection” or whatever). Of course, this boils down to whether this information is actually included in the payload of the email provider’s webhook, but I would find it strange if it wasn’t…