Login
You're viewing the functional.cafe public feed.
  • Nov 13, 2026, 3:44 PM

    @kasperd @neil The failures at the packet level can never be fully resolved sadly - that is the edge case I mention.

    Basically attempts to deliver to MX as per RFC.

    💬 1🔄 0⭐ 0

Replies

  • 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)

    💬 1🔄 0⭐ 0
  • Nov 13, 2026, 9:47 PM

    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.

    💬 0🔄 0⭐ 0