Mailing list questions (DMARC, ARC, more?)

Fri Sep 23 22:23:03 UTC 2022

another test done

>>>>>>>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:

From: frank picabia <fpicabia at gmail.com>

>>- 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.

>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:

>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?

>>- 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 at pcale:~/tmp$ arc-verify.pl < arc1.eml

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

uhlar at fantomas% perl ./scripts/arcverify.pl < /tmp/arc1.eml
RESULT: pass
uhlar at 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)
- not from ISC

>ARC-Seal: v=3 pass
>ARC-Message-Signature: v=3 pass
>ARC-Seal: v=2 pass
>ARC-Message-Signature: v=2 fail (body has been altered)
>ARC-Seal: v=1 pass
>ARC-Message-Signature: v=1 fail (body has been altered)
>
>(arc-verify.pl is a copy of the module's synopsis[*].)
>
>Then I tried it on Ged's message, earlier in this thread, and got:
>
>ale at pcale:~/tmp$ arc-verify.pl < arc2.eml
>ARC-Seal: v=3 pass
>ARC-Message-Signature: v=3 pass
>ARC-Seal: v=2 pass
>ARC-Message-Signature: v=2 fail (message has been altered)
>ARC-Seal: v=1 pass
>ARC-Message-Signature: v=1 fail (message has been altered)
>
>So both messages seem to be valid, if you trust isc.org.  The failure 
>in the signature reflects that only the body was altered in your 
>message, while also the header was altered in Ged's one.  As ARC 
>allows mediators to modify messages, only the last signature is 
>significant.
>
>
>>>Mailman should know about your setting in order to skip From: 
>>>munging in the copies sent to you.  Currently, the copies sent to 
>>>pipermail for archiving seem to be non-munged, so this 
>>>functionality exists.
>>
>>do you mean I can turn off From: munging in mail sent to me?
>
>
>Mailman options[†] don't include something like
>
>   *From munging*:
>
>   Set this option to /Disabled/ to receive messages with the original From:
>   line intact.  Keep in mind that disabling this option will fail DMARC, so
>   keep it enabled unless your MTA either doesn't check DMARC or accepts ARC
>   overrides.
>
>It doesn't seem difficult to implement.  It requires trusting the 
>users, though.  I'm going to ask Mailman developers.

-- 
Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I'm not interested in your website anymore.
If you need cookies, bake them yourself.