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

[Alexander Leidinger]

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 sinature. 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).

>> What the list-software would need to do is to strip the original  
>> DKIM signature
>
>
> Why?  Original signatures can often be recovered.  They shouldn't be  
> removed anyway.

Already answered by Alessandro, but to add to that: any munging with  
the message (no matter if header or body) invalidates the DKIM  
signature. If the munging is done on purpose, the DKIM message has to  
be removed to prevent DKIM-policy=discard setups to lose the message  
(some people may say this would be on purpose / as designed, and I can  
agree to that, but the intend of this list here is surely not to  
discard such messages).

>> (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.

>> or to not modify the message (at least not the designated header  
>> lines, and the body). More info here:
>>     https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html
>
>
> Omitting subject tag and footer seems to me to be worse than From: munging.

My filter setup doesn't depend on a footer or subject tag. The world  
has advanced way past a subject tag or a footer to be able to identify  
a mailinglist. Any search engine is quite good at finding a webpage  
related to the list (last line of the signature in this list) and I  
don't need the email address of the list itself in the footer (it's in  
the header anyway as the TO or CC). The first content-line of the  
signature I don't need either. All the info there is either redundant  
or useless to me when I'm already subscribed. This list also has no  
subject tag. Seems we can live without it. As we are talking about the  
DKIM issues this list has, I only talk about this list, and I don'T  
care how other lists handle this.

> 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).

>> For mailman there is some info here what could/should be done:
>>     https://wiki.list.org/DEV/DKIM
>>     https://wiki.list.org/DEV/DMARC
>>
>> For listserv there is some info here what could/should be done:
>>      
>> https://www.lsoft.com/manuals/17.0/advancedtopics/Section12UsingDomainKeysIdentifi.html
>>      
>> https://www.lsoft.com/manuals/17.0/advancedtopics/Section13DMARCandLISTSERV.html
>>
>> There is also ARC (which you should see in the headers of my mail):
>>     https://en.wikipedia.org/wiki/Authenticated_Received_Chain
>
>
> I'd definitely recommend ARC, not the conceptual Mailman 3 version.   
> However, most receivers are not yet prepared to accept it.

ARC has advantages and drawbacks. One drawback is that it relies on a  
trust-chain. Only few places have an explicit trust-chain (Microsoft  
seems to allow to configure one in thier cloud offering). It is an  
additional tool in the SPF/DKIM/DMARC/... world, but not a golden  
solution, and it will not solve the problem of failing DKIM signatures  
of this list because of message-munging.

Bye,
Alexander.

-- 
http://www.Leidinger.net Alexander at Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild at FreeBSD.org  : PGP 0x8F31830F9F2772BF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: Digitale PGP-Signatur
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230613/b36fa344/attachment.sig>