Subject: [dmarc-ietf] dmarc.ietf.org failed dmarc

From: Benny Pedersen <[email-masked]>
Date: Sat, 16 May 2020 13:56:21 +0200

https://dmarcian.com/domain-checker/ test it there

if not taking ownerships it will get dmarc pass

oh well software testers needs cases to test on its one here then

if its complete impossible to not break dkim i will leave this maillist

---

From: "John Levine" <[email-masked]>
Date: 16 May 2020 13:24:52 -0400

>https://dmarcian.com/domain-checker/ test it there

You're misreading what it says.  The DMARC setup is fine.

>if its complete impossible to not break dkim i will leave this maillist

After you leave, you might want to review the ARC work we've been
doing over the past year.

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 18 May 2020 15:51:30 -0400

While the setup for dmarc.ietf.org was correct before, it was pretty 
funky.

I suggested they make a few changes which they have now done: 
there is now an explicit _dmarc.dmarc.ietf.org TXT record, and there is an 
MX record pointing at the mail server rather than A/AAAA records.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Benny Pedersen <[email-masked]>
Date: Mon, 18 May 2020 21:59:38 +0200

> While the setup for dmarc.ietf.org was correct before, it was pretty 

+1

> I suggested they make a few changes which they have now done: there is
> now an explicit _dmarc.dmarc.ietf.org TXT record, and there is an MX
> record pointing at the mail server rather than A/AAAA records.

spamassassin still says dkim invalid here

not using sid-milter, opendkim, openarc, opendmarc or even python based 
dkim validators, pure perl Mail::DKIM 0.440 in gentoo

sorry if its my own fault

i self use fuglu 0.10.6 to dkim sign

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 18 May 2020 16:02:35 -0400

+1 John and thanks.

tim

On Mon, May 18, 2020 at 3:51 PM John R. Levine <[email-masked]> wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Benny Pedersen <[email-masked]>
Date: Mon, 18 May 2020 22:07:58 +0200

> +1 John and thanks.

this mail is dkim valid au here, hope to see posts from John that is 
pass aswell

---

From: "John Levine" <[email-masked]>
Date: 18 May 2020 16:32:21 -0400

>spamassassin still says dkim invalid here

Yes, that is correct.  I would suggest learning more about DMARC and why
that is not a problem.

---

From: Benny Pedersen <[email-masked]>
Date: Mon, 18 May 2020 22:42:17 +0200

> Yes, that is correct.  I would suggest learning more about DMARC and 

i will when spamassassin supports dmarc

---

From: "Douglas E. Foster" <[email-masked]>
Date: Mon, 18 May 2020 22:09:24 GMT

I understand your question to be "Why do I see invalid DKIM signatures on messages from the IETF mailing list?"  I can provide your answer

The typical message on this mailing list has three signatures:

Signature Analysis:
The first signature is from the submitter's organization.   In your message, it was from junc.eu.

The second signature is applied by IETF shortly after receipt of the message.

IETF adds an Athentication-Results header which indicates that the junc.eu signature was valid when they checked it
.Then, IETF changes the FROM address to be @dmarc.ietf.org and tags the Subject with [dmarc-ietf].   This breaks both of the first two signatures.

Then, IETF applies a second signature which is verifiable. 

Integrity Analysis:
The IETF rule is "an unverified signature is the same as no signature."  Therefore, the invalid signatures can and should be ignored.  It appears that your tool is getting confused by the invalid IETF signature and ignoring the valid one.

The message passes SPF because the Sender Address has been changed to [email-masked].

The second passes DKIM because the second IETF signature verifies.

No official assertion is been made about the sender's domain, so there is no need to verify against that domain.   But if you want to do so, you can evaluate whether to place trust in the Authentication-Results header applied by IETF. 

IETF converts all messages to plain text, and strips or blocks attachments, so they have minimized the opportunity for malicious submission.
Implications for Email Defenses:

This example is a reminder that every message is a take-it-or-leave-it proposition.   You can accept the message or reject it, based on the message characteristics, but you will probably be unable to cannot change the sender's behavior.   In this situation, you may not like having two signatures from IETF, but you cannot change IETF.    As a result, any spam filter needs to be very flexible about exceptions.   Too many spam filters do not have adequate exception mechanisms.

Hope this helps,

Doug Foster

----------------------------------------
From: me=[email-masked]
Sent: 5/16/20 7:58 AM
To: [email-masked]
Subject: [dmarc-ietf] dmarc.ietf.org failed dmarc
https://dmarcian.com/domain-checker/ test it there

---

From: "John Levine" <[email-masked]>
Date: 18 May 2020 20:24:46 -0400

In article <[email-masked]> you write:
>This example is a reminder that every message is a take-it-or-leave-it proposition.   You can accept
>the message or reject it, based on the message characteristics, but you will probably be unable to
>cannot change the sender's behavior.   In this situation, you may not like having two signatures
>from IETF, but you cannot change IETF.    As a result, any spam filter needs to be very flexible
>about exceptions.   Too many spam filters do not have adequate exception mechanisms.

You missed an important point -- for any From: address that has a
quarantine or reject DMARC policy, the IETF lists rewrite the address
into the dmarc.ietf.org domain using a kludge I suggested to them.

You shouldn't be seeing any mail from IETF lists failing dmarc with a
dmarc policy. You'll see plenty that fails with p=none (this one
probably) but any spam filter that rejects on DMARC failure with
p=none is pretty badly broken.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 19 May 2020 11:46:49 +0200

On Mon 18/May/2020 22:32:21 +0200 John Levine wrote:
> Yes, that is correct.

Why would that be correct?

It says DKIM_VALID here, not only in normal TB usage (attached) but also if I run SA locally (normally I spare SA for list messages), getting the following
(notice dkim: signature verification result: PASS):

ale@pcale:~/tmp$ spamassassin -D dkim < valid.eml 
May 19 11:35:03.226 [4856] dbg: dkim: using Mail::DKIM version 0.4
May 19 11:35:03.226 [4856] dbg: dkim: providing our own resolver: Mail::SpamAssassin::DnsResolver
May 19 11:35:03.231 [4856] dbg: dkim: performing public key lookup and signature verification
May 19 11:35:03.979 [4856] dbg: dkim: VALID DKIM, i=@ietf.org, d=ietf.org, s=ietf1, a=rsa-sha256, c=relaxed/simple, key_bits=1024, pass, does not match author domain
May 19 11:35:03.979 [4856] dbg: dkim: VALID DKIM, i=@ietf.org, d=ietf.org, s=ietf1, a=rsa-sha256, c=relaxed/simple, key_bits=1024, pass, does not match author domain
May 19 11:35:03.979 [4856] dbg: dkim: FAILED DKIM, i=@iecc.com, d=iecc.com, s=fc88.5ec2f0d6.k2005, a=rsa-sha256, c=simple/simple, unknown key size, fail, does not match author domain
May 19 11:35:03.980 [4856] dbg: dkim: FAILED DKIM, i=@taugh.com, d=taugh.com, s=fc88.5ec2f0d6.k2005, a=rsa-sha256, c=simple/simple, unknown key size, fail, matches author domain
May 19 11:35:03.980 [4856] dbg: dkim: signature verification result: PASS
May 19 11:35:03.983 [4856] dbg: dkim: adsp: performing lookup on _adsp._domainkey.taugh.com
May 19 11:35:04.219 [4856] dbg: dkim: adsp result: U/unknown (dns: unknown), author domain 'taugh.com'
May 19 11:35:04.238 [4856] dbg: dkim: VALID signature by ietf.org, author [email-masked], no valid matches
May 19 11:35:04.238 [4856] dbg: dkim: VALID signature by ietf.org, author [email-masked], no valid matches
May 19 11:35:04.238 [4856] dbg: dkim: FAILED signature by iecc.com, author [email-masked], no valid matches
May 19 11:35:04.238 [4856] dbg: dkim: FAILED signature by taugh.com, author [email-masked], no valid matches
May 19 11:35:04.238 [4856] dbg: dkim: author [email-masked], not in any dkim whitelist
May 19 11:35:06.693 [4857] info: util: setuid: ruid=1000 euid=1000 rgid=1000 27 29 104 109 115 125 1000 egid=1000 27 29 104 109 115 125 1000 

Best
Ale
--

---

From: Benny Pedersen <[email-masked]>
Date: Tue, 19 May 2020 13:44:49 +0200

On 2020-05-19 00:09, Douglas E. Foster wrote:
> I understand your question to be "Why do I see invalid DKIM signatures
> on messages from the IETF mailing list?"

yes this is my consern, it should not be breaked on take ownerships, if 
maillist can break dkim and take ownerships and still not make it dmarc 
pass then its incompetent maillist admins

its just sadly not the only maillist its daily problem on

> I can provide your answer
> 
> 	* The first signature is from the submitter's organization.   In your
> message, it was from junc.eu.

yes

> 
> 	* The second signature is applied by IETF shortly after receipt of
> the message.

opendkim resign ?

> 
> 	* IETF adds an Athentication-Results header which indicates that the
> junc.eu signature was valid when they checked it

yes i did my homework then

> .
> 	* Then, IETF changes the FROM address to be @dmarc.ietf.org and tags
> the Subject with [dmarc-ietf].   This breaks both of the first two
> signatures.

why is it done ?, to fix there own problem of breaking dkim ?

> 
> 	* Then, IETF applies a second signature which is verifiable.

it just not giving dmarc pass, why ?

> 
> Integrity Analysis:
> 
> 	* The IETF rule is "an unverified signature is the same as no
> signature."  Therefore, the invalid signatures can and should be
> ignored.  It appears that your tool is getting confused by the invalid
> IETF signature and ignoring the valid one.

i think that on the safe side to not make dkim pass with signatures not 
from original outhor domain, if that ships sail it would make it hard to 
verify without openarc sealing

> 
> 	* The message passes SPF because the Sender Address has been changed
> to [email-masked].

thats the standard aling changes, all well there

> 
> 	* The second passes DKIM because the second IETF signature verifies.

but why is it not dmarc pass

> 
> 	* No official assertion is been made about the sender's domain, so
> there is no need to verify against that domain.   But if you want to
> do so, you can evaluate whether to place trust in the
> Authentication-Results header applied by IETF.

waiting for AuthRes plugin in spamassassin then all problems will be 
bigger if results is evaluated outside of spamassassin from AR headers

hope developpers wake up on the risk of breaking more then just dkim

> 
> 	* IETF converts all messages to plain text, and strips or blocks
> attachments, so they have minimized the opportunity for malicious
> submission.

i remember with amavisd-new it was good to disable 8bitmime before 
letting amavisd-new do its dkim sign, that helps make dkim signed 
signature not break on mime converters

> This example is a reminder that every message is a take-it-or-leave-it
> proposition.   You can accept the message or reject it, based on the
> message characteristics, but you will probably be unable to cannot
> change the sender's behavior.   In this situation, you may not like
> having two signatures from IETF, but you cannot change IETF.    As a
> result, any spam filter needs to be very flexible about exceptions.
> Too many spam filters do not have adequate exception mechanisms.

i will let spamassassin do its work on dkim breakage on maillists, but 
that is same reason i do not use sid-milter, opendkim, openarc, 
opendmarc, its designed badly to maillists that claim its impossible to 
not break dkim

> Hope this helps,

it does hopefully :=)

---

From: Benny Pedersen <[email-masked]>
Date: Tue, 19 May 2020 22:48:03 +0200

> You're misreading what it says.  The DMARC setup is fine.

page does not test arc results :)

> doing over the past year.

it does not matter if opendmarc does not use openarc yet

opendmarc from trunk does, but none of it is stable on gentoo, even 
opendkim is not stable, since gentoo devs insists on backports with 
delays to not happend soon

thats why i leaved from opendkim, openarc, opendmarc, its simple to 
unstable for real life