Login
You're viewing the functional.cafe public feed.
  • RevK :verified_r:revk@toot.me.uk
    Nov 13, 2026, 2:05 PM

    @neil On a serious note, and from a technical viewpoint, which I think makes sense.

    With old fashioned post we had a postmark.

    With email servers we have mail server logs.

    Personally I would consider someone has attempted delivery of an email as soon last their (or their agent/ISP) has attempted delivery to any of the MX records of the recipients domain. A delay from that point should not be on the sender (unless someone can prove the sender's connectivity was at fault).

    ...

    💬 2🔄 0⭐ 0

Replies

  • RevK :verified_r:revk@toot.me.uk
    Nov 13, 2026, 2:07 PM

    @neil I'd then say if the email was delivered, i.e. a 2xx response from one of the recipient's domain's MX record, then it has in fact been delivered.

    Getting it reliably from that point to the attention of an actual person or process is the recipients responsibility.

    There is always a technical grey area catch on such things but that is a massive edge case. Far more likely email logs shows delivery attempt (and non delivery response) or delivery response.

    But the border is the recipient MX.

    💬 3🔄 1⭐ 5
  • Mike Coxmikecox@mastodon.iow.social
    Nov 13, 2026, 2:09 PM

    @revk @neil To me it's like when people say that they didn't receive my email because it went in their spam. Well that's their problem, not mine. It was sent to them and received

    💬 1🔄 1⭐ 1
  • RevK :verified_r:revk@toot.me.uk
    Nov 13, 2026, 2:16 PM

    @mikecox @neil Indeed, I have likened it to an office that throws out any post that comes in pink envelopes. Clearly if I sent it and it arrived even in a pink envelope, I have done my bit.

    I'd also be replying "thank you for confirming you did in fact RECEIVE my email within the required time frame (even if you chose to file it as spam), I have saved your confirmation for future reference".

    💬 0🔄 1⭐ 3
  • Andrew Hodgsonandrew@hodgson.io
    Nov 13, 2026, 2:29 PM

    @revk @neil Interestingly that puts people who use intermediary services like Mimecast at a disadvantage compared to those who just publish the M365 MX records. The company I work for is in this situation, with the mail then backing up at Mimecast. The tests I sent this morning seem to indicate that MS are responding with 4XX temp failure codes on the SMTP level.

    💬 1🔄 0⭐ 2
  • penguin42penguin42@mastodon.org.uk
    Nov 13, 2026, 2:33 PM

    @andrew @revk @neil It's not that unusual to how some big financial companies handle mail - many use a physical mail processing company to receive the mail and I guess scan and forward it electronically. It's fairly easy to spot when you notice the postcode for big companies is all neighbouring ones in the same town where the company isn't.

    💬 1🔄 0⭐ 1
  • RevK :verified_r:revk@toot.me.uk
    Nov 13, 2026, 2:51 PM

    @penguin42 @andrew @neil I would not say a disadvantage but a clear demarkation of responsibility.

    If you contract with someone to handle your email sending (e.g. ISP) the demarkation is when they send it on to the MX of the recipient. You chose to contract out your sending.

    But if someone contracts out their receiving, which, as you say, happens, the recipient is taking responsibility as they are the ones that contacted that out.

    You need a line, and handed to an MX for domain is a good one

    💬 1🔄 0⭐ 2
  • RevK :verified_r:revk@toot.me.uk
    Nov 13, 2026, 2:56 PM

    @penguin42 @andrew @neil My key issue here is that there should be a specific point that sender hands over responsibility to recipient.

    Up to then, any failure is the sender's fault.

    Beyond that is the recipient's fault.

    Contracting someone else for each side does not change that reality.

    As I say, there is always some technical edge cases on that specific SMTP connection, which is unavoidable but really not going to happen in most cases.

    This also fixes the date/time.

    💬 1🔄 0⭐ 2
  • 💬 3🔄 0⭐ 1
  • penguin42penguin42@mastodon.org.uk
    Nov 13, 2026, 3:03 PM

    @revk @andrew @neil Well you can get 'proof of posting' at a post-office; and often you're told to use tracked/signed-for - so there's some requirement on the sender to do something in the face of a delivery system that's known to be flaky.

    (which in the case of mail handling companies is useless - you get a delivery picture of a huge box sitting on a table without your letter visible)

    💬 1🔄 0⭐ 1
  • RevK :verified_r:revk@toot.me.uk
    Nov 13, 2026, 3:05 PM

    @penguin42 @andrew @neil Ha, yeah, but for some legal things a "proof of posting" is all you need. My suggestion on MX of recipient domain is actually a tad further down the line, but also allows for people sending email themselves not using an ISP.

    I have had such a picture (to amazon) and sued RM (who caved) on basis proof of delivery picture did not show *my* package (distinctive colour even).

    💬 0🔄 0⭐ 1
  • Danieldan@axillae.telent.net
    Nov 13, 2026, 3:06 PM

    @revk @penguin42 @andrew @neil iirc with Royal Mail there is (in the context of legal notices) a presumption of delivery - if you can prove postage then it's on the other party to prove that it wasn't delivered. I don't know if there's anything analogous in email

    💬 1🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • The Penguin of Eviletchedpixels@mastodon.social
    Nov 13, 2026, 3:18 PM

    @revk @penguin42 @andrew @neil No the postal service is special here

    You have an interest in proving and email was or was not delivered. You can tamper with or lose your server logs. Stuff can get lost. SMTP is not reliable

    The post office is notionally an uninterested third party with a process in place to manage high reliability document delivery and recognized as such.

    The analogy would be not using email but both using an agreed reliable third party provider of electronic document service

    💬 3🔄 0⭐ 3
  • Ben Hardillben@hardill.me.uk
    Nov 13, 2026, 3:21 PM

    @etchedpixels @revk @penguin42 @andrew @neil

    While technically true, recent event have seen 1st class mail here be delivered in the 3rd week after it was posted and the new barcodes on the side of stamps mean they are not franked with the posing date (I assume the PO can look up in DB the day/time it was scanned, but it's harder to verify)

    💬 0🔄 0⭐ 0
  • 💬 1🔄 0⭐ 1
  • 💬 1🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • datenwolfdatenwolf@chaos.social
    Nov 13, 2026, 2:30 PM

    @revk @neil

    This is but one reason, why I have my MXs configured in a way, that filtering unwanted mail happens as part of the delivery process, so that in the case it's identified as unwanted, the delivery process itself will abort with a rejecting error.

    It also allows me to tell-off people who suggest "I should look into my spam folder…"

    Sorry mate… doesn't work like that with my mail server.

    💬 1🔄 0⭐ 3
  • RevK :verified_r:revk@toot.me.uk
    Nov 13, 2026, 2:53 PM

    @datenwolf @neil That creates an interesting point.

    I agree, best place for it.

    But it means you have a case of "sender attempted to delivery and you refused delivery", which I imagine in some legal senses means sender did what was required and it was your choice to refuse.

    Where as a spam folder is "sender actually did deliver", which I would assume has even more legal leverage, as sender would not know delivery was ignored.

    💬 0🔄 0⭐ 0
  • kasperdkasperd@westergaard.social
    Nov 13, 2026, 3:18 PM

    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?

    💬 1🔄 0⭐ 0
  • RevK :verified_r:revk@toot.me.uk
    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.

    💬 1🔄 0⭐ 0
  • kasperdkasperd@westergaard.social
    Nov 13, 2026, 3:35 PM

    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.

    💬 1🔄 0⭐ 0
  • RevK :verified_r:revk@toot.me.uk
    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
  • Steve Hill 🏴󠁧󠁢󠁷󠁬󠁳󠁿🇪🇺steve@mastodon.nexusuk.org
    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
  • kasperdkasperd@westergaard.social
    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
  • RevK :verified_r:revk@toot.me.uk
    Nov 13, 2026, 4:17 PM

    @kasperd @neil We in to very much edge cases.

    Though “current version of IP” is not a "different definition of what that means than many other people". There is one definition of that as per RFCs that define IP.

    💬 0🔄 0⭐ 0