Mailing list questions (DMARC, ARC, more?)

[Alessandro Vesely]

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 <fpicabia at 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 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)


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 <uhlar at 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