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

[Alessandro Vesely]

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.


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


I assume you mean the DKIM signature has to be removed, not the DKIM message. 
As I said, it's not true.


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

However, as ARC's specifications, unlike DKIM's, mention no responsibility, 
some mailers use this instead of DKIM —more on forwarding than on mailing 
lists, IME.

Mailing lists are enjoying an incredibly low rate of fraud.  It is enough to 
impersonate a subscriber to have your message pass, failing authentications 
notwithstanding.  Yet it doesn't happen any often.  Sooner or later they'll 
have to enforce authentication checks on entry themselves.


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


Some admins derive the need to put a footer from legal requirements.

Subject tags are just handy for the eye.  I too sort mailing list messages in 
various folders, but I don't have a folder for each list.

Munged From:s can sometimes be restored.


>> 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:

    mailing_list:  Local heuristics determined that the message arrived
       via a mailing list, and thus authentication of the original
       message was not expected to succeed.

See also BCP 167.  BTW, discard was ADSP parlance; there is no "DKIM-policy".


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


That's right.  As it is, ARC is only useful to global mailbox providers who can 
afford to categorize all (global) ARC sealers.  To become useful to small 
providers, it needs to be deployed in some kind of cooperative solution.



Best
Ale
--