Nov 13, 2026, 11:50 AMWell, today I am pondering contract clauses about giving notice via email.
- Nov 13, 2026, 11:50 AM
Replies
Stewart Tolhurstfoxbasealpha@tech.lgbtNov 13, 2026, 11:52 AM@neil Bring back the fax!
oisinoisin@mastodon.ieNov 13, 2026, 11:54 AM@neil I am pondering if my tax items will reach the accountant in time for deadline 😬
- Nov 13, 2026, 11:57 AM
@oisin Good luck!
Glen Tglent@aus.socialNov 13, 2026, 11:58 AM@neil Ohhhh. What an excellent thought. Especially the general rule that a phsyical mail's date is the date it is sent. So if your email is sitting in the outbound queue at Fastmail, you've still given notice.
Nov 13, 2026, 12:03 PM@neil Your contract will autorenew indefinitely unless you give notice through a service that isn't working?
HighlandLawyerHighlandLawyer@mastodon.socialNov 13, 2026, 12:15 PM@neil
AFAIK there is still no unified e-postal rule. For example the Act of Sederunt (Electronic Signature and Electronic Transmission of Documents) 2025 allows court documents to go to parties by email, but lacks any provision for determining when such delivery is deemed to have occurred.
Ed DaviesedaviesNov 13, 2026, 12:46 PM@HighlandLawyer @neil There was that instance [¹] where somebody's objection to a planning application wasn't taken into account by the planners because it was rejected by the council's spam filters because it contained the word “erection”.
So the mail was delivered to the recipients (the council) but they chose (by using a spam filter) to not read it. So who takes liability for the spam filter?
[¹] I was going to write “case” there but I don't think it went to court so that might have mislead.
- HighlandLawyerHighlandLawyer@mastodon.socialNov 13, 2026, 4:01 PM
@edavies @neil
There's a whole line of historical development of rules when intimation is effective.
Way back it was when someone became aware of it.
But it was too easy to say "I never saw/heard it", so you got personal service by an official giving it to you, or leaving it at your home.
Then the universal postal service was created, with regular & effective deliveries, so rules were created based on the expectation of such ("postal rule").
Now we're going through it again with e-delivery. 
chrisgerhardchrisgerhard@mastodon.greenNov 13, 2026, 12:19 PM@neil given email is not, and has never been guaranteed to deliver and has no way of determining that the mail has arrived, that seems impossible.
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).
...
- 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.
Mike Coxmikecox@mastodon.iow.socialNov 13, 2026, 2:09 PM- 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".
Andrew Hodgsonandrew@hodgson.ioNov 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.
penguin42penguin42@mastodon.org.ukNov 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.
- 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
- 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.
- Nov 13, 2026, 3:00 PM
@penguin42 @andrew @neil This is not unlike postal service.
I suspect the demarcation is putting the letter in the post box. The timestamp is the postmark (when they existed).
- penguin42penguin42@mastodon.org.ukNov 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)
- 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).
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
- Nov 13, 2026, 3:18 PM
@dan @penguin42 @andrew @neil I think the discussion here is maybe we can establish some similar ground rules for email.
The Penguin of Eviletchedpixels@mastodon.socialNov 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
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)
- Nov 13, 2026, 3:23 PM
@etchedpixels @penguin42 @andrew @neil SO by that logic, contracting sending to an uninterested 3rd party ISP who can provide email logs of attempted or actual delivery, creates the same logic.
- Andrew Hodgsonandrew@hodgson.ioNov 13, 2026, 4:26 PM
@revk @etchedpixels @penguin42 @neil I struggle to see how you can do this via email to be honest. In most cases especially with the third party companies involved these days there are too many points of failures and wiggle room.
- Nov 13, 2026, 8:06 PM
@andrew @etchedpixels @penguin42 @neil there are surely parties contracted by sender and parties contracted by recipient?
- Nov 13, 2026, 6:48 PM
@etchedpixels @revk @penguin42 @andrew @neil presenting tampered logs in court would, of course, be contempt, so would be quite a risk
datenwolfdatenwolf@chaos.socialNov 13, 2026, 2:30 PMThis 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.
- 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.
kasperdkasperd@westergaard.socialNov 13, 2026, 3:18 PMI’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.
- kasperdkasperd@westergaard.socialNov 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.
- 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)
- kasperdkasperd@westergaard.socialNov 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.
- Nov 13, 2026, 4:17 PM
- The Penguin of Eviletchedpixels@mastodon.socialNov 13, 2026, 3:14 PM
@neil Ah the two generals problem. One of those joyous "you can't win" moments.
I would never accept notification by email for anything important. Notice can be given by email but shall not be considered received unless a message from the recipient confirming it has been received, and proper special postal notification as a backup maybe.
IMHO it's fine to agree to do stuff via email as convenience but nobody should deem it remotely reliable.