Comment by flowerthoughts
Comment by flowerthoughts 6 hours ago
I also don't see why the DMARC reporting would retry sending. If the receiver isn't receiving right away, surely it's okay to just drop that report to keep the queue small.
Comment by flowerthoughts 6 hours ago
I also don't see why the DMARC reporting would retry sending. If the receiver isn't receiving right away, surely it's okay to just drop that report to keep the queue small.
> retried 1/2/4/8 Minuten apart
That's generally not very clever, as it will impose an unneeded burden on a receiving server which actually has temporary resource problems, and it will collide with greylisting, for example.
RFC 5321 states in section "4.5.4.1. Sending Strategy" that the retry interval should be at least 30 minutes, while the give-up time needs to be at least 4–5 days:
> the retry interval should be at least 30 minutes, while the give-up time needs to be at least 4–5 days
RFCs have very little to do anymore with the realities of email delivery. And advocating for password reset emails to only be retried after 30 minutes (all while the user is manically mashing the 'resend link' button) and/or to be kept around for 5 days (while the link contained therein expires after an hour) doesn't either.
SHOULD is not MUST. These capitalized terms are have very specific meanings in RFCs, see RFC https://datatracker.ietf.org/doc/html/rfc2119. SHOULD is:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
MUST is a requirement. You left out the "however" part:
In general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the SMTP client can determine the reason for non-delivery.
There's absolutely nothing wrong with a fine tuned backoff. I am not saying the specific backoff discussed by GP is best, merely that 30 minutes is absolutely not a requirement, and in fact, discussed in tandem with the fact that "more sophisticated strategies" are actually beneficial.
The RFC does not agree with you. Partially quoted as you have, does not help.
We already had 'low effort' mail queues (for things like password reset emails: these are retried 1/2/4/8 minutes apart and don't generate bounces, other than an API flag and a metrics record), to which we added 'least effort' for DMARC reports. Retry once, then forget about the entire thing other than incrementing a counter for the destination domain.