Catching this event as a bounce leads quite often to false bounces, like
in the cases the error is due to our own instance SMTP errors. Errors
like a too large message should no bounce a thread's recipients as the
problem isn't in the recipients side but ours.
We leave anyway some true positives aside (like in the case of malformed
email addresses). We should be able to detect and fix those anyway.
- Partner get bounced when his associated email is in a hard bounced
tracking. It didn't matter if the hard bounce event was solved in that
recipient later and leaded to an increasing number of false positives.
- We also use the email_bounced_set() method to get the whole bounce
info in case positive.
On our server,
queries based on "mail_tracking_event"."tracking_email_id" improved from 501,924 ms to 1,840 ms
queries based on "mail_tracking_email"."mail_message_id" improved from 167,436 ms to 3,223 ms
The last ones are run several times when a thread has many messages