We noticed that Sparkpost logs as "Transient Failure" (code 70) errors such as:
554 5.4.7 [internal] message timeout (exceeded max time, last transfail: 421 4.4.0 [internal] no mail servers for this domain could be reached at this time)
This happens most often for domains without an MX record (usually expired domains being squatted).
When converted to CiviCRM jargon by the Sparkpost extension, this transient error is currently considered an "Away" error, which has a default threshold of 30 bounces before the email is set On Hold. Therefore it would take a long time before CRM users realize that the email is invalid.
This pull-request changes the bounce type to "Relay", which has a default threshold of 3 bounces.
In the spot-checks I did, Sparkpost tried to deliver the email 6 times over 3 days before bouncing it as "Transient Failure". I would be tempted to make it a hard bounce, but that might be a bit too aggressive and would contradict Sparkpost's interpretation of transient.
We noticed that Sparkpost logs as "Transient Failure" (code 70) errors such as:
This happens most often for domains without an MX record (usually expired domains being squatted).
When converted to CiviCRM jargon by the Sparkpost extension, this transient error is currently considered an "Away" error, which has a default threshold of 30 bounces before the email is set On Hold. Therefore it would take a long time before CRM users realize that the email is invalid.
This pull-request changes the bounce type to "Relay", which has a default threshold of 3 bounces.
In the spot-checks I did, Sparkpost tried to deliver the email 6 times over 3 days before bouncing it as "Transient Failure". I would be tempted to make it a hard bounce, but that might be a bit too aggressive and would contradict Sparkpost's interpretation of transient.
For reference, CiviCRM bounce types and thresholds:
https://docs.civicrm.org/sysadmin/en/latest/setup/civimail/inbound/