Hi Adrian,

On 07.06.23 21:33, Adrian Ulrich via swinog wrote:

...

I'm pretty surprised that of the 1.7M domains with an MX record, only 57% have DKIM

I don't see how one could reliability gather this data from DNS:

DKIM allows you to specify a selector in the header of the mail: This mail for example will use 'sx1' as the selector (check out the header ;-) ):

...

$ dig +short txt sx1._domainkey.blinkenlights.ch "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC[....]

But without ever receiving a mail from me: how would you know?

You could try to send a query for '_domainkey.blinkenlights.ch' and you MAY receive a NOERROR reply - but that's not guaranteed: My DNS will just return an NXDOMAIN:

...

$ dig txt _domainkey.blinkenlights.ch|grep status: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10153

Your nameserver breaks https://www.rfc-editor.org/rfc/rfc8020

This document states clearly that when a DNS resolver receives a response with a response code of NXDOMAIN, it means that the domain name which is thus denied AND ALL THE NAMES UNDER IT do not exist.

Daniel

Hi Franco, Dear List

Thank you for your feedback.

1) I configured mailman3 [1] dmarc_mitigate_action to "munge_from" (to replace the from header) and dmarc_mitigate_unconditionally to true. My thought was that this would mean that there can no longer be a dmarc policy which sets dkim to strict. This way, an invalid dkim signature would no longer be such a big problem. But I was probably wrong. I don't want to set up the mails to be re-signed overnight, maybe there is an option to remove the signature. If anyone has experience with mailman3 and dkim, please write to me directly.

2) The SPF RR was a bit of a back and forth. I sent an email to the person who manages swinog.ch on 2023-05-10 to replace the : with a =. However, the email seems to have been forgotten or lost and I also forgot to ask again. I will do that today.

Jonas

[1]: https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/do...

On 6/8/23 08:24, Franco Hug via swinog wrote:

Hi swinog / init7

Thanks @adrian for the report and @daniel for pointing out the NXDOMAIN issue.

Maybe this is well-known, but I would like to point out that this swinog list has a problem with DKIM and SPF.

1. DKIM: not valid ("message has been altered") because of the email forwarding without re-signing

2. SPF: wrong record

...

Authentication-Results: opendkim.logging.ch; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=switch.ch header.b=qiNTrxHE Received-SPF: permerror (lists.swinog.ch: Unknown mechanism type 'redirect' in 'v=spf1' record) receiver=mx3.logging.ch; identity=mailfrom; envelope-from="swinog-bounces@lists.swinog.ch"; helo=vmaill01.sys.init7.net; client-ip=82.197.188.230 Received: from vmaill01.sys.init7.net (vmaill01.sys.init7.net [82.197.188.230])

SPF misconfiguration:

...

dig +short lists.swinog.ch txt "v=spf1 redirect:init7.net"

The correct record should read as:

...

"v=spf1 redirect=init7.net"

See https://www.rfc-editor.org/rfc/rfc7208#section-6.1

While 2) would be an easy fix, 1) might involve some more work.

My 2 cents - Gruass, Franco

On 08.06.23 07:42, Daniel Stirnimann via swinog wrote:

...

Hi Adrian,

On 07.06.23 21:33, Adrian Ulrich via swinog wrote:

...

...

I'm pretty surprised that of the 1.7M domains with an MX record, only 57% have DKIM

I don't see how one could reliability gather this data from DNS:

DKIM allows you to specify a selector in the header of the mail: This mail for example will use 'sx1' as the selector (check out the header ;-) ):

...

$ dig +short txt sx1._domainkey.blinkenlights.ch "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC[....]

But without ever receiving a mail from me: how would you know?

You could try to send a query for '_domainkey.blinkenlights.ch' and you MAY receive a NOERROR reply - but that's not guaranteed: My DNS will just return an NXDOMAIN:

...

$ dig txt _domainkey.blinkenlights.ch|grep status: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10153

Your nameserver breaks https://www.rfc-editor.org/rfc/rfc8020

This document states clearly that when a DNS resolver receives a    response with a response code of NXDOMAIN, it means that the domain    name which is thus denied AND ALL THE NAMES UNDER IT do not exist.

Daniel _______________________________________________ swinog mailing list -- swinog@lists.swinog.ch To unsubscribe send an email to swinog-leave@lists.swinog.ch

---

swinog mailing list -- swinog@lists.swinog.ch To unsubscribe send an email to swinog-leave@lists.swinog.ch

Noting.... you do part of this already.

But..... note this nasty effect:

--- From: Jonas Meier via swinog swinog@lists.swinog.ch Reply-To: Jonas Meier meier@init7.net ---

Now add that to people having "automatically add recipient to addressbook" and when one wants to send an email to Jonas... it autocompletes to the public list ;)

Mailman3 does not do the @via trick yet unfortunately; hence why folks use custom remailers quite often :)

Greets, Jeroen

On 8 Jun 2023, at 12:06, Jeroen Massar jeroen@massar.ch wrote:

...

On 8 Jun 2023, at 11:47, Jonas Meier via swinog swinog@lists.swinog.ch wrote:

Hi Franco, Dear List

Thank you for your feedback.

1. I configured mailman3 [1] dmarc_mitigate_action to "munge_from" (to replace the from header) and dmarc_mitigate_unconditionally to true. My thought was that this would mean that there can no longer be a dmarc policy which sets dkim to strict. This way, an invalid dkim signature would no longer be such a big problem. But I was probably wrong. I don't want to set up the mails to be re-signed overnight, maybe there is an option to remove the signature. If anyone has experience with mailman3 and dkim, please write to me directly.

The only real solution is effectively to do SRS aka "From Rewriting" to be able to decently send emails through a mailinglist and have them not land up in spam/junk...

The list has to remove the Original "From" and replace it with eg jeroen+massar.ch@via.lists.swinog mailto:jeroen+massar.ch@via.lists.swinog.ch Then you sign that From with your DKIM key.

To make the receiver happy that there is the 'old' DKIM header you then need to do ARC signingt: http://arc-spec.org/ That way, a receiver knows "oh the rewrote something and they are taking responsibility for this mail"

For Mailman there is some info here: https://wiki.list.org/DEV/DMARC

Thus the option you need to do is:

"Munge the From: header" some other details: https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/do...

For ARC: https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/do...

Greets, Jeroen

Hi Daniel,

Your nameserver breaks https://www.rfc-editor.org/rfc/rfc8020

I'd rather say 'does not implement' instead of 'break': As RFC 8020 points out, the (almost 30 years older) RFC 1034 is very unspecific about the details on how a nameserver should behave in such a situation. (And opinions seem to have changed over time, see https://groups.google.com/g/comp.protocols.dns.std/c/j0ddY0jZhog/m/yHN9ew5Q5...)

Therefore, there *are* existing implementations which do seem to return NXDOMAIN in such cases - probably because their implementation predates RFC8020, one of them being AWS / Route53:

Example:

$ dig txt mv2jefm7mwexbuk5zvfgdg5yzcylqkwc._domainkey.just-eat.ch

Returns the expected data while

$ dig txt _domainkey.just-eat.ch

returns NXDOMAIN.

Note that i don't want to argue whether or not everyone should implement RFC8020: All i'm saying is that there are servers in the wild which do return NXDOMAIN and hence it is almost impossible to say whether or not a domain has DKIM enabled.

Regards, Adrian