I came across a device that sends automated mails via Exim, and that device’s developers (Axis) made it such that when certain mails are sent, it creates Date headers in a completely invalid format (apparently they invented their own format, instead of reading the standard in RFC5322). The incorrect format looks like this:
Date: Sun Aug 3 06:00:00 2025 +0200
rather than something like the following, which would be standards-compliant:
Date: Sun, 3 Aug 2025 06:00:00 +0200
This causes incorrect sorting in some mail clients (notably in Thunderbird mobile) but unfortunately, the device is sufficiently old that this is not likely to get fixed, so I decided to fix it at the server level on the Exim server, through which mails are sent. I added the below to the DATA ACL used for mail submission, and it seems to do the trick:
warn log_message = Rewriting incorrect Date header
condition = ${if match{$h_Date:}{^\w{3} \w{3}}}
remove_header = Date
add_header = Date: $tod_full
(We can probably all agree that, if the mail standard was being written from scratch again today, that neither of the above date formats would be chosen as the ideal one to be standardised…)
Tags: exim