On 2022-01-29 at 05:26:21 UTC-0500 (Sat, 29 Jan 2022 10:26:21 +0000
(GMT))
Andrew C Aitchison via Exim-users <andrew@???>
is rumored to have said:
> On Fri, 28 Jan 2022, Bill Cole via Exim-users wrote:
>
>> On 2022-01-27 at 14:31:41 UTC-0500 (Thu, 27 Jan 2022 19:31:41 +0000
>> (GMT))
>> Andrew C Aitchison via Exim-users <andrew@???>
>> is rumored to have said:
>>
>>> On Thu, 27 Jan 2022, Marcin Gryszkalis via Exim-users wrote:
>> [...]
>>
>>>> - What do you think about implementing re-folding headers to make
>>>> mail RFC-compliant again (ie. fix what outlook spolied)?
>>>
>>> Unfortunately that can break DKIM signatures.
>>
>> True, but only if the signer is using 'simple' header
>> canonicalization, in which case they surely must expect and so
>> deserve to have their signatures broken.
>>
>> Yes, I'm MOSTLY serious.
>
> Ah.
> Now I have my head around header canonicalization I agree and am
> relieved;
> we don't need to worry too much about breaking DKIM.
>
> Would we need a setting to say whether to break or reject messages
> with simple header canonicalization and long headers, or is it clear
> which we should do ?
I think the correct approach is to go ahead and fold the header, maybe
add a header noting that 'break' (like Sendmail's X-Autoconverted
header) and expose the fact that DKIM is generally a garbage mechanism.
Rejecting mail simply because it has a bad DKIM signature or an overlong
line is a great way to reject otherwise legitimate mail in a
semi-chaotic pattern.
IMHO, DKIM canonicalizations are primary evidence of the standard being
mis-designed; "simple" is positively ridiculous for mail moving outside
of unified administrative realms (where DKIM serves what purpose?) and
'relaxed' is inadequate to its supposed purpose. It feels like DKIM was
devised by people who didn't actually work with real-world mail systems.
At all. It seems to me that DKIM needs *at least* a new default
canonicalization defined, and the existing canonicalizations should be
deprecated.
--
Bill Cole
bill@??? or billcole@???
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
