From ralph at ml.seichter.de  Thu Jun  1 09:16:58 2023
From: ralph at ml.seichter.de (Ralph Seichter)
Date: Thu, 01 Jun 2023 09:16:58 +0200
Subject: [Announce] GnuPG for OS X 2.4.2
Message-ID: <87y1l3zm6t.fsf@ra.horus-it.com>

GnuPG for OS X / macOS release 2.4.2 is now available for download via
https://sourceforge.net/p/gpgosx/docu/Download/ . This release also
includes updates for several library dependencies.

The disk image signature key is available via public keyservers, and it
can also be downloaded from https://www.seichter.de/pgp/gpgosx-signing.asc .

  pub ed25519/FD56297D9833FF7F 2022-07-07 [SC] [expires: 2027-07-06]
     Key fingerprint = EAB0 FE4F F793 D9E7 028E  C8E2 FD56 297D 9833 FF7F
  uid [ultimate] Ralph Seichter (GnuPG for OS X signing key)

GnuPG 2.4.x is installed in /usr/local/gnupg-2.4 instead of the formerly
hardcoded directory /usr/local/gnupg-2.2. This enables installing both
stable and LTS releases of GnuPG for OS X side by side, for advanced
users' needs.

The one caveat is that the latest installation will replace existing
soft links in /usr/local/{bin,lib}. Please use absolute paths like
/usr/local/gnupg-2.2/bin/gpg2 if necessary. Enjoy.

-Ralph


From Alexander at leidinger.net  Thu Jun  1 13:23:36 2023
From: Alexander at leidinger.net (Alexander Leidinger)
Date: Thu, 01 Jun 2023 13:23:36 +0200
Subject: get OpenPGP pubkeys authenticated using German personal ID
In-Reply-To: <202305311655.13811.bernhard@intevation.de>
Message-ID: <20230601132336.Horde.kTnbuuxrOgs5IKjYyK1K6w6@webmail.leidinger.net>


Quoting Bernhard Reiter <bernhard at intevation.de> (from Wed, 31 May  
2023 16:55:05 +0200):

> https://pgp.governikus.de/?lang=EN
>
> """
> Governikus provides the online service for authenticating your OpenPGP key on
> behalf of the German Federal Office for Information Security (BSI). This
> online service compares the name read from your ID card, your electronic
> residence permit or eID card for citizens of the European Union with the name
> specified in your OpenPGP key. If the names match, your public key is
> electronically signed by Governikus, confirming the match.
> """
>
> interesting, kind of cool.
>
> Obviously they cannot authenticate the email address
> so once I have a common name, we get collisions?

The signature is send to the email listed in the key. In case you  
share a name with someone which has a PGP key and you sign this key,  
the person(s) with access to that email account will get the signature.

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/20230601/81e5e7ef/attachment.sig>

From andrewg at andrewg.com  Thu Jun  1 15:19:29 2023
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Thu, 1 Jun 2023 14:19:29 +0100
Subject: get OpenPGP pubkeys authenticated using German personal ID
In-Reply-To: <20230601132336.Horde.kTnbuuxrOgs5IKjYyK1K6w6@webmail.leidinger.net>
References: <20230601132336.Horde.kTnbuuxrOgs5IKjYyK1K6w6@webmail.leidinger.net>
Message-ID: <B8A0A419-4AAE-4939-9632-A228B73B91BC@andrewg.com>

On 1 Jun 2023, at 12:23, Alexander Leidinger via Gnupg-users <gnupg-users at gnupg.org> wrote:
> 
> Quoting Bernhard Reiter <bernhard at intevation.de <mailto:bernhard at intevation.de>> (from Wed, 31 May 2023 16:55:05 +0200):
> 
>> Obviously they cannot authenticate the email address
>> so once I have a common name, we get collisions?
> 
> The signature is send to the email listed in the key. In case you share a name with someone which has a PGP key and you sign this key, the person(s) with access to that email account will get the signature.

This is not best practice. Normally when email verification is being performed, the gated action (such as certification, account creation etc.) is not done until after a (time-bound!) challenge/response succeeds. This places too much emphasis on verification of the (non-unique) ?real name? component of the UserID, and not enough on the machine-readable email address.

This opens up more fundamental questions about the meaning of signatures over RFC822 UserIDs - do they validate the ?real name?, the email address, or some combination of the two? For example, an email-validating CA may only check the email address part, treating the ?real name? as little more than a comment; while Governikus appear to be doing it the other way around. It is of course up to the receiver to decide how to interpret signatures, but it only compounds the problem when not only is the signer?s trustworthiness in question, but also their intent. How do you interpret the validity of a claim when it?s not even clear what the claim is?

A

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230601/e6f8e484/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230601/e6f8e484/attachment.sig>

From johanw at vulcan.xs4all.nl  Thu Jun  1 16:50:31 2023
From: johanw at vulcan.xs4all.nl (Johan Wevers)
Date: Thu, 1 Jun 2023 16:50:31 +0200
Subject: get OpenPGP pubkeys authenticated using German personal ID
In-Reply-To: <202305311655.13811.bernhard@intevation.de>
References: <202305311655.13811.bernhard@intevation.de>
Message-ID: <674a90b4-c2a2-5174-f57c-c8c2cbfaa83c@vulcan.xs4all.nl>

On 2023-05-31 16:55, Bernhard Reiter wrote:

> Governikus provides the online service for authenticating your OpenPGP key on 
> behalf of the German Federal Office for Information Security (BSI). This 
> online service compares the name read from your ID card, your electronic 
> residence permit or eID card for citizens of the European Union with the name 
> specified in your OpenPGP key. If the names match, your public key is 
> electronically signed by Governikus, confirming the match. 

Considering the persistent attempts of the EU to scan all encrypted
communication, would you think it is wise to prove to one of the
governments pushing this which key is yours? GnuPG encrypted mail can be
analyzed to see what the receiver's keyID is so using such a key with
another mail address would inform any snooper that it is yours.

-- 
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html


From andrewg at andrewg.com  Thu Jun  1 17:08:06 2023
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Thu, 1 Jun 2023 16:08:06 +0100
Subject: get OpenPGP pubkeys authenticated using German personal ID
In-Reply-To: <674a90b4-c2a2-5174-f57c-c8c2cbfaa83c@vulcan.xs4all.nl>
References: <202305311655.13811.bernhard@intevation.de>
 <674a90b4-c2a2-5174-f57c-c8c2cbfaa83c@vulcan.xs4all.nl>
Message-ID: <5E61C946-9935-4D05-ADEC-B964068BC7B1@andrewg.com>

On 1 Jun 2023, at 15:50, Johan Wevers via Gnupg-users <gnupg-users at gnupg.org> wrote:
> 
> On 2023-05-31 16:55, Bernhard Reiter wrote:
> 
>> Governikus provides the online service for authenticating your OpenPGP key on
>> behalf of the German Federal Office for Information Security (BSI). This
>> online service compares the name read from your ID card, your electronic
>> residence permit or eID card for citizens of the European Union with the name
>> specified in your OpenPGP key. If the names match, your public key is
>> electronically signed by Governikus, confirming the match.
> 
> Considering the persistent attempts of the EU to scan all encrypted
> communication, would you think it is wise to prove to one of the
> governments pushing this which key is yours? GnuPG encrypted mail can be
> analyzed to see what the receiver's keyID is so using such a key with
> another mail address would inform any snooper that it is yours.

If you want to maintain two separate online identities, and keep that linkage secret from your government, using the same encryption key for both is pretty high up the list of very bad ideas.

A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230601/8c1da986/attachment.sig>

From Alexander at leidinger.net  Fri Jun  2 07:55:24 2023
From: Alexander at leidinger.net (Alexander Leidinger)
Date: Fri, 02 Jun 2023 07:55:24 +0200
Subject: get OpenPGP pubkeys authenticated using German personal ID
In-Reply-To: <B8A0A419-4AAE-4939-9632-A228B73B91BC@andrewg.com>
References: <20230601132336.Horde.kTnbuuxrOgs5IKjYyK1K6w6@webmail.leidinger.net>
 <B8A0A419-4AAE-4939-9632-A228B73B91BC@andrewg.com>
Message-ID: <20230602075524.Horde.2XgrKznfVnYJ6yezHjig0Rt@webmail.leidinger.net>

  Quoting Andrew Gallagher <andrewg at andrewg.com> (from Thu, 1 Jun 2023  
14:19:29 +0100):

> On 1 Jun 2023, at 12:23, Alexander Leidinger via Gnupg-users  
> <gnupg-users at gnupg.org> wrote:
>
>> ?
>>        Quoting Bernhard Reiter <bernhard at intevation.de> (from Wed,  
>> 31 May 2023 16:55:05 +0200):
>>
>>> Obviously they cannot authenticate the email address
>>> so once I have a common name, we get collisions?
>>
>> The signature is send to the email listed in the key. In case you  
>> share a name with someone which has a PGP key and you sign this  
>> key, the person(s) with access to that email account will get the  
>> signature.
>
>   This is not best practice. Normally when email verification is  
> being performed, the gated action (such as certification, account  
> creation etc.) is not done until after a (time-bound!)  
> challenge/response succeeds. This places too much emphasis on  
> verification of the (non-unique) ?real name? component of the  
> UserID, and not enough on the machine-readable email address.
>   ?
>   This opens up more fundamental questions about the meaning of  
> signatures over RFC822 UserIDs - do they validate the ?real name?,  
> the email address, or some combination of the two? For example, an  
> email-validating CA may only check the email address part, treating  
> the ?real name? as little more than a comment; while Governikus  
> appear to be doing it the other way around. It is of course up to  
> the receiver to decide how to interpret signatures, but it only  
> compounds the problem when not only is the signer?s trustworthiness  
> in question, but also their intent. How do you interpret the  
> validity of a claim when it?s not even clear what the claim is?
>   ?

I don't remember if there was a challenge/response or not. As I still  
have the email with the signed key, I can tell that the signature can  
arrive via a TLS encrypted SMTP channel directly from governicus (and  
they have a SPF setup but not DKIM):
---snip---
Received: from smtp.governikus.de (smtp.governikus.de [194.31.70.126])  
  (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)    
key-exchange X25519 server-signature ECDSA (P-256) server-digest  
SHA256   client-signature RSA-PSS (4096 bits) client-digest SHA256)   
(Client CN "VPR-BOS004.dmz.bosnetz.de", Issuer  
"VPR-BOS004.dmz.bosnetz.de" (not verified))---snip---

Bye,
Alexander.
-- 
http://www.Leidinger.net Alexander at Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild at FreeBSD.org  : PGP 0x8F31830F9F2772BF
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230602/2c888b95/attachment-0001.html>
-------------- 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/20230602/2c888b95/attachment-0001.sig>

From jcb62281 at gmail.com  Sat Jun  3 02:56:15 2023
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Fri, 02 Jun 2023 19:56:15 -0500
Subject: get OpenPGP pubkeys authenticated using German personal ID
In-Reply-To: <20230602075524.Horde.2XgrKznfVnYJ6yezHjig0Rt@webmail.leidinger.net>
References: <20230601132336.Horde.kTnbuuxrOgs5IKjYyK1K6w6@webmail.leidinger.net>
 <B8A0A419-4AAE-4939-9632-A228B73B91BC@andrewg.com>
 <20230602075524.Horde.2XgrKznfVnYJ6yezHjig0Rt@webmail.leidinger.net>
Message-ID: <647A8FAF.8070001@gmail.com>

Alexander Leidinger via Gnupg-users wrote:
> [...]
>
> I don't remember if there was a challenge/response or not. As I still 
> have the email with the signed key, I can tell that the signature can 
> arrive via a TLS encrypted SMTP channel directly from governicus (and 
> they have a SPF setup but not DKIM):
> ---snip---
>
> Received: from smtp.governikus.de (smtp.governikus.de [194.31.70.126])
>  (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
>   key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256
>   client-signature RSA-PSS (4096 bits) client-digest SHA256)
>  (Client CN "VPR-BOS004.dmz.bosnetz.de", Issuer "VPR-BOS004.dmz.bosnetz.de" (not verified))
>   
>
> ---snip---
>

Am I misreading that header or does Governikus' outgoing SMTP have a 
self-signed client certificate for 'VPR-BOS004.dmz.bosnetz.de'?  That 
does not inspire confidence...


-- Jacob



From broussard_marc at yahoo.fr  Mon Jun  5 16:49:55 2023
From: broussard_marc at yahoo.fr (broussard marc)
Date: Mon, 5 Jun 2023 14:49:55 +0000 (UTC)
Subject: expiration date for the keys pgp (automatism)
In-Reply-To: <647A8FAF.8070001@gmail.com>
References: <20230601132336.Horde.kTnbuuxrOgs5IKjYyK1K6w6@webmail.leidinger.net>
 <B8A0A419-4AAE-4939-9632-A228B73B91BC@andrewg.com>
 <20230602075524.Horde.2XgrKznfVnYJ6yezHjig0Rt@webmail.leidinger.net>
 <647A8FAF.8070001@gmail.com>
Message-ID: <1102499875.5129057.1685976595943@mail.yahoo.com>

 Hello

It is the firs time that I am writing to the mailing list...
Be indulgent please!

I need to know when a key is expired in order to renew it:

for instance:

gpg --list-keys

------------------------

 pub rsa4096 2016-05-26 [SC] [expires: 2025-01-31]
 xxxxxxxxxxxxxxxxxXXXXXXXXXXXX
 uid [ full ] PeopleDoc Inc (Eeyore Encryption Key Prod EU) <xxxx at YYYYY.com>
 sub rsa4096 2016-05-26 [E] [expires: 2025-01-31]



I would to launch a script each week end, to have a warning when for instance, when the key is expired 4 week later.
In this case, early january 2025 I would like this warning.

I think I can manage to do it with shell script (LINUX) ...

but before, I would like to if there is a fonction in pgp which allow that or anything similar ?
=> does pgp can tell when the key is becoming soon expired?

thanks a lot

marc broussard
equans France  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230605/a8a34fc4/attachment.html>

From andrewg at andrewg.com  Tue Jun  6 13:20:07 2023
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Tue, 6 Jun 2023 12:20:07 +0100
Subject: get OpenPGP pubkeys authenticated using German personal ID
In-Reply-To: <647A8FAF.8070001@gmail.com>
References: <20230601132336.Horde.kTnbuuxrOgs5IKjYyK1K6w6@webmail.leidinger.net>
 <B8A0A419-4AAE-4939-9632-A228B73B91BC@andrewg.com>
 <20230602075524.Horde.2XgrKznfVnYJ6yezHjig0Rt@webmail.leidinger.net>
 <647A8FAF.8070001@gmail.com>
Message-ID: <0106787F-EB69-4B8C-B115-5E2031953263@andrewg.com>

On 3 Jun 2023, at 01:56, Jacob Bachmeyer <jcb62281 at gmail.com> wrote:
> 
> Alexander Leidinger via Gnupg-users wrote:
>> [...]
>> 
>> I don't remember if there was a challenge/response or not. As I still have the email with the signed key, I can tell that the signature can arrive via a TLS encrypted SMTP channel directly from governicus (and they have a SPF setup but not DKIM):
>> ---snip---
>> 
>> Received: from smtp.governikus.de (smtp.governikus.de [194.31.70.126])
>> (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
>>  key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256
>>  client-signature RSA-PSS (4096 bits) client-digest SHA256)
>> (Client CN "VPR-BOS004.dmz.bosnetz.de", Issuer "VPR-BOS004.dmz.bosnetz.de" (not verified))
>> 
>> ---snip---
>> 
> 
> Am I misreading that header or does Governikus' outgoing SMTP have a self-signed client certificate for 'VPR-BOS004.dmz.bosnetz.de'?  That does not inspire confidence?


I wouldn?t read too much into this. The client cert here is probably used for internal purposes, and their MXes may be configured to offer their client certs by default - external sites won?t check it anyway, so no harm done.

A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230606/6bb3bb81/attachment.sig>

From bernhard at intevation.de  Fri Jun  9 10:37:26 2023
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 9 Jun 2023 10:37:26 +0200
Subject: expiration date for the keys pgp (automatism)
In-Reply-To: <1102499875.5129057.1685976595943@mail.yahoo.com>
References: <20230601132336.Horde.kTnbuuxrOgs5IKjYyK1K6w6@webmail.leidinger.net>
 <647A8FAF.8070001@gmail.com>
 <1102499875.5129057.1685976595943@mail.yahoo.com>
Message-ID: <202306091037.32867.bernhard@intevation.de>

Hello Marc,

Am Montag 05 Juni 2023 16:49:55 schrieb broussard marc via Gnupg-users:
> It is the firs time that I am writing to the mailing list...

welcome!

> I would to launch a script each week end, to have a warning when for
> instance, when the key is expired 4 week later. In this case, early january
> 2025 I would like this warning.
>
> I think I can manage to do it with shell script (LINUX) ...

Another option would be to use GPGME which somehow is the official API
to access GnuPG functionality and usually more stable than parsing the output
yourself in a shell.

E.g. you can use python, see https://wiki.gnupg.org/APIs .
 
> but before, I would like to if there is a fonction in pgp which allow that
> or anything similar ? => does pgp can tell when the key is becoming soon
> expired?

At least I do not remember such a function.

But I have two more hints:
 * See in the documentation for option -with-colons
   if you really do want to parse the output yourself.
 * Faking the time may help you, e.g. put it four weeks in the future.
   See for the "esoteric"  option --faked-system-time

Again, personally a python script would be my first choice.

Regards
Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230609/5c07c5ae/attachment.sig>

From wk at gnupg.org  Fri Jun  9 14:25:01 2023
From: wk at gnupg.org (Werner Koch)
Date: Fri, 09 Jun 2023 14:25:01 +0200
Subject: expiration date for the keys pgp (automatism)
In-Reply-To: <1102499875.5129057.1685976595943@mail.yahoo.com> (broussard marc
 via Gnupg-users's message of "Mon,
 5 Jun 2023 14:49:55 +0000 (UTC)")
References: <20230601132336.Horde.kTnbuuxrOgs5IKjYyK1K6w6@webmail.leidinger.net>
 <B8A0A419-4AAE-4939-9632-A228B73B91BC@andrewg.com>
 <20230602075524.Horde.2XgrKznfVnYJ6yezHjig0Rt@webmail.leidinger.net>
 <647A8FAF.8070001@gmail.com>
 <1102499875.5129057.1685976595943@mail.yahoo.com>
Message-ID: <875y7wvn4y.fsf@wheatstone.g10code.de>

On Mon,  5 Jun 2023 14:49, broussard marc said:

> => does pgp can tell when the key is becoming soon expired?

That is easy on Unix:

  $ gpg --list-keys --with-colons \
    | awk -F: -v days=60 \
      'BEGIN { from=systime(); to=from+(days*86400)};\
       $1=="pub" && $7 > from && $7 < to { found=1 };
       $1=="fpr" && found {found=0; \
          print "key " $10 " expires in the next " days " days"}'

A really proper solution would use a function to decode field 7 because
it may in the future be shown as YYYYMMDDTHHMMSS (actually gpgsm does it
this way).

I will consider to allow the expiration date for the --list-filter which
could then be used on Windows (i.e. w/o awk) as well.



Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230609/f03504f5/attachment.sig>

From steffen at sdaoden.eu  Fri Jun  9 15:24:34 2023
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Fri, 09 Jun 2023 15:24:34 +0200
Subject: expiration date for the keys pgp (automatism)
In-Reply-To: <875y7wvn4y.fsf@wheatstone.g10code.de>
References: <20230601132336.Horde.kTnbuuxrOgs5IKjYyK1K6w6@webmail.leidinger.net>
 <B8A0A419-4AAE-4939-9632-A228B73B91BC@andrewg.com>
 <20230602075524.Horde.2XgrKznfVnYJ6yezHjig0Rt@webmail.leidinger.net>
 <647A8FAF.8070001@gmail.com>
 <1102499875.5129057.1685976595943@mail.yahoo.com>
 <875y7wvn4y.fsf@wheatstone.g10code.de>
Message-ID: <20230609132434.xS7mR%steffen@sdaoden.eu>

Werner Koch wrote in
 <875y7wvn4y.fsf at wheatstone.g10code.de>:
 |On Mon,  5 Jun 2023 14:49, broussard marc said:
 |
 |> => does pgp can tell when the key is becoming soon expired?
 |
 |That is easy on Unix:
 |
 |  $ gpg --list-keys --with-colons \
 || awk -F: -v days=60 \
 |      'BEGIN { from=systime(); to=from+(days*86400)};\

Not _that_ easy ("date +%s" maybe, strftime(3) %s is old).

  #?2|kent:$ awk 'END{print systime()}' </dev/null
  1686316851
  #?0|kent:$ mawk 'END{print systime()}' </dev/null
  1686316853
  #?0|kent:$ nawk 'END{print systime()}' </dev/null
  nawk: calling undefined function systime
   source line number 1
  #?2|kent:$ busybox.static awk 'END{print systime()}' </dev/null
  1686316860

 |       $1=="pub" && $7 > from && $7 < to { found=1 };
 |       $1=="fpr" && found {found=0; \
 |          print "key " $10 " expires in the next " days " days"}'
 |
 |A really proper solution would use a function to decode field 7 because
 |it may in the future be shown as YYYYMMDDTHHMMSS (actually gpgsm does it
 |this way).
 |
 |I will consider to allow the expiration date for the --list-filter which
 |could then be used on Windows (i.e. w/o awk) as well.

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


From steffen at sdaoden.eu  Sun Jun 11 00:30:01 2023
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Sun, 11 Jun 2023 00:30:01 +0200
Subject: expiration date for the keys pgp (automatism)
In-Reply-To: <20230609132434.xS7mR%steffen@sdaoden.eu>
References: <20230601132336.Horde.kTnbuuxrOgs5IKjYyK1K6w6@webmail.leidinger.net>
 <B8A0A419-4AAE-4939-9632-A228B73B91BC@andrewg.com>
 <20230602075524.Horde.2XgrKznfVnYJ6yezHjig0Rt@webmail.leidinger.net>
 <647A8FAF.8070001@gmail.com>
 <1102499875.5129057.1685976595943@mail.yahoo.com>
 <875y7wvn4y.fsf@wheatstone.g10code.de>
 <20230609132434.xS7mR%steffen@sdaoden.eu>
Message-ID: <20230610223001.z4mDP%steffen@sdaoden.eu>

P.S.:

Steffen Nurpmeso wrote in
 <20230609132434.xS7mR%steffen at sdaoden.eu>:
 |Werner Koch wrote in
 | <875y7wvn4y.fsf at wheatstone.g10code.de>:
 ||On Mon,  5 Jun 2023 14:49, broussard marc said:
 ||
 ||> => does pgp can tell when the key is becoming soon expired?
 ||
 ||That is easy on Unix:
 ||
 ||  $ gpg --list-keys --with-colons \
 ||| awk -F: -v days=60 \
 ||      'BEGIN { from=systime(); to=from+(days*86400)};\
 |
 |Not _that_ easy ("date +%s" maybe, strftime(3) %s is old).
 |
 |  #?2|kent:$ awk 'END{print systime()}' </dev/null
 |  1686316851
 |  #?0|kent:$ mawk 'END{print systime()}' </dev/null
 |  1686316853
 |  #?0|kent:$ nawk 'END{print systime()}' </dev/null
 |  nawk: calling undefined function systime
 |   source line number 1

Todd Millert of sudo/OpenBSD mentioned that nawk (Kernighan's one
true awk) got systime(), but it is on the [bsd-features] branch of
the github repo[1] only, taken over among other things by Aharon
Robbins of gawk (i had opened an issue; 'and switched my CRUX
Linux port to that branch).

  [1] https://github.com/onetrueawk/awk.git

 |  #?2|kent:$ busybox.static awk 'END{print systime()}' </dev/null
 |  1686316860
 |
 ||       $1=="pub" && $7 > from && $7 < to { found=1 };
 ||       $1=="fpr" && found {found=0; \
 ||          print "key " $10 " expires in the next " days " days"}'
 ||
 ||A really proper solution would use a function to decode field 7 because
 ||it may in the future be shown as YYYYMMDDTHHMMSS (actually gpgsm does it
 ||this way).
 ||
 ||I will consider to allow the expiration date for the --list-filter which
 ||could then be used on Windows (i.e. w/o awk) as well.

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


From bernhard at intevation.de  Mon Jun 12 10:37:25 2023
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 12 Jun 2023 10:37:25 +0200
Subject: expiration date for the keys pgp (automatism)
In-Reply-To: <875y7wvn4y.fsf@wheatstone.g10code.de>
References: <20230601132336.Horde.kTnbuuxrOgs5IKjYyK1K6w6@webmail.leidinger.net>
 <1102499875.5129057.1685976595943@mail.yahoo.com>
 <875y7wvn4y.fsf@wheatstone.g10code.de>
Message-ID: <202306121037.26114.bernhard@intevation.de>

Am Freitag 09 Juni 2023 14:25:01 schrieb Werner Koch via Gnupg-users:
> A really proper solution would use a function to decode field 7

And potentially filter for otherwise valid pubkeys. >;)

Best,
Bernhard

-- 
https://intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230612/83fb0f86/attachment.sig>

From vesely at tana.it  Mon Jun 12 10:57:32 2023
From: vesely at tana.it (Alessandro Vesely)
Date: Mon, 12 Jun 2023 10:57:32 +0200
Subject: OT: DKIM signatures on email messages from lists.gnupg.org
Message-ID: <87bd1dab-a656-47da-5e5f-b4ac14cac4a7@tana.it>

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







From Alexander at leidinger.net  Mon Jun 12 13:05:51 2023
From: Alexander at leidinger.net (Alexander Leidinger)
Date: Mon, 12 Jun 2023 13:05:51 +0200
Subject: OT: DKIM signatures on email messages from lists.gnupg.org
In-Reply-To: <87bd1dab-a656-47da-5e5f-b4ac14cac4a7@tana.it>
Message-ID: <20230612130551.Horde.ah8LbiWcJfdmZWg8d0HXXeW@webmail.leidinger.net>

Quoting Alessandro Vesely via Gnupg-users <gnupg-users at 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 at 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 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/20230612/bcc2a0ca/attachment.sig>

From steffen at sdaoden.eu  Mon Jun 12 14:48:32 2023
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Mon, 12 Jun 2023 14:48:32 +0200
Subject: expiration date for the keys pgp (automatism)
In-Reply-To: <20230610223001.z4mDP%steffen@sdaoden.eu>
References: <20230601132336.Horde.kTnbuuxrOgs5IKjYyK1K6w6@webmail.leidinger.net>
 <B8A0A419-4AAE-4939-9632-A228B73B91BC@andrewg.com>
 <20230602075524.Horde.2XgrKznfVnYJ6yezHjig0Rt@webmail.leidinger.net>
 <647A8FAF.8070001@gmail.com>
 <1102499875.5129057.1685976595943@mail.yahoo.com>
 <875y7wvn4y.fsf@wheatstone.g10code.de>
 <20230609132434.xS7mR%steffen@sdaoden.eu>
 <20230610223001.z4mDP%steffen@sdaoden.eu>
Message-ID: <20230612124832.6TZoY%steffen@sdaoden.eu>

P.P.S.: .. and getting off-topic ..

Leonardo Taccari posted a brilliant idea to the already closed
nawk issue that should not be concealed, to which i just now
responded

--- Forwarded from Steffen Nurpmeso <steffen at sdaoden.eu> ---
 |Hello!
 |
 |Leonardo Taccari wrote in
 | <onetrueawk/awk/issues/184/1586092193 at github.com>:
 ||@sdaoden another possible way - that should work on all the AWKs - is:
 ||
 ||```awk
 ||BEGIN { srand(); t = srand(); print t }
 ||```
 ||
 ||When `srand()` is called without any argument it will start from the \
 ||current time of day.
 |
 |That is actually a brilliant idea!
 |This works back to System V8 awk, and for BSD i am a bit out of
 |ideas, CSRG repo shows nothing before 1994, though gawk came in
 |earlier already.
 |But anyway, for (at least) almost thirty years anywhere!

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


From vesely at tana.it  Mon Jun 12 18:45:37 2023
From: vesely at tana.it (Alessandro Vesely)
Date: Mon, 12 Jun 2023 18:45:37 +0200
Subject: OT: DKIM signatures on email messages from lists.gnupg.org
In-Reply-To: <20230612130551.Horde.ah8LbiWcJfdmZWg8d0HXXeW@webmail.leidinger.net>
References: <20230612130551.Horde.ah8LbiWcJfdmZWg8d0HXXeW@webmail.leidinger.net>
Message-ID: <3d8acfd7-5d24-713b-fce4-05ac798e92cc@tana.it>

On Mon 12/Jun/2023 13:05:51 +0200 Alexander Leidinger via Gnupg-users wrote:
> Quoting Alessandro Vesely via Gnupg-users <gnupg-users at 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 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.


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








From konstantin at linuxfoundation.org  Mon Jun 12 21:24:54 2023
From: konstantin at linuxfoundation.org (Konstantin Ryabitsev)
Date: Mon, 12 Jun 2023 15:24:54 -0400
Subject: OT: DKIM signatures on email messages from lists.gnupg.org
In-Reply-To: <3d8acfd7-5d24-713b-fce4-05ac798e92cc@tana.it>
References: <20230612130551.Horde.ah8LbiWcJfdmZWg8d0HXXeW@webmail.leidinger.net>
 <3d8acfd7-5d24-713b-fce4-05ac798e92cc@tana.it>
Message-ID: <20230612-landline-jawless-f2c113@meerkat>

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


From steffen at sdaoden.eu  Mon Jun 12 21:54:45 2023
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Mon, 12 Jun 2023 21:54:45 +0200
Subject: OT: DKIM signatures on email messages from
 lists.gnupg.org
In-Reply-To: <20230612-landline-jawless-f2c113@meerkat>
References: <20230612130551.Horde.ah8LbiWcJfdmZWg8d0HXXeW@webmail.leidinger.net>
 <3d8acfd7-5d24-713b-fce4-05ac798e92cc@tana.it>
 <20230612-landline-jawless-f2c113@meerkat>
Message-ID: <20230612195445.ivVrA%steffen@sdaoden.eu>

Konstantin Ryabitsev wrote in
 <20230612-landline-jawless-f2c113 at 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


From konstantin at linuxfoundation.org  Mon Jun 12 22:06:24 2023
From: konstantin at linuxfoundation.org (Konstantin Ryabitsev)
Date: Mon, 12 Jun 2023 16:06:24 -0400
Subject: OT: DKIM signatures on email messages from lists.gnupg.org
In-Reply-To: <20230612195445.ivVrA%steffen@sdaoden.eu>
References: <20230612130551.Horde.ah8LbiWcJfdmZWg8d0HXXeW@webmail.leidinger.net>
 <3d8acfd7-5d24-713b-fce4-05ac798e92cc@tana.it>
 <20230612-landline-jawless-f2c113@meerkat>
 <20230612195445.ivVrA%steffen@sdaoden.eu>
Message-ID: <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.

> 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


From steffen at sdaoden.eu  Mon Jun 12 22:41:42 2023
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Mon, 12 Jun 2023 22:41:42 +0200
Subject: OT: DKIM signatures on email messages from
 lists.gnupg.org
In-Reply-To: <20230612-rename-satirical-b8339e@meerkat>
References: <20230612130551.Horde.ah8LbiWcJfdmZWg8d0HXXeW@webmail.leidinger.net>
 <3d8acfd7-5d24-713b-fce4-05ac798e92cc@tana.it>
 <20230612-landline-jawless-f2c113@meerkat>
 <20230612195445.ivVrA%steffen@sdaoden.eu>
 <20230612-rename-satirical-b8339e@meerkat>
Message-ID: <20230612204142.EQdgz%steffen@sdaoden.eu>

Konstantin Ryabitsev wrote in
 <20230612-rename-satirical-b8339e at 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


From Alexander at leidinger.net  Tue Jun 13 08:46:06 2023
From: Alexander at leidinger.net (Alexander Leidinger)
Date: Tue, 13 Jun 2023 08:46:06 +0200
Subject: OT: DKIM signatures on email messages from lists.gnupg.org
In-Reply-To: <3d8acfd7-5d24-713b-fce4-05ac798e92cc@tana.it>
References: <20230612130551.Horde.ah8LbiWcJfdmZWg8d0HXXeW@webmail.leidinger.net>
 <3d8acfd7-5d24-713b-fce4-05ac798e92cc@tana.it>
Message-ID: <20230613084606.Horde.JLeQXeqyLtPvYqNoOszsw2i@webmail.leidinger.net>

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>

From wk at gnupg.org  Tue Jun 13 09:02:31 2023
From: wk at gnupg.org (Werner Koch)
Date: Tue, 13 Jun 2023 09:02:31 +0200
Subject: OT: DKIM signatures on email messages from lists.gnupg.org
In-Reply-To: <20230612-landline-jawless-f2c113@meerkat> (Konstantin Ryabitsev
 via Gnupg-users's message of "Mon, 12 Jun 2023 15:24:54 -0400")
References: <20230612130551.Horde.ah8LbiWcJfdmZWg8d0HXXeW@webmail.leidinger.net>
 <3d8acfd7-5d24-713b-fce4-05ac798e92cc@tana.it>
 <20230612-landline-jawless-f2c113@meerkat>
Message-ID: <87wn07sv3s.fsf@wheatstone.g10code.de>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230613/e1bb3ea7/attachment.sig>

From Alexander at leidinger.net  Tue Jun 13 09:18:39 2023
From: Alexander at leidinger.net (Alexander Leidinger)
Date: Tue, 13 Jun 2023 09:18:39 +0200
Subject: OT: DKIM signatures on email messages from lists.gnupg.org
In-Reply-To: <20230612195445.ivVrA%steffen@sdaoden.eu>
References: <20230612130551.Horde.ah8LbiWcJfdmZWg8d0HXXeW@webmail.leidinger.net>
 <3d8acfd7-5d24-713b-fce4-05ac798e92cc@tana.it>
 <20230612-landline-jawless-f2c113@meerkat>
 <20230612195445.ivVrA%steffen@sdaoden.eu>
Message-ID: <20230613091839.Horde.xOmd2-klk1PTncda-lgsFUI@webmail.leidinger.net>

Quoting Steffen Nurpmeso <steffen at sdaoden.eu> (from Mon, 12 Jun 2023  
21:54:45 +0200):

> Konstantin Ryabitsev wrote in
>  <20230612-landline-jawless-f2c113 at 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 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/132d13c0/attachment-0001.sig>

From Alexander at leidinger.net  Tue Jun 13 09:26:06 2023
From: Alexander at leidinger.net (Alexander Leidinger)
Date: Tue, 13 Jun 2023 09:26:06 +0200
Subject: OT: DKIM signatures on email messages from lists.gnupg.org
In-Reply-To: <87wn07sv3s.fsf@wheatstone.g10code.de>
References: <20230612130551.Horde.ah8LbiWcJfdmZWg8d0HXXeW@webmail.leidinger.net>
 <3d8acfd7-5d24-713b-fce4-05ac798e92cc@tana.it>
 <20230612-landline-jawless-f2c113@meerkat>
 <87wn07sv3s.fsf@wheatstone.g10code.de>
Message-ID: <20230613092606.Horde.u_HTnL1h8f6JZmieKmhOEot@webmail.leidinger.net>

Quoting Werner Koch via Gnupg-users <gnupg-users at 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 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/e3945135/attachment.sig>

From vesely at tana.it  Tue Jun 13 09:49:30 2023
From: vesely at tana.it (Alessandro Vesely)
Date: Tue, 13 Jun 2023 09:49:30 +0200
Subject: OT: DKIM signatures on email messages from lists.gnupg.org
In-Reply-To: <20230613092606.Horde.u_HTnL1h8f6JZmieKmhOEot@webmail.leidinger.net>
References: <20230612130551.Horde.ah8LbiWcJfdmZWg8d0HXXeW@webmail.leidinger.net>
 <3d8acfd7-5d24-713b-fce4-05ac798e92cc@tana.it>
 <20230612-landline-jawless-f2c113@meerkat>
 <87wn07sv3s.fsf@wheatstone.g10code.de>
 <20230613092606.Horde.u_HTnL1h8f6JZmieKmhOEot@webmail.leidinger.net>
Message-ID: <91b49b86-84df-1d89-48d0-fe1fe0bbb873@tana.it>

On Tue 13/Jun/2023 09:26:06 +0200 Alexander Leidinger via Gnupg-users wrote:
> Quoting Werner Koch via Gnupg-users <gnupg-users at 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
-- 







From vesely at tana.it  Tue Jun 13 09:49:44 2023
From: vesely at tana.it (Alessandro Vesely)
Date: Tue, 13 Jun 2023 09:49:44 +0200
Subject: OT: DKIM signatures on email messages from lists.gnupg.org
In-Reply-To: <20230612-landline-jawless-f2c113@meerkat>
References: <20230612130551.Horde.ah8LbiWcJfdmZWg8d0HXXeW@webmail.leidinger.net>
 <3d8acfd7-5d24-713b-fce4-05ac798e92cc@tana.it>
 <20230612-landline-jawless-f2c113@meerkat>
Message-ID: <67c312ac-51b1-31d0-6733-b84bda62761a@tana.it>

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











From vesely at tana.it  Tue Jun 13 11:19:02 2023
From: vesely at tana.it (Alessandro Vesely)
Date: Tue, 13 Jun 2023 11:19:02 +0200
Subject: OT: DKIM signatures on email messages from lists.gnupg.org
In-Reply-To: <20230613084606.Horde.JLeQXeqyLtPvYqNoOszsw2i@webmail.leidinger.net>
References: <20230612130551.Horde.ah8LbiWcJfdmZWg8d0HXXeW@webmail.leidinger.net>
 <3d8acfd7-5d24-713b-fce4-05ac798e92cc@tana.it>
 <20230613084606.Horde.JLeQXeqyLtPvYqNoOszsw2i@webmail.leidinger.net>
Message-ID: <5e1c0b49-a4ac-a0e5-5771-be6eeeede52d@tana.it>

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







From wk at gnupg.org  Tue Jun 13 11:40:39 2023
From: wk at gnupg.org (Werner Koch)
Date: Tue, 13 Jun 2023 11:40:39 +0200
Subject: OT: DKIM signatures on email messages from lists.gnupg.org
In-Reply-To: <20230613084606.Horde.JLeQXeqyLtPvYqNoOszsw2i@webmail.leidinger.net>
 (Alexander Leidinger via Gnupg-users's message of "Tue, 13 Jun 2023
 08:46:06 +0200")
References: <20230612130551.Horde.ah8LbiWcJfdmZWg8d0HXXeW@webmail.leidinger.net>
 <3d8acfd7-5d24-713b-fce4-05ac798e92cc@tana.it>
 <20230613084606.Horde.JLeQXeqyLtPvYqNoOszsw2i@webmail.leidinger.net>
Message-ID: <87sfavsns8.fsf@wheatstone.g10code.de>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230613/fa7daa75/attachment.sig>

From vesely at tana.it  Tue Jun 13 11:54:19 2023
From: vesely at tana.it (Alessandro Vesely)
Date: Tue, 13 Jun 2023 11:54:19 +0200
Subject: OT: DKIM signatures on email messages from lists.gnupg.org
In-Reply-To: <87sfavsns8.fsf@wheatstone.g10code.de>
References: <20230612130551.Horde.ah8LbiWcJfdmZWg8d0HXXeW@webmail.leidinger.net>
 <3d8acfd7-5d24-713b-fce4-05ac798e92cc@tana.it>
 <20230613084606.Horde.JLeQXeqyLtPvYqNoOszsw2i@webmail.leidinger.net>
 <87sfavsns8.fsf@wheatstone.g10code.de>
Message-ID: <fa9daeab-6254-e3b3-263d-183c788fd159@tana.it>

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







From Alexander at leidinger.net  Tue Jun 13 13:02:09 2023
From: Alexander at leidinger.net (Alexander Leidinger)
Date: Tue, 13 Jun 2023 13:02:09 +0200
Subject: OT: DKIM signatures on email messages from lists.gnupg.org
In-Reply-To: <5e1c0b49-a4ac-a0e5-5771-be6eeeede52d@tana.it>
References: <20230612130551.Horde.ah8LbiWcJfdmZWg8d0HXXeW@webmail.leidinger.net>
 <3d8acfd7-5d24-713b-fce4-05ac798e92cc@tana.it>
 <20230613084606.Horde.JLeQXeqyLtPvYqNoOszsw2i@webmail.leidinger.net>
 <5e1c0b49-a4ac-a0e5-5771-be6eeeede52d@tana.it>
Message-ID: <20230613130209.Horde.P6sVK6DhJORNsvRI9_S7I6P@webmail.leidinger.net>

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>

From steffen at sdaoden.eu  Tue Jun 13 16:43:00 2023
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Tue, 13 Jun 2023 16:43:00 +0200
Subject: OT: DKIM signatures on email messages from
 lists.gnupg.org
In-Reply-To: <20230613091839.Horde.xOmd2-klk1PTncda-lgsFUI@webmail.leidinger.net>
References: <20230612130551.Horde.ah8LbiWcJfdmZWg8d0HXXeW@webmail.leidinger.net>
 <3d8acfd7-5d24-713b-fce4-05ac798e92cc@tana.it>
 <20230612-landline-jawless-f2c113@meerkat>
 <20230612195445.ivVrA%steffen@sdaoden.eu>
 <20230613091839.Horde.xOmd2-klk1PTncda-lgsFUI@webmail.leidinger.net>
Message-ID: <20230613144300.x7JyA%steffen@sdaoden.eu>

Alexander Leidinger wrote in
 <20230613091839.Horde.xOmd2-klk1PTncda-lgsFUI at webmail.leidinger.net>:
 |Quoting Steffen Nurpmeso <steffen at 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


From vesely at tana.it  Tue Jun 13 19:56:38 2023
From: vesely at tana.it (Alessandro Vesely)
Date: Tue, 13 Jun 2023 19:56:38 +0200
Subject: OT: DKIM signatures on email messages from lists.gnupg.org
In-Reply-To: <20230613130209.Horde.P6sVK6DhJORNsvRI9_S7I6P@webmail.leidinger.net>
References: <20230612130551.Horde.ah8LbiWcJfdmZWg8d0HXXeW@webmail.leidinger.net>
 <3d8acfd7-5d24-713b-fce4-05ac798e92cc@tana.it>
 <20230613084606.Horde.JLeQXeqyLtPvYqNoOszsw2i@webmail.leidinger.net>
 <5e1c0b49-a4ac-a0e5-5771-be6eeeede52d@tana.it>
 <20230613130209.Horde.P6sVK6DhJORNsvRI9_S7I6P@webmail.leidinger.net>
Message-ID: <8fe44a06-cb26-db9b-bf9a-8251baf560b4@tana.it>

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/







From steffen at sdaoden.eu  Tue Jun 13 23:50:03 2023
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Tue, 13 Jun 2023 23:50:03 +0200
Subject: OT: DKIM signatures on email messages from
 lists.gnupg.org
In-Reply-To: <8fe44a06-cb26-db9b-bf9a-8251baf560b4@tana.it>
References: <20230612130551.Horde.ah8LbiWcJfdmZWg8d0HXXeW@webmail.leidinger.net>
 <3d8acfd7-5d24-713b-fce4-05ac798e92cc@tana.it>
 <20230613084606.Horde.JLeQXeqyLtPvYqNoOszsw2i@webmail.leidinger.net>
 <5e1c0b49-a4ac-a0e5-5771-be6eeeede52d@tana.it>
 <20230613130209.Horde.P6sVK6DhJORNsvRI9_S7I6P@webmail.leidinger.net>
 <8fe44a06-cb26-db9b-bf9a-8251baf560b4@tana.it>
Message-ID: <20230613215003.V_sMR%steffen@sdaoden.eu>

Alessandro Vesely wrote in
 <8fe44a06-cb26-db9b-bf9a-8251baf560b4 at 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


From kloecker at kde.org  Tue Jun 13 22:34:03 2023
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Tue, 13 Jun 2023 22:34:03 +0200
Subject: OT: DKIM signatures on email messages from lists.gnupg.org
In-Reply-To: <8fe44a06-cb26-db9b-bf9a-8251baf560b4@tana.it>
References: <20230612130551.Horde.ah8LbiWcJfdmZWg8d0HXXeW@webmail.leidinger.net>
 <20230613130209.Horde.P6sVK6DhJORNsvRI9_S7I6P@webmail.leidinger.net>
 <8fe44a06-cb26-db9b-bf9a-8251baf560b4@tana.it>
Message-ID: <4813010.GXAFRqVoOG@daneel>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230613/80b51ac1/attachment.sig>

From Alexander at leidinger.net  Wed Jun 14 08:54:41 2023
From: Alexander at leidinger.net (Alexander Leidinger)
Date: Wed, 14 Jun 2023 08:54:41 +0200
Subject: OT: DKIM signatures on email messages from lists.gnupg.org
In-Reply-To: <8fe44a06-cb26-db9b-bf9a-8251baf560b4@tana.it>
References: <20230612130551.Horde.ah8LbiWcJfdmZWg8d0HXXeW@webmail.leidinger.net>
 <3d8acfd7-5d24-713b-fce4-05ac798e92cc@tana.it>
 <20230613084606.Horde.JLeQXeqyLtPvYqNoOszsw2i@webmail.leidinger.net>
 <5e1c0b49-a4ac-a0e5-5771-be6eeeede52d@tana.it>
 <20230613130209.Horde.P6sVK6DhJORNsvRI9_S7I6P@webmail.leidinger.net>
 <8fe44a06-cb26-db9b-bf9a-8251baf560b4@tana.it>
Message-ID: <20230614085441.Horde.qMIl9NeiHJxIvEJT1vPGEmD@webmail.leidinger.net>

Quoting Alessandro Vesely <vesely at 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 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.

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 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/20230614/d227fb1a/attachment-0001.sig>

From aheinecke at gnupg.org  Wed Jun 14 10:22:36 2023
From: aheinecke at gnupg.org (Andre Heinecke)
Date: Wed, 14 Jun 2023 10:22:36 +0200
Subject: get OpenPGP pubkeys authenticated using German personal ID
In-Reply-To: <202305311655.13811.bernhard@intevation.de>
References: <202305311655.13811.bernhard@intevation.de>
Message-ID: <2151432.irdbgypaU6@teutates>

Hi,

On Wednesday, 31 May 2023 16:55:05 CEST Bernhard Reiter wrote:
> https://pgp.governikus.de/?lang=EN
> 
> """
> Governikus provides the online service for authenticating your OpenPGP key 
on 
> behalf of the German Federal Office for Information Security (BSI). This 
> online service compares the name read from your ID card, your electronic 
> residence permit or eID card for citizens of the European Union with the 
name 
> specified in your OpenPGP key. If the names match, your public key is 
> electronically signed by Governikus, confirming the match. 
> """
> 
> interesting, kind of cool.

Cool, I was thinking about setting something like this up myself as I would 
love to use my ID card more.

But damn this website has bad usability. I am using the AusweisApp on my 
Smartphone and used it in the past to sign PDFs using an online service. But 
that website just says "To continue use AusweisApp2" even if I open the 
website with my smartphone. The button has no functionality. It does nothing.

Okay... Then how the hell do I open it. When I go to the download site, of 
course there is no option for Linux. So lets boot a Windows VM and install the 
software.

Which of course requires root access and wants to open up my windows firewall. 
Sure! I trust the Government! Here you go.

Then I start the Windows App and it wants to connect either to the smartphone 
or to an NFC reader. The option to connect to a smartphone is not shown, 
because apparently as they need to be in the same WLAN it is not offered to 
connect them because the VM, which is running on my Laptop in the same WLAN 
does not see it as WLAN but as a network.

So I failed for now.

And the link to the website how to get a PGP Software linking to that fishy 
"openpgp.org" website which lists Gpg4win as "Outlook software" on the same 
level with Gpg4o? And which links to Claws mail as PGP software to get a Key? 
WTF.. has no one even checked how a user with no technical understanding 
should navigate this? I mean would 2-3 Screenshots how to generate a PGP key 
be too much to ask instead of loosing the user on a confusing website that 
lists PGP Mail clients? 


Sorry for the rant but this is typical contracted Government Software which 
might follow some "Contractual requirements" but from the User Experience this 
comes close to a scam. I don't understand why I can't use this site on my 
phone which has the AusweisApp and everything works there. I can't use it in a 
VM. Maybe when I use my native Windows I could use it. I don't know...


Best Regards,
Andre
-- 
GnuPG.com - a brand of g10 Code, the GnuPG experts.

g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459
GF Werner Koch, USt-Id DE215605608, www.g10code.com.

GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf.  VR 11482 D?sseldorf
Vorstand: W.Koch, B.Reiter, A.Heinecke        Mail: board at gnupg.org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779.   Tel: +49-211-28010702
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 5655 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230614/10a58cc3/attachment.sig>

From neal at walfield.org  Wed Jun 14 10:44:57 2023
From: neal at walfield.org (Neal H. Walfield)
Date: Wed, 14 Jun 2023 10:44:57 +0200
Subject: get OpenPGP pubkeys authenticated using German personal ID
In-Reply-To: <2151432.irdbgypaU6@teutates>
References: <202305311655.13811.bernhard@intevation.de>
 <2151432.irdbgypaU6@teutates>
Message-ID: <87r0qe1lh2.wl-neal@walfield.org>

On Wed, 14 Jun 2023 10:22:36 +0200,
Andre Heinecke via Gnupg-users wrote:
> And the link to the website how to get a PGP Software linking to that fishy 
> "openpgp.org" website which lists Gpg4win as "Outlook software" on the same 
> level with Gpg4o? And which links to Claws mail as PGP software to get a Key? 
> WTF.. has no one even checked how a user with no technical understanding 
> should navigate this? I mean would 2-3 Screenshots how to generate a PGP key 
> be too much to ask instead of loosing the user on a confusing website that 
> lists PGP Mail clients? 

What do you mean by fishy?  openpgp.org is maintained as a community
project by Dominik, one of the developers of Open Keychain.  Anyone
can suggest improvements, and 159 people have contributed over the
years.

  https://github.com/OpenPGP/openpgp.org/graphs/contributors

That hardly seems to be shady or suspicious.

I don't disagree that the text could use improvement.

Neal


From christoph.klassen at intevation.de  Wed Jun 14 16:25:19 2023
From: christoph.klassen at intevation.de (Christoph Klassen)
Date: Wed, 14 Jun 2023 16:25:19 +0200
Subject: expiration date for the keys pgp (automatism)
In-Reply-To: <202306091037.32867.bernhard@intevation.de>
References: <20230601132336.Horde.kTnbuuxrOgs5IKjYyK1K6w6@webmail.leidinger.net>
 <647A8FAF.8070001@gmail.com>
 <1102499875.5129057.1685976595943@mail.yahoo.com>
 <202306091037.32867.bernhard@intevation.de>
Message-ID: <9cb1d7ae-eeae-921d-7a73-e9f5c1718ce7@intevation.de>

Hi Marc,

On 09.06.23 10:37, Bernhard Reiter wrote:
> Another option would be to use GPGME which somehow is the official API
> to access GnuPG functionality and usually more stable than parsing the output
> yourself in a shell.
> 
> E.g. you can use python, see https://wiki.gnupg.org/APIs .
as Bernhard explained you could also use a Python script. Here is one 
you could use for a start: 
https://heptapod.host/intevation/gnupg-scripts/-/blob/main/Python/list_expired_keys.py

Kind regards,
Christoph

-- 
Christoph Klassen | https://intevation.de
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230614/43140840/attachment.sig>

From Alexander at leidinger.net  Thu Jun 15 09:08:26 2023
From: Alexander at leidinger.net (Alexander Leidinger)
Date: Thu, 15 Jun 2023 09:08:26 +0200
Subject: get OpenPGP pubkeys authenticated using German personal ID
In-Reply-To: <2151432.irdbgypaU6@teutates>
References: <202305311655.13811.bernhard@intevation.de>
 <2151432.irdbgypaU6@teutates>
Message-ID: <20230615090826.Horde.OCT9rmG-E4uljJkQv5GTGqB@webmail.leidinger.net>

Quoting Andre Heinecke via Gnupg-users <gnupg-users at gnupg.org> (from  
Wed, 14 Jun 2023 10:22:36 +0200):

> Then I start the Windows App and it wants to connect either to the smartphone
> or to an NFC reader. The option to connect to a smartphone is not shown,
> because apparently as they need to be in the same WLAN it is not offered to
> connect them because the VM, which is running on my Laptop in the same WLAN
> does not see it as WLAN but as a network.

The Windows PC I used with the AusweisApp was connected via cable and  
it worked. The WLAN and the cable network are in the same /24 range in  
my case. So your problem was caused by something else than what you  
thought.
I haven't done a packet trace, but I assume they do a broadcast  
message in the local network, so if your VM is in e.g. a NATted  
10.0.0.x/24 and your linux PC in 192.168.1.y/24, it will not work.

You can give it a try without going through the website.
     https://www.ausweisapp.bund.de/faq#c294

There's also a video tutorial, it seems:
     https://www.ausweisapp.bund.de/videotutorials

Some basic connection validation can be done via "Ger?t und Ausweis  
pr?fen". Once this works you could try "Meine Daten einsehen".

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/20230615/0e7518ad/attachment.sig>

From wk at gnupg.org  Thu Jun 15 11:14:27 2023
From: wk at gnupg.org (Werner Koch)
Date: Thu, 15 Jun 2023 11:14:27 +0200
Subject: get OpenPGP pubkeys authenticated using German personal ID
In-Reply-To: <20230615090826.Horde.OCT9rmG-E4uljJkQv5GTGqB@webmail.leidinger.net>
 (Alexander Leidinger via Gnupg-users's message of "Thu, 15 Jun 2023
 09:08:26 +0200")
References: <202305311655.13811.bernhard@intevation.de>
 <2151432.irdbgypaU6@teutates>
 <20230615090826.Horde.OCT9rmG-E4uljJkQv5GTGqB@webmail.leidinger.net>
Message-ID: <87fs6tqe8c.fsf@wheatstone.g10code.de>

On Thu, 15 Jun 2023 09:08, Alexander Leidinger said:

> The Windows PC I used with the AusweisApp was connected via cable and
> it worked. The WLAN and the cable network are in the same /24 range in

WLAN and Ethernet should never share the same network.  This is
something such a service should have taken into consideration.


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230615/61ba14d9/attachment.sig>

From rra24 at med.miami.edu  Fri Jun 16 19:50:43 2023
From: rra24 at med.miami.edu (Alberti, Rafael Ricardo)
Date: Fri, 16 Jun 2023 17:50:43 +0000
Subject: Question - GPG - No Secret Keys
Message-ID: <BN7PR07MB50909452B7DF7C75BB4901F4E458A@BN7PR07MB5090.namprd07.prod.outlook.com>

Hi Gpg Developers

On May 15 2023, we installed and were looking at using GPG a server.   We created  the proper Public and Private key and Pass Phrase.   The decryption and encryption was working well for a few weeks until on June 13, 2023 the decryption failed.

Upon review, we received a "No Secret Key" error - nothing changed on the machine.  We also noticed that the Public and Private key were no longer visible in the armor i.e.  Gpg -list-keys    {returned blank}

What would cause the keys to be removed?    We did notice that an install of GPG occurred on the server on June 13.

Can a GPG Auto Update remove the Keys inside the Armor ?    If so, how can we disable GPG Auto Update feature

After much review,  and  "by chance"  we re-imported the Public.key and the TrustDb.Key and the Armor was repopulated with the old Key information and the decryption started to work again

Any advise or information is appreciated

Thank you
Rafael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230616/dc8313b2/attachment-0001.html>