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…
Greylisted e-mails aren’t bounced. They’re delayed. If Sparkpost is incorrectly reporting delayed e-mails as bounced, that’s a problem for them. If Discourse misinterpreting a delayed e-mail notification from Sparkpost as a bounce, that’s a problem for us (PR welcome!) If Sparkpost isn’t reporting the final delivery failure as a bounce, that’s a problem for them.
On the sparkpost website they’re listed under “Delayed”. I have now excluded delayed messages from the webhook and will monitor if those still show up in discourse. If not, it probably means that they are correctly reported by sparkpost but treated as bounced by discourse.
What would be the expected behaviour when discourse receives “delayed” events? Is it supposed to ignore them or list them separately or what?
OK, since I took delayed messages entirely out of the sparkpost webhook, they are no longer showing under “bounces” on discourse.
So that is currently the only way to prevent them from showing up. In other words, discourse is not ignoring notifications about delayed messages but interpreting them as bounces.
That’s not great. A PR to ignore delay notifications, or at least a bug report clearly showing what a delay notification from sparkpost looks like, would be appreciated.