Version and my setup of openarc

["A. Schulze" <sca@xxxxxxxxxxxxxxxxx>]

Hi,

while talking about defects that *do* exist in OpenARC, I would like to get more specific about "what I'm using" before summarizing some test results.

1.
I take the branch 'develop' as base. https://github.com/trusteddomainproject/OpenARC/tree/develop

2.
I apply a patch for Issue 137 (https://github.com/trusteddomainproject/OpenARC/issues/137) also known as Pull 121
(https://github.com/trusteddomainproject/OpenARC/pull/121)
Finally it this commit: https://github.com/trusteddomainproject/OpenARC/pull/121/commits/7547a83dece3a3994bfc7c990b7ecabb067783ec

3.
OpenARC add Header with 'uncommon' but perfect valid 'very long lines'. https://github.com/trusteddomainproject/OpenARC/issues/162
I use the patch mentioned in this Issue

4.
then I apply this commit:
https://github.com/trusteddomainproject/OpenARC/pull/145/commits/5d488372f06410e65bc972ade89d8e68998d7170

5.
finally I apply this change: https://github.com/andreasschulze/OpenARC/compare/develop...andreasschulze:OpenARC:log_arc_validation_result

Then, I created new ARC seal keys for the MTA's, I operate.
I selected 2k RSA and a minimum of option in the public part published in DNS:
 - https://dns.google/query?name=arc1._domainkey.dahlem.somaf.de&rr_type=TXT
 - https://dns.google/query?name=arc1._domainkey.mta.somaf.de&rr_type=TXT
You see explicit no information about any hash algorithm.

Selecting 2k but not 4k also has a reason. Open*DM*ARC crash on larger keys:
https://github.com/trusteddomainproject/opendmarc/issues/183
I like to avoid triggering this bug when I send out a message so I select a "know to not crash" key size...

Said that, I configure separate instances of OpenARC. One only seal, an other only verify.

/etc/postfix/main.cf
  dkim_verifier       = inet:localhost:2000
  dkim_signer_rsa     = inet:localhost:2100
  dkim_signer_ed25519 = inet:localhost:2200
  arc_verifier        = inet:localhost:3000
  arc_sealer          = inet:localhost:3100
  dmarc               = inet:localhost:4000
  # smtpd_milters not set in main.cf

/etc/postfix/master.cf
  smtp       inet n - - - - smtpd
   -o smtpd_milters=${dkim_verifier},${arc_verifier},${dmarc},${arc_sealer}
   -o <other MX specific options>
   -o syslog_name=postfix/mx

  submission inet n - - - - smtpd
   -o smtpd_milters=${dkim_signer_rsa},${dkim_signer_ed25519},${arc_sealer}
   -o <other submission specific options>
   -o syslog_name=postfix/submission

Now I send test messages.

 - from my personal address -> ms365
   -> MS say: arc=pass
 - from ms365 to my personal address
   -> my OpenARC say: arc=pass

 - from my personal address -> echo at openarc dot org
   -> my OpenARC say: arc=pass
 - from ms365 -> echo at openarc dot org
   -> MS say: arc=pass
 
 - from my personal address -> forward at openarc dot org
   -> my OpenARC say: arc=fail
 - from ms365 -> forward at openarc dot org
   -> MS say: arc=fail

 ( to be done: same tests with gmail )

This matches an observation, Jered Floyd mentioned here: https://openarc.org/listarchives/openarc-users@xxxxxxxxxxx/2024-01/0000010.html

My conclusion: there are (at least) two further defects in OpenARC
  - validation fail for chains longer then 0 or 1
  - validation fail if the DNS of foreign seal data include a hash algorithm