On Tue 13/Jun/2023 08:46:06 +0200 Alexander Leidinger via Gnupg-users wrote:
Quoting Alessandro Vesely via Gnupg-users <gnupg-users@gnupg.org> (from Mon, 12
Jun 2023 18:45:37 +0200):
The From was re-written be the list and as such the header check fails. The
body check fails as the list adds the following:
---snip---
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
---snip---
The message verifies after removing the footer. It can be done routinely, on
some kind of signatures.
DKIM doesn't specify an automatic removal of a signature. So I postulate there
is no DKIM related tool which does this (only home-grown solutions which need
to be specially tailored to the sender as you don't know in
advance/automatically if a signature has to be stripped or not, and you can not
rely on the way the signature is added, as even this list does not use the age
old de-facto standard (which was ignored by big corporations like they did with
some other de-facto standards) of "-- " on it's own line as a signature
separator).
http://www.tana.it/sw/zdkimfilter/zdkimfilter.html#mlmtrans for one.
You may call it home grown, but it's not tailored to a specific sender. Of
course it doesn't work on /every/ signature. Yours, for instance, didn't
verify. Gmail's signatures, by contrast, verify across most mailing lists.
What the list-software would need to do is to strip the original DKIM signature
Why? Original signatures can often be recovered. They shouldn't be removed
anyway.
Already answered by Alessandro, but to add to that: any munging with the
message (no matter if header or body) invalidates the DKIM signature. If the
munging is done on purpose, the DKIM message has to be removed to prevent
DKIM-policy=discard setups to lose the message (some people may say this would
be on purpose / as designed, and I can agree to that, but the intend of this
list here is surely not to discard such messages).
I assume you mean the DKIM signature has to be removed, not the DKIM message.
As I said, it's not true.
(and maybe sign itself, but there are drawbacks),
What drawback can there be to signing? CPU resource consumption?
If the list signs the message itself due to the rewritten From:-header, it
would sign spam-messages which slip through the anti-spam setup of this list.
So it would defeat what it is supposed to do, prevent SPAM from arriving in
your inbox . It would also either discredit the reputation of the list, or
increase the reputation (for a while) of the SPAM message in some big anti-spam
setups which use sender-reputation and message-hashes to rate the SPAMiness of
messages.
Camouflage is not a good anti-spam technique, IMHO. A sane list's subscribers
want list messages, and their mailbox provider must be an inept if it degrades
the list reputation because of occasional uncaught spam.
However, as ARC's specifications, unlike DKIM's, mention no responsibility,
some mailers use this instead of DKIM —more on forwarding than on mailing
lists, IME.
Mailing lists are enjoying an incredibly low rate of fraud. It is enough to
impersonate a subscriber to have your message pass, failing authentications
notwithstanding. Yet it doesn't happen any often. Sooner or later they'll
have to enforce authentication checks on entry themselves.
or to not modify the message (at least not the designated header lines, and
the body). More info here:
https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html
Omitting subject tag and footer seems to me to be worse than From: munging.
My filter setup doesn't depend on a footer or subject tag. The world has
advanced way past a subject tag or a footer to be able to identify a
mailinglist. Any search engine is quite good at finding a webpage related to
the list (last line of the signature in this list) and I don't need the email
address of the list itself in the footer (it's in the header anyway as the TO
or CC). The first content-line of the signature I don't need either. All the
info there is either redundant or useless to me when I'm already subscribed.
This list also has no subject tag. Seems we can live without it. As we are
talking about the DKIM issues this list has, I only talk about this list, and I
don't care how other lists handle this.
Some admins derive the need to put a footer from legal requirements.
Subject tags are just handy for the eye. I too sort mailing list messages in
various folders, but I don't have a folder for each list.
Munged From:s can sometimes be restored.
See also this:
https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail
You can not expect all subscribers of the list to change their DKIM settings to
a more relaxed way or other sending side related stuff. This may not be in the
influence of the person (try to get google to change their dkim settings for
gmail). As such it is up to the list owner to be a nice netticen. If the list
owner(s) insists on message-munging, that's fine, but in this case the list
owner(s) has to remove DKIM signatures if they want to have the message
delivered correctly for the DKIM-policy=discard case. Any other action which
needs involvement of the receiver or the sender will not work in the generic
case (and I consider this list to fall into the generic case).
"mailing_list" is one of the provided policy override cases for DMARC. RFC
7489 describes it like so:
mailing_list: Local heuristics determined that the message arrived
via a mailing list, and thus authentication of the original
message was not expected to succeed.
See also BCP 167. BTW, discard was ADSP parlance; there is no "DKIM-policy".
There is also ARC (which you should see in the headers of my mail):
https://en.wikipedia.org/wiki/Authenticated_Received_Chain
I'd definitely recommend ARC, not the conceptual Mailman 3 version. However,
most receivers are not yet prepared to accept it.
ARC has advantages and drawbacks. One drawback is that it relies on a
trust-chain. Only few places have an explicit trust-chain (Microsoft seems to
allow to configure one in their cloud offering). It is an additional tool in
the SPF/DKIM/DMARC/... world, but not a golden solution, and it will not solve
the problem of failing DKIM signatures of this list because of message-munging.
That's right. As it is, ARC is only useful to global mailbox providers who can
afford to categorize all (global) ARC sealers. To become useful to small
providers, it needs to be deployed in some kind of cooperative solution.
Best
Ale
--
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
