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

Tue Jun 13 13:02:09 CEST 2023

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

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.

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

Yes.

> message. As I said, it's not true.

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.

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

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

I agree, but it doesn't seem to be the case here.

>>> 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 excempt 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  
explicitely calls it a "poor candiate for inclusion in the DMARC  
evaluation algorithm".

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

Sorry, I mixed up. I was having the DMARC p=reject in my mind and  
misattributed it to DKIM.

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/5d762b7a/attachment-0001.sig>