OT: DKIM signatures on email messages from lists.gnupg.org

[Alessandro Vesely]

On Tue 13/Jun/2023 13:02:09 +0200 Alexander Leidinger via Gnupg-users wrote:
> Quoting Alessandro Vesely <vesely at tana.it> (from Tue, 13 Jun 2023 11:19:02 +0200):
>> On Tue 13/Jun/2023 08:46:06 +0200 Alexander Leidinger via Gnupg-users wrote:
>>> Quoting Alessandro Vesely via Gnupg-users <gnupg-users at gnupg.org> (from Mon, 
>>> 12 Jun 2023 18:45:37 +0200):
>>>
>>>>> The From was re-written be the list and as such the header check fails. 
>>>>> The body check fails as the list adds the following:
>>>>>
>>>>> ---snip---
>>>>> _______________________________________________
>>>>> Gnupg-users mailing list
>>>>> Gnupg-users at gnupg.org
>>>>> https://lists.gnupg.org/mailman/listinfo/gnupg-users
>>>>> ---snip---
>>>>
>>>> The message verifies after removing the footer.  It can be done routinely, 
>>>> on some kind of signatures.
>>>
>>> DKIM doesn't specify an automatic removal of a signature. So I postulate 
>>> there is no DKIM related tool which does this (only home-grown solutions 
>>> which need to be specially tailored to the sender as you don't know in 
>>> advance/automatically if a signature has to be stripped or not, and you can 
>>> not rely on the way the signature is added, as even this list does not use 
>>> the age old de-facto standard (which was ignored by big corporations like 
>>> they did with some other de-facto standards) of "-- " on it's own line as a 
>>> signature separator).
>>
>>
>> http://www.tana.it/sw/zdkimfilter/zdkimfilter.html#mlmtrans for one.
>> You may call it home grown, but it's not tailored to a specific sender.  Of 
>> course it doesn't work on /every/ signature.  Yours, for instance, didn't 
>> verify.  Gmail's signatures, by contrast, verify across most mailing lists.
> 
> "Yours ... didn't verify": via list or direct?


I meant via list.  Direct ones verify well.

BTW your GPG signature doesn't verify.


> Any idea if it was because this 
> lists signature was not stripped (even then, it would need to rewrite the 
> from), or because my signature was stripped (which it shouldn't)?


In the message I'm replying to, it was stripped (why?)  In the one before that 
it didn't verify, probably because of the Reply-To:.  (I can probably fix that, 
but not today.)


> Anyway, it proves my point. And it is not required by the DKIM standard, so 
> yes, I would call it home-grown as you can not rely on its existence on the 
> receiver side.


Undoing transformations just mitigates the damage of From: munging by restoring 
the original From: when it succeeds.

Perhaps it could also aid a receiver who trusts an ARC signer, if sometimes the 
ARC-Authentication-Results: can be verified that way.


> You may be able to do some un-munging in some situations, but this is not 
> specified anywhere in any validation rule of the standard. As such you can not 
> rely on anything on the receiver side. As such you need to remove the 
> DKIM-Signature header as the list owner, if you want to have the message with a 
> mangled from header not fail the dkim validation.


No, to pass DKIM validation a list just needs to add its DKIM signature.  The 
old one doesn't disturb.  Lazy DMARC verifiers may even skip signatures where 
d= is not aligned.  Really, you gain nothing by removing DKIM-Signature:'s, 
except saving a few bytes.


>>>>> (and maybe sign itself, but there are drawbacks),
>>>>
>>>> What drawback can there be to signing?  CPU resource consumption?
>>>
>>> If the list signs the message itself due to the rewritten From:-header, it 
>>> would sign spam-messages which slip through the anti-spam setup of this 
>>> list. So it would defeat what it is supposed to do, prevent SPAM from 
>>> arriving in your inbox . It would also either discredit the reputation of 
>>> the list, or increase the reputation (for a while) of the SPAM message in 
>>> some big anti-spam setups which use sender-reputation and message-hashes to 
>>> rate the SPAMiness of messages.
>>
>> Camouflage is not a good anti-spam technique, IMHO.  A sane list's 
>> subscribers want list messages, and their mailbox provider must be an inept 
>> if it degrades the list reputation because of occasional uncaught spam.
> 
> I agree, but it doesn't mean it can not happen. As such I wouldn't want to 
> mangle the from and sign myself.


Not signing might result in worse treatment.  Relying on SPF only is weak.


>>>> See also this:
>>>> https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail
>>>
>>> You can not expect all subscribers of the list to change their DKIM settings 
>>> to a more relaxed way or other sending side related stuff. This may not be 
>>> in the influence of the person (try to get google to change their dkim 
>>> settings for gmail). As such it is up to the list owner to be a nice 
>>> netticen. If the list owner(s) insists on message-munging, that's fine, but 
>>> in this case the list owner(s) has to remove DKIM signatures if they want to 
>>> have the message delivered correctly for the DKIM-policy=discard case. Any 
>>> other action which needs involvement of the receiver or the sender will not 
>>> work in the generic case (and I consider this list to fall into the generic 
>>> case).
>>
>> "mailing_list" is one of the provided policy override cases for DMARC.  RFC 
>> 7489 describes it like so:
> 
> Appendix C, DMARC XML Schema -> so it's in the report which is send. Did I 
> overlook any other place in this RFC which describes that mailing lists can or 
> should or have to be exempt from DKIM processing? If not, what do you expect 
> the usual behavior of DKIM validation software is? Will it have an heuristic 
> for mailing list detection? Also see "A.3 Sender Header Field" in the RFC, 
> which explicitly calls it a "poor candiate for inclusion in the DMARC 
> evaluation algorithm".


There is no deterministic way to determine if a message is from a mailing list. 
  Signatures, either DKIM or ARC, ease that task.  In this respect, I'd sign 
with d=lists.gnupg.org, not d=gnupg.org.

I receive aggregate reports with the exception raised, so someone is able to do 
it.  In the reports I send, I set it if I can verify the original signature 
after undoing the MLM transformation.

The Sender: field was considered in Microsoft's Sender ID (RFC 4405), which has 
been competing with SPF for some time in the past.  Every now and then someone 
proposes that DMARC should consider it too[*].  A receiver cannot verify that a 
self-appointed Sender is authorized to send messages on behalf of a bank or 
whoever it tries to impersonate.


Best
Ale
-- 

[*] https://datatracker.ietf.org/doc/draft-ietf-dmarc-sender/