Mailing List Archive

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

would someone please explain DKIM settings of lists.gnupg.org?

Looking at recent posts, I counted 44 with a failed signature by d=gnupg.org,
22 with no DKIM signature at all and none with a good signature.

I'm asking because there was a proposal to eliminate SPF from DMARC
authentication methods[*]. Opposers to such move note that in a number of
cases SPF succeeds where DKIM fails. The discussion concluded that it must be
because of misconfiguration, since most in-transit alterations were eliminated.
As people on this list is certainly acknowledgeable, I though I'd dare
asking where does such misconfiguration stem from.


Best
Ale
--

[*] https://mailarchive.ietf.org/arch/msg/dmarc/2CcO17K8QcOmTORHl3_isQBm_RE






_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OT: DKIM signatures on email messages from lists.gnupg.org [ In reply to ]
Quoting Alessandro Vesely via Gnupg-users <gnupg-users@gnupg.org>
(from Mon, 12 Jun 2023 10:57:32 +0200):

> Hi,
>
> would someone please explain DKIM settings of lists.gnupg.org?

I'm not involved in gnupg.org administration, but it looks like there
are none.

> Looking at recent posts, I counted 44 with a failed signature by
> d=gnupg.org, 22 with no DKIM signature at all and none with a good
> signature.

Can it be that those 44 are from real people which have a from-address
@gnupg.org?

> I'm asking because there was a proposal to eliminate SPF from DMARC
> authentication methods[*]. Opposers to such move note that in a
> number of cases SPF succeeds where DKIM fails. The discussion
> concluded that it must be because of misconfiguration, since most
> in-transit alterations were eliminated. As people on this list is
> certainly acknowledgeable, I though I'd dare asking where does such
> misconfiguration stem from.

Your mail to the list had a DKIM signature from tana.it (your DKIM
signature). It specifies that in the header the date, to, from and
subject lines are subject to validation. 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@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
---snip---

What the list-software would need to do is to strip the original DKIM
signature (and maybe sign itself, but there are drawbacks), 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

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

Bye,
Alexander.

--
http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF
Re: OT: DKIM signatures on email messages from lists.gnupg.org [ In reply to ]
On Mon 12/Jun/2023 13:05:51 +0200 Alexander Leidinger via Gnupg-users wrote:
> Quoting Alessandro Vesely via Gnupg-users <gnupg-users@gnupg.org> (from Mon, 12 Jun 2023 10:57:32 +0200):
>
>> Hi,
>>
>> would someone please explain DKIM settings of lists.gnupg.org?
>
> I'm not involved in gnupg.org administration, but it looks like there are none.


Sometimes there is a signature. The Announce message of April 28 had two:

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org;
s=20181017;
h=Sender:Content-Type:List-Subscribe:List-Help:List-Archive:
List-Unsubscribe:List-Id:Subject:MIME-Version:Message-ID:Date:Cc:To:From:
Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date
:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:
References:List-Post:List-Owner;
bh=AaifcSnTnefRUURuPlCYtVlF0on0neCAn9vyAWrccMA=; b=GZor1crbzgMYZ0XztsHrHN0w3P
d4QT2yOyZRUI1iA/Ys5St2fi/3ZIKghj/man3fY3c8bmN1N0fwEGCadSTzKO5YpM29kATZ8tDDLcf
hX/49Mlk+X0sw5ecu3Z/Bm+2RJlpk8TPHWNM1wUy7yIlI4txDDSCsIlAawikJ4I4HTJY=;

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org;
s=20181017;
h=Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From:
Sender:Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:
Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:
In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
List-Post:List-Owner:List-Archive;
bh=waITwZnkLncVwES3fe/pbC3rS8gp+dpge17NQpRHvMU=; b=U9warAJAiKlE0f9mSRe61yIzqa
TNpdihkg9KDQBb8px1ESE5/6/qPzsg2KOMt82hpGMJukxzKAoDMwOGvpN/TGO9ADjrjWz9Dk5Ry+p
QIwg+x3PKxYoOGVU9cmpVmeGsu6yOemyfN3mz0fGdqEC7SBGWjbe4LusOc/Kb65Opd0k=;


There were a number of Received: by/from kerckhoffs.g10code.com in between, as
if the message was sent back and forth to a signer. Most likely some header
fields are changed during the transaction.


>> Looking at recent posts, I counted 44 with a failed signature by d=gnupg.org,
>> 22 with no DKIM signature at all and none with a good signature.
>
> Can it be that those 44 are from real people which have a from-address @gnupg.org?


I only counted d=gnupg.org.


>> I'm asking because there was a proposal to eliminate SPF from DMARC
>> authentication methods[*].  Opposers to such move note that in a number of
>> cases SPF succeeds where DKIM fails.  The discussion concluded that it must
>> be because of misconfiguration, since most in-transit alterations were
>> eliminated.  As people on this list is certainly acknowledgeable,  I though
>> I'd dare asking where does such misconfiguration stem from.
>
> Your mail to the list had a DKIM signature from tana.it (your DKIM signature).
> It specifies that in the header the date, to, from and subject lines are
> subject to validation.


Those lines are enough to uniquely identify a message. Signing more fields
only makes the signature more fragile. It is not enough to prevent crackerjack
re-playing in any case.


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


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


> (and maybe sign itself, but there are drawbacks),


What drawback can there be to signing? CPU resource consumption?


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

See also this:
https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail


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


Best
Ale
--







_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OT: DKIM signatures on email messages from lists.gnupg.org [ In reply to ]
On Mon, Jun 12, 2023 at 06:45:37PM +0200, Alessandro Vesely via Gnupg-users wrote:
> > 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.

If list-software is doing something to make the DKIM signature no longer
verify, it must remove the DKIM signature or rewrite the From: header to
change alignment.

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

No it isn't. Changing the subject and adding the footer is a damaging
anti-pattern from mid-nineties. If the end-user wants to filter mail, they can
do it based on the List-Id header or any other criteria. Lists that still do
this in 2023 need to be updated to no longer do this.

> I'd definitely recommend ARC, not the conceptual Mailman 3 version.
> However, most receivers are not yet prepared to accept it.

ARC is just adding more things to the chain that you must explicitly trust.
It's basically an assurance from the remailer that "oh, btw, I checked this
message and its DKIM was good, trust me." It's useful for the huge mail
providers like Yahoo/Gmail/Outlook, but standing up your own ARC-signing
infrastructure is largely just wasting cycles.

-K

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OT: DKIM signatures on email messages from lists.gnupg.org [ In reply to ]
Konstantin Ryabitsev wrote in
<20230612-landline-jawless-f2c113@meerkat>:
|On Mon, Jun 12, 2023 at 06:45:37PM +0200, Alessandro Vesely via Gnupg-us\
|ers wrote:
|>> 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.
|
|If list-software is doing something to make the DKIM signature no longer
|verify, it must remove the DKIM signature or rewrite the From: header to
|change alignment.

My Mailman2 has "REMOVE_DKIM_HEADERS = 2".
(But this will change, somewhen.)

|>> or to not modify the message (at least not the designated header lines,
|>> and the body). More info here:
|>
|>
|> Omitting subject tag and footer seems to me to be worse than From: \
|> munging.
|
|No it isn't. Changing the subject and adding the footer is a damaging
|anti-pattern from mid-nineties. If the end-user wants to filter mail, \
|they can
|do it based on the List-Id header or any other criteria. Lists that \
|still do
|this in 2023 need to be updated to no longer do this.

That is your own biased thing to which i am totally opposed to.
The traditional email way uses a single INBOX and dispatches
non-deleted things from there (also automatically). I am happy
that many lists i am on continue to use that subject tagging, or
reintroduced it, because i get a human-compatible overview with
a single glance (already thread-sorted) when i look into my INBOX.
This includes IETF lists, tuhs and coff, 9fans, oss-sec and many
more.
(Having said that lists i read like those from NetBSD never did
anything such, and did not need to change anything to work in
today's email world.)

|> I'd definitely recommend ARC, not the conceptual Mailman 3 version.
|> However, most receivers are not yet prepared to accept it.
|
|ARC is just adding more things to the chain that you must explicitly trust.
|It's basically an assurance from the remailer that "oh, btw, I checked this
|message and its DKIM was good, trust me." It's useful for the huge mail
|providers like Yahoo/Gmail/Outlook, but standing up your own ARC-signing
|infrastructure is largely just wasting cycles.

If you do DKIM then ARC does make sense. (I am a bit away from
the standards though.) SPF/DKIM/ARC are maybe a thing, especially
when being holistic; dmarc destroyed email (not), it should imho
be boycotted.

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|~~
|..and in spring, hear David Leonard sing..
|
|The black bear, The black bear,
|blithely holds his own holds himself at leisure
|beating it, up and down tossing over his ups and downs with pleasure
|~~
|Farewell, dear collar bear

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OT: DKIM signatures on email messages from lists.gnupg.org [ In reply to ]
On Mon, Jun 12, 2023 at 09:54:45PM +0200, Steffen Nurpmeso wrote:
> |No it isn't. Changing the subject and adding the footer is a damaging
> |anti-pattern from mid-nineties. If the end-user wants to filter mail, \
> |they can
> |do it based on the List-Id header or any other criteria. Lists that \
> |still do
> |this in 2023 need to be updated to no longer do this.
>
> That is your own biased thing to which i am totally opposed to.

It's not "my own biased thing" -- I speak from experience of managing hundreds
of Linux mailing lists.

> The traditional email way uses a single INBOX and dispatches
> non-deleted things from there (also automatically). I am happy
> that many lists i am on continue to use that subject tagging, or
> reintroduced it, because i get a human-compatible overview with
> a single glance (already thread-sorted) when i look into my INBOX.
> This includes IETF lists, tuhs and coff, 9fans, oss-sec and many
> more.

The "traditional email way" is gone. Anyone who insists on doing things the
way it used to be done in the 90s is doing everyone a disservice because
messages sent by their users will increasingly end up in spam or be rejected
outright. You're contributing to the notion that email is too unreliable to be
used for anything serious, especially via mailing lists.


-K

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OT: DKIM signatures on email messages from lists.gnupg.org [ In reply to ]
Konstantin Ryabitsev wrote in
<20230612-rename-satirical-b8339e@meerkat>:
|On Mon, Jun 12, 2023 at 09:54:45PM +0200, Steffen Nurpmeso wrote:
|>|No it isn't. Changing the subject and adding the footer is a damaging
|>|anti-pattern from mid-nineties. If the end-user wants to filter mail, \
|>|they can
|>|do it based on the List-Id header or any other criteria. Lists that \
|>|still do
|>|this in 2023 need to be updated to no longer do this.
|>
|> That is your own biased thing to which i am totally opposed to.
|
|It's not "my own biased thing" -- I speak from experience of managing \
|hundreds
|of Linux mailing lists.

Well then, hi ho silver.
IETF has a lot of lists, too.

|> The traditional email way uses a single INBOX and dispatches
|> non-deleted things from there (also automatically). I am happy
|> that many lists i am on continue to use that subject tagging, or
|> reintroduced it, because i get a human-compatible overview with
|> a single glance (already thread-sorted) when i look into my INBOX.
|> This includes IETF lists, tuhs and coff, 9fans, oss-sec and many
|> more.
|
|The "traditional email way" is gone. Anyone who insists on doing things the
|way it used to be done in the 90s is doing everyone a disservice because
|messages sent by their users will increasingly end up in spam or be \
|rejected
|outright. You're contributing to the notion that email is too unreliable \
|to be
|used for anything serious, especially via mailing lists.

Nah, total rubbish. As if i would count, for one.
Second, you give an interesting picture of the mental context of
the (tens of) thousands of Linux programmers you live in.

Third, S/MIME and PGP are used seriously, it is the usual maybe
western-world specific paranoia bullshit propaganda which hammers
and bastardizingly bends somewhere, also here. Hundreds or
thousands of years you put envelope in envelope and then seal that
further. Just put pseudo headers in the outermost and make
software use the real ones from the inside instead; that is solved
for long, except for the certificate infrastructure which
unfortunately has to be a commercial mess instead of being open
for everyone easily. So that not. You need some tags in the
outermost header, and DKIM is a good thing, actually.

Having said that, the software i maintain myself cannot (until
the MIME machinery is replaced), but i have few spare time (i
could hack it in somewhat fast, but it would be a terrible hack
on a terrible infrastructure) -- the question is solely why the
big ones and their beautiful graphical programs fail to do it
properly. Why so.

Fourth; most spam i see comes from GMail or Outlook.
And then they killed mailing-lists ... not. That is wonderful.
But i grant a real, proper mailing-list must sooner or later
switch to use DKIM and ARC (and/or postsrsd), and as of today
likely (dependent on its audience) needs to rewrite From: to that
'Xy via Z' in order to make it happen. That is basically it, and
you can get away with a subject tag and a footer.
DMARC is a foul name.

Fifth email is more fifty than thirty, and i think for a reason.
Shove the rest (up your ass)!
So whereas "die Antwort heißt immer Verzicht" / "the answer is
always renunciation", that is surely not true for reliabiliy and
email. That is a super robust forgiving thing, given that even
DMARC and that mess did not break it down.

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|~~
|..and in spring, hear David Leonard sing..
|
|The black bear, The black bear,
|blithely holds his own holds himself at leisure
|beating it, up and down tossing over his ups and downs with pleasure
|~~
|Farewell, dear collar bear

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OT: DKIM signatures on email messages from lists.gnupg.org [ In reply to ]
Quoting Alessandro Vesely via Gnupg-users <gnupg-users@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@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@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF
Re: OT: DKIM signatures on email messages from lists.gnupg.org [ In reply to ]
Hi!

When posting mails to lists.gnupg.org the mails are received at our
standard MX and are then forwarded to a the Mailman box
(lists.gnupg.org). Over there we do some minimal spam detection and
then pass it to mailman. Mailman changes From to have the list address.

lists.gnupg.org does not do DKIM. I know stripped the obvious wrong
DKIM-Signature headers before they are processed by Mailman. Let's see
whether this solves the problem. Those of you in C should see my DKIM
header but the lists should not.

FWIW, I plan to migrate lists.gnupg.org to another box to limit the
systems which send out mail.


Shalom-Salam,

Werner


--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein
Re: OT: DKIM signatures on email messages from lists.gnupg.org [ In reply to ]
Quoting Steffen Nurpmeso <steffen@sdaoden.eu> (from Mon, 12 Jun 2023
21:54:45 +0200):

> Konstantin Ryabitsev wrote in
> <20230612-landline-jawless-f2c113@meerkat>:
> |On Mon, Jun 12, 2023 at 06:45:37PM +0200, Alessandro Vesely via Gnupg-us\
> |ers wrote:

> |> Omitting subject tag and footer seems to me to be worse than From: \
> |> munging.
> |
> |No it isn't. Changing the subject and adding the footer is a damaging
> |anti-pattern from mid-nineties. If the end-user wants to filter mail, \
> |they can
> |do it based on the List-Id header or any other criteria. Lists that \
> |still do
> |this in 2023 need to be updated to no longer do this.
>
> That is your own biased thing to which i am totally opposed to.
> The traditional email way uses a single INBOX and dispatches

Nice that it still works for you, but god forbit that _I_ go back to a
single inbox... and if I look at all the other IT people I know, I
agree with Konstantin that most use-cases involve pre-filtering into
some kind of hierarchy before looking at emails (some things have much
higher priority than others and the graphical applications most people
use have good support for a priority based process of looking at
pre-filtered emails).

> non-deleted things from there (also automatically). I am happy
> that many lists i am on continue to use that subject tagging, or
> reintroduced it, because i get a human-compatible overview with
> a single glance (already thread-sorted) when i look into my INBOX.
> This includes IETF lists, tuhs and coff, 9fans, oss-sec and many
> more.
> (Having said that lists i read like those from NetBSD never did
> anything such, and did not need to change anything to work in
> today's email world.)

As you are also on the FreeBSD mailinglists:
We had footers in there in the past (a quick check of messages from
1999 and 2006 confirms this). In 2021 (around June/July it seems) we
changed that, at least partly due to DKIM signatures failing (not sure
if this was the only reason).

I do not remember any complains from users about this change (I'm not
part of the FreeBSD postmaster team, but I had a discussion about
failing DKIM signatures with them, and we get internal status reports
from them from time to time). We never had subject munging in place.

With more than 100 public lists FreeBSD uses, and a lot of subscribers
per list, I would say generally we can live without mail-munging by
mailinglists. Those people which want to keep it the old way, are
typically old and experienced enough (procmail/formail anyone?) to do
their own mail-munging based upon existing header lines.

I also consider things like DKIM much more useful than a footer or
other mail-munging.

Bye,
Alexander.


--
http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF
Re: OT: DKIM signatures on email messages from lists.gnupg.org [ In reply to ]
Quoting Werner Koch via Gnupg-users <gnupg-users@gnupg.org> (from Tue,
13 Jun 2023 09:02:31 +0200):

> lists.gnupg.org does not do DKIM. I know stripped the obvious wrong
> DKIM-Signature headers before they are processed by Mailman. Let's see
> whether this solves the problem. Those of you in C should see my DKIM
> header but the lists should not.

I can confirm: no DKIM signature via the list.

Thanks for the quick reaction,
Alexander.

--
http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF
Re: OT: DKIM signatures on email messages from lists.gnupg.org [ In reply to ]
On Tue 13/Jun/2023 09:26:06 +0200 Alexander Leidinger via Gnupg-users wrote:
> Quoting Werner Koch via Gnupg-users <gnupg-users@gnupg.org> (from Tue, 13 Jun
> 2023 09:02:31 +0200):
>
>> lists.gnupg.org does not do DKIM.  I know stripped the obvious wrong
>> DKIM-Signature headers before they are processed by Mailman. Let's see
>> whether this solves the problem.  Those of you in C should see my DKIM
>> header but the lists should not.
>
> I can confirm: no DKIM signature via the list.


Setting up a DKIM signing filter in between Mailman and sendmail shouldn't take
more than half an hour,

Thanks for replying
Ale
--






_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OT: DKIM signatures on email messages from lists.gnupg.org [ In reply to ]
On Mon 12/Jun/2023 21:24:54 +0200 Konstantin Ryabitsev via Gnupg-users wrote:
> On Mon, Jun 12, 2023 at 06:45:37PM +0200, Alessandro Vesely via Gnupg-users wrote:
>>> 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.
>
> If list-software is doing something to make the DKIM signature no longer
> verify, it must remove the DKIM signature or rewrite the From: header to
> change alignment.


An invalid signature is never a reason to reject a message. The spec states to
treat invalid signatures as if they weren't there. Forensic analysis and
advanced software can use the signature even if it was invalidated.


Best
Ale
--










_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OT: DKIM signatures on email messages from lists.gnupg.org [ In reply to ]
On Tue 13/Jun/2023 08:46:06 +0200 Alexander Leidinger via Gnupg-users wrote:
> Quoting Alessandro Vesely via Gnupg-users <gnupg-users@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@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
--






_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OT: DKIM signatures on email messages from lists.gnupg.org [ In reply to ]
On Tue, 13 Jun 2023 08:46, Alexander Leidinger said:

> DKIM doesn't specify an automatic removal of a sinature. So I
> postulate there is no DKIM related tool which does this (only

formail -I DKIM-Signature

BTW, the whole DKIM thing does not protect the body of a mail because
for example the Content-type is not commonly included in the hash and
thus you can change the boundary in this header and then tweak the body.
TLR had a PoC within hours after the DKIM idea was original proposed.
It was a major failure not to use established MIME formats for that
thing (protecting headers would have been simple with MIME).


SCNR,

Werner


--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein
Re: OT: DKIM signatures on email messages from lists.gnupg.org [ In reply to ]
On Tue 13/Jun/2023 11:40:39 +0200 Werner Koch via Gnupg-users wrote:
> BTW, the whole DKIM thing does not protect the body of a mail because
> for example the Content-type is not commonly included in the hash and
> thus you can change the boundary in this header and then tweak the body.


That hack only works when a signature contains the l= tag, which limits the
part of the body covered by the signature to the given length. That tag was
indeed designed so that mailing lists could append a footer to plain text
messages. It should never be set.


Best
Ale
--






_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OT: DKIM signatures on email messages from lists.gnupg.org [ In reply to ]
Quoting Alessandro Vesely <vesely@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@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@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@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF
Re: OT: DKIM signatures on email messages from lists.gnupg.org [ In reply to ]
Alexander Leidinger wrote in
<20230613091839.Horde.xOmd2-klk1PTncda-lgsFUI@webmail.leidinger.net>:
|Quoting Steffen Nurpmeso <steffen@sdaoden.eu> (from Mon, 12 Jun 2023
|21:54:45 +0200):
...
|> non-deleted things from there (also automatically). I am happy
|> that many lists i am on continue to use that subject tagging, or
|> reintroduced it, because i get a human-compatible overview with
|> a single glance (already thread-sorted) when i look into my INBOX.
|> This includes IETF lists, tuhs and coff, 9fans, oss-sec and many
|> more.
|> (Having said that lists i read like those from NetBSD never did
|> anything such, and did not need to change anything to work in
|> today's email world.)
|
|As you are also on the FreeBSD mailinglists:
|We had footers in there in the past (a quick check of messages from
|1999 and 2006 confirms this). In 2021 (around June/July it seems) we
|changed that, at least partly due to DKIM signatures failing (not sure
|if this was the only reason).
|
|I do not remember any complains from users about this change (I'm not
|part of the FreeBSD postmaster team, but I had a discussion about
|failing DKIM signatures with them, and we get internal status reports
|from them from time to time). We never had subject munging in place.
|
|With more than 100 public lists FreeBSD uses, and a lot of subscribers
|per list, I would say generally we can live without mail-munging by
|mailinglists. Those people which want to keep it the old way, are

Yeah that is your own biased opinion, but i am happy that i am on
MLs which do otherwise.

|typically old and experienced enough (procmail/formail anyone?) to do
|their own mail-munging based upon existing header lines.

You surely miss the one from the tmux developer which i never used
but would claim is surely a good one.

But it is not that simple, @FreeBSD.org developer email addresses
are often aliases to for example @gmail.com, and until at least
once i last had comm with one mails were simply retransmitted,
i had to weaken my SPF record from -all to ~all because that
failed. (I included postsrsd in the list due to this.)

|I also consider things like DKIM much more useful than a footer or
|other mail-munging.

But where is the connection with this.
It is not DKIM that kills mailing-lists, no?
Sure DKIM is something useful, unfortunately its further
development is blocked by some destroyers on the according IETF
list, it even switched to moderated mode due to that, very, _very_
ugly. Then again i personally think DKIM and all the other things
are only plastering over a false solution, but yes, they do that.
And with PGP you can even have non-MIME confidentiality and/or
assurance (easily). Even those who work on email for over fourty
years are having long notation threads over whether a ML sent mail
is "new", or whatever and all that .. is surely off-topic.

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|~~
|..and in spring, hear David Leonard sing..
|
|The black bear, The black bear,
|blithely holds his own holds himself at leisure
|beating it, up and down tossing over his ups and downs with pleasure
|~~
|Farewell, dear collar bear

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OT: DKIM signatures on email messages from lists.gnupg.org [ In reply to ]
On Tue 13/Jun/2023 13:02:09 +0200 Alexander Leidinger via Gnupg-users wrote:
> Quoting Alessandro Vesely <vesely@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@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@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/






_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OT: DKIM signatures on email messages from lists.gnupg.org [ In reply to ]
On Dienstag, 13. Juni 2023 19:56:38 CEST Alessandro Vesely via Gnupg-users
wrote:
> BTW your GPG signature doesn't verify.

It does for me. For all of his messages in this thread.

Regards,
Ingo
Re: OT: DKIM signatures on email messages from lists.gnupg.org [ In reply to ]
Alessandro Vesely wrote in
<8fe44a06-cb26-db9b-bf9a-8251baf560b4@tana.it>:
...
|d= is not aligned. Really, you gain nothing by removing DKIM-Signature:\
|'s,
|except saving a few bytes.

Most non-spam non-patch messages i see have an exorbitant text /
header data relation. I could not tell names now (i use

headerpick save ignore '^Delivered-To$' '^Envelope-To$' '^Original-.*$' '^X-.*$' '^ARC-.+$' '^Authentication-Results$' '^DKIM.+$' ^X- ^IronPort ^MGA ^Spam '^(Accept|Content)-Language' ^Thread-

) but there exist universities and organizations with baffling
internal email infrastructures, and each of those hops performs
spam checks, DKIM+ verification, and -signing. Over, and over,
and over again. (Where i would then, likely, use a (WireGuard)
VPN, or plain TLS with client certificates, to do the internal
hops. But, you know, there is wiiind, there is sooollarrr, and
for now there are plenty nuclear plants, too. Just my one cent.)

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

The very much appreciated Dave Crocker who is in email for i think
45 years or more added RFC 9057 Author:, which is worth reading
when talking this topic.
Unfortunately the get-the-job-done-for-money people who caused all
the mess do not seem to care for it. They do not care for the
email infrastructure at all, which finally (for me) brings back
the claims of the nonseriousity of email.
Maybe an interesting further data point i have read today in an
Austrian magazine that EU wants to have access to Signal and other
messengers aka decryption possibilities ([1], says it abstracts
[2]).


[1] https://www.derstandard.at/story/3000000174315/eu-staaten-beharren-mehrheitlich-auf-anlassloser-messenger-ueberwachung
[2] https://netzpolitik.org/2023/staendige-vertreter-eu-staaten-wollen-chatkontrolle-trotz-warnung-ihrer-juristen/#netzpolitik-pw

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|~~
|..and in spring, hear David Leonard sing..
|
|The black bear, The black bear,
|blithely holds his own holds himself at leisure
|beating it, up and down tossing over his ups and downs with pleasure
|~~
|Farewell, dear collar bear

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OT: DKIM signatures on email messages from lists.gnupg.org [ In reply to ]
Quoting Alessandro Vesely <vesely@tana.it> (from Tue, 13 Jun 2023
19:56:38 +0200):

> On Tue 13/Jun/2023 13:02:09 +0200 Alexander Leidinger via Gnupg-users wrote:
>> Quoting Alessandro Vesely <vesely@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@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@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.

My MUA tries to alidate the GPG signature against the From-address
(which is @gnupg.org) and as such fails. I haven't tried to validate
by hand. An email which I had send to another mailinglist shows up
with a valid GPG signature in my MUA.

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

My mails which I get from the list into my inbox all have my
signature. As such the original message shall have it. Your
Thunderbird will strip my signature in the reply-window, as it knows
"^-- $" (regex notation) as a signature separator and IIRC the default
option in Thunderbird is to strip signatures on reply.


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

I agree.

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

That would be sensible, if DKIM signing is something the list-owners
want to do.

Bye,
Alexander.

--
http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF