[swinog] Re: Swiss Domain Security Report Q3 2022

[Sebastian Philipp via swinog]

On 08 Jun 2023 Jonas Meier via swinog wrote:
> maybe there is an option to remove the signature. If anyone has
> experience with mailman3 and dkim, please write to me directly.

You can set `remove_dkim_headers: yes` in mailman.cfg [1]

(Sending this to the list, as this may be relevant for more people on
here).

Regards
Sebastian

[1]:
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/config/docs/config.html#remove-dkim-headers
___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Re: Swiss Domain Security Report Q3 2022

[Jeroen Massar via swinog]

Noting you do part of this already.

But. note this nasty effect:

---
From: Jonas Meier via swinog 
Reply-To: Jonas Meier 
---

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  wrote:
> 
> 
> 
>> On 8 Jun 2023, at 11:47, Jonas Meier via swinog  
>> 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 
> .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/docs/dmarc-mitigations.html
> 
> For ARC: 
> https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/arc_sign.html
> 
> Greets,
> Jeroen
> 
> 

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

[swinog] Re: Swiss Domain Security Report Q3 2022

[Jeroen Massar via swinog]

> On 8 Jun 2023, at 11:47, Jonas Meier via swinog  
> 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 .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/docs/dmarc-mitigations.html

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

Greets,
 Jeroen


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

[swinog] Re: Swiss Domain Security Report Q3 2022

[Jonas Meier via swinog]

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/docs/dmarc-mitigations.html


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-boun...@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-le...@lists.swinog.ch

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

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

[swinog] ### SwiNOG #38 - Agenda ###

[Simon Ryf via swinog]

Dear SwiNOG community,

we could finally compile the agenda for the upcoming SwiNOG #38 – June 
Wednesday 21st
Have a look at https://www.swinog.ch/meetings/swinog38/
There is still time to https://register.swinog.ch/ if you have not done it 
already.


We have a super packed agenda. On the other hand,

I’m very happy with all the exciting speeches which have made it to the final 
list.



A few last things to wrap up and then we’re ready to welcome you again in ~ 2 
weeks.



Looking forward to seeing many of you.



SwiNOG Core Team
___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Re: Swiss Domain Security Report Q3 2022

[Adrian Ulrich via swinog]

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/yHN9ew5Q5GkJ)

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
___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Re: Swiss Domain Security Report Q3 2022

[Franco Hug via swinog]

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-boun...@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-le...@lists.swinog.ch
___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch