I’d change one word in that. I’d say the sender has to try all the MX records before it counts as an attempted delivery.
Even with that definition there are some technical details to consider as you rightfully point out in another post. One question I would ask is if one side is IPv4-only and the other side is IPv6-only, then who is responsible for failed delivery?
Nov 13, 2026, 3:21 PM@kasperd @neil Ah, interesting.
So for non-connection definitely has to try all MX.
But if connected to an MX, using that connection to send an email (regardless of response code) should be delivery attempted, IMHO.
A server not available and using next MX is *normal*. A server saying 2xx got it, or even other reject, is acting as the recipient mail server.
As for IPv4/IPv6, I would assume anyone using the current version of IP is not responsible for failure.
An MX can be broken in a way that causes it to respond with a transient error code at some point during the communication. In that case I would only regard delivery as having been attempted once all MX records have been tried.
If any MX responds with successful reply code, then the receiver has assumed responsibility. There is even a statement somewhere in the RFC to that effect.
It’s also possible that communication breaks at some point during the communication after initial connection establishment. That could for example happen due to an MTU problem on the network, or you were just really unlucky and some intermediate router died in the middle of the transaction and there wasn’t any other route to the destination.
When you say “current version of IP” you may have a different definition of what that means than many other people. I am guessing we are in agreement of what it should mean, but convincing the rest of the world is challenging.
Nov 13, 2026, 3:44 PM
Nov 13, 2026, 8:41 PM@revk @kasperd @neil if the receiver accepts the email and the connection ends with both sides sending a FIN, the email has surely unambiguously been delivered. There are some edge cases where the connection may break and you can't be sure it has been delivered, but to my mind that doesn't need to be resolved (legally) since it almost never happens, and if it did happen with something that really needed to be delivered you would just deliver it again (risk a double delivery, but unambiguous)
Absolutely. There is a brief moment while the successful response code at the end of DATA is being transmitted from receiver to sender during which both sides have responsibility for delivering.
Should an interruption happen during that time preventing the sender from receiving and processing the response code, then duplication can happen. And such duplication can be addressed by deduplication on the receiving side. I am not sure if there is any RFC specifying how to do such a deduplication, but the msgid is certainly an important field to take into account when doing deduplication.
That doesn’t answer the question of what time should really count if the exact time of attempted delivery has legal significance.
Nov 13, 2026, 4:17 PM