On Sat 24/Sep/2022 00:23:03 +0200 Matus UHLAR - fantomas wrote:
another test done


Thanks for reporting.

This is slightly OT, as it concerns the list functioning rather than DNS.  I 
hope it doesn't afflict...


I see the list operates both From: munging and ARC sealing. While I'm clear about the former, I'm curious about how ARC works:

Do any subscribers trust the seal by isc.org?

I guess most of recipients use predefined configurations, e.g. no whitelisting.

out of curiousity, I set my opendmarc.conf:

DomainWhitelist lists.isc.org

so we'll see next time mail comes.

On 25.08.22 18:10, Alessandro Vesely wrote:
Please tell us.

On Fri 02/Sep/2022 14:27:55 +0200 Matus UHLAR - fantomas wrote:
so far, not ex

- opendmarc only uses header that's inserted by openarc milter

- openarc milter for bind-users inserts arc.chain="isc.org:isc.org:isc.org"

On 04.09.22 12:56, Alessandro Vesely wrote:
They produce an ARC set on each internal passage, all having d=isc.org. That's undoubtedly redundant, yet valid.

I haven't studied the ARC standard, but this looks correct.
However, I was repeatedly unable to make opendmarc to accept arc result:

Authentication-Results: fantomas.fantomas.sk; dmarc=fail (p=none dis=none) 
header.from=gmail.com
Authentication-Results: fantomas.fantomas.sk;
         dkim=fail reason="signature verification failed" (2048-bit key; 
unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 
header.b=itqgpF3K;
         dkim-atps=neutral


IMHO, it is correct to say dkim=fail, but DMARC should have been redeemed by 
ARC if trusted.


Authentication-Results: [...]
Authentication-Results: fantomas.fantomas.sk; arc=pass smtp.remote-ip=149.20.1.60 
arc.chain="isc.org:isc.org:isc.org"


That arc=pass doesn't say if it was trusted or not.  As you say, trust doesn't 
seem to make any difference.  Paradoxical.


From: frank picabia <fpica...@gmail.com>


Gmail has p=none.  However, I tried to send to this list an unauthenticated 
message from a domain with p=reject and spf-all.  It was rejected by:
550 5.7.1 Blocked by SpamAssassin

That looks like accumulating a score, not a formal rejection after policy 
requirements.


- opendmarc seems to ignore "DomainWhitelist isc.org" perhaps I need to put
  isc.org:isc.org:isc.org (will try)

I have tried both, no result.


There is a school of thought according to which receivers should blindly trust 
ARC headers, except spam or known bad actors.


When enabled, arc=pass should override dmarc=fail p=reject.  We never get this, because bind-users rewrite From: if author's domain has p=reject.

This should not be a problem, since we should trust isc.org servers when they provide wortking ARC-Seal:


Yes, but we still receive munged From:'s.  The idea was that with ARC they 
could be avoided.  The way to do it is the 1st method in my draft[*], but I 
cannot find a list willing to experiment.

Trusting isc.org should suffice.  Logically, when multiple domains applied message modifications, a receiver has to trust all of them. Not necessarily any disposition of them.

do you mean, I should trust all domains in ARC-Seal, listed in Authentication-Results header?


RFC8617 talks about "sealing domain" of a given ARC set, surmising that the d= 
tag should have the same value in ARC-Seal and ARC-Message-Signature.


- openarc (I have installed beta from debian experimental) seems to insert Authentication-Result: header when no ARC seal is present, though not always.

- arc for bind-users seems to fail when mailman rewrites From: header   (but DKIM is fine in this case)

I tried the Perl ARC verifier included in Mail::DKIM.  On your message it outputs:

ale@pcale:~/tmp$ arc-verify.pl < arc1.eml

this is not in debian distribution.
when tried it, it shows correct:

uhlar@fantomas% perl ./scripts/arcverify.pl < /tmp/arc1.eml
RESULT: pass
uhlar@fantomas% perl ./scripts/arcverify.pl < /tmp/arctest
RESULT: pass


however, I was unable to make my dkim/dmarc PASS on a mail from this list that was:

- arc-signed by ISC
- DKIM fail (not munged)


The header is ok, but the body has an added footer.  Using zdkimfilter (3rd 
method in that draft[*]) I get the following on your message:

INFO: zfilter: zdkimfilter[13097]:ip=NULL: domain isc.org whitelisted by 
list.dnswl.org
DEBUG: zfilter: zdkimfilter[13097]:ip=NULL: retrieved fantomas.sk->fantomas: 
rsa-sha256, 2048 bits
INFO: zfilter: zdkimfilter[13097]:ip=NULL: enabling body parse (sigs pass: 1, 
could pass: 0)
INFO: zfilter: zdkimfilter[13097]:ip=NULL: enabling retry (badsig, bh ok: 0; 
badsig, bh bad: 0; pass, bh bad: 1)
INFO: zfilter: zdkimfilter[13097]:ip=NULL: transformation enabled for "Matus UHLAR - 
fantomas <uh...@fantomas.sk>" retry body only
INFO: zfilter: zdkimfilter[13097]:ip=NULL: transform message from base64 back 
to identity  with footer.
INFO: zfilter: zdkimfilter[13097]:ip=NULL: sig failure d=fantomas.sk, 
s=fantomas: body hash mismatch
INFO: zfilter: zdkimfilter[13097]:ip=NULL: sig success (trans) d=fantomas.sk, 
s=fantomas
INFO: zfilter: zdkimfilter[13097]:ip=NULL: signature by fantomas.sk, s=fantomas 
recovered by transformation
INFO: zfilter: zdkimfilter[13097]:DMARC disabled (0), policy not found for 
fantomas.sk
INFO: zfilter: zdkimfilter[13097]:ADSP disabled (0), policy not found for 
fantomas.sk

Authentication-Results: wmail.tana.it;
  spf=pass smtp.mailfrom=lists.isc.org;
  dkim=pass reason="transformed" header.d=fantomas.sk
250 Ok.


Best
Ale
--

[*] https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform









--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to