* Added arc.chain to be recognized by ar parser

[theSCHAPPY]

ar-test is unable to parse the following AR header taken from milter-test because arc.chain is not a recognized ptype: example.com; arc=pass header.oldest-pass=0 smtp.remote-ip=127.0.0.1 arc.chain="example.com:example.com"
In addition, you will find the following message logged to syslog: <MSGID>: can't parse Authentication-Results; <AUTHSERV_ID>; arc=pass header.oldest-pass=0 smtp.remote-ip="<IP>" arc.chain=<CHAINNAME> ; ignoring

The arc.chain ptype is added during verification of messages, which have already an existing ARC chain present. This is the case if you receive o365 managed domains nowadays.

token 0 = 'example'
token 1 = '.'
token 2 = 'com'
token 3 = ';'
token 4 = 'arc'
token 5 = '='
token 6 = 'pass'
token 7 = 'header'
token 8 = '.'
token 9 = 'oldest-pass'
token 10 = '='
token 11 = '0'
token 12 = 'smtp'
token 13 = '.'
token 14 = 'remote-ip'
token 15 = '='
token 16 = '127'
token 17 = '.'
token 18 = '0'
token 19 = '.'
token 20 = '0'
token 21 = '.'
token 22 = '1'
token 23 = 'arc'
token 24 = '.'
token 25 = 'chain'
token 26 = '='
token 27 = 'example.com:example.com'

ar-test: ares_parse() returned -1

After adding arc to the list of allowed ptypes for ar parser, the AR header is recognized correctly.

token 0 = 'example'
token 1 = '.'
token 2 = 'com'
token 3 = ';'
token 4 = 'arc'
token 5 = '='
token 6 = 'pass'
token 7 = 'header'
token 8 = '.'
token 9 = 'oldest-pass'
token 10 = '='
token 11 = '0'
token 12 = 'smtp'
token 13 = '.'
token 14 = 'remote-ip'
token 15 = '='
token 16 = '127'
token 17 = '.'
token 18 = '0'
token 19 = '.'
token 20 = '0'
token 21 = '.'
token 22 = '1'
token 23 = 'arc'
token 24 = '.'
token 25 = 'chain'
token 26 = '='
token 27 = 'example.com:example.com'

1 result found
authserv-id 'example.com'
version ''
result #0, 3 properties
        method "arc"
        result "pass"
        reason ""
        property #0
                ptype "header"
                property "oldest-pass"
                value "0"
        property #1
                ptype "smtp"
                property "remote-ip"
                value "127.0.0.1"
        property #2
                ptype "arc"
                property "chain"
                value "example.com:example.com"

Cheers!

[flowerysong]

Ignoring results with arc.chain is correct; it's an invalid ptype that is only appropriate to be added when you are the final receiver and no further processing will occur (and arguably not even then, but I didn't want to break anyone's existing setup by changing this functionality.)

If you have a need to add a chain property when you are not the final receiver, rather than modifying the parsing you'll need to rework the functionality that adds the property so that it uses the appropriate ptype (header).

[theSCHAPPY]

Setting FinalReceiver yes in openarc.conf results in adding arc.chain to AR header:

Authentication-Results: <AUTHSERV_ID>; arc=pass header.oldest-pass=0 smtp.remote-ip="<IP>" arc.chain=microsoft.com

vs. FinalReceiver no (default)

Authentication-Results: <AUTHSERV_ID>; arc=pass header.oldest-pass=0 smtp.remote-ip="<IP>"

Here it is recommend to set FinalReceiver yes to allow processing of AR headers containing arc information by openDMARC.
The commend for the property says: If set, causes this filter to pass chain signatory information downstream for local policy evaluation in the event of an authentication failure.
I would expect that existing AR headers with arc details remain unchecked in case of FinalReceiver yes because the parser is unable to parse them? As a result, a new chain might be started. That was the idea behind the fix.

Setup: Incoming mails are handled by postfix, verified by the following milters: openDKIM --> openARC --> openDMARC (to be able to see openARC results) --> others.
In case of local users with e-mail forwarding present, received mails are reinserted into SRS-rewriting and forwarded to final recipients.

Today, O365 hosted domains send out ARC-signed mails, i.e. a chain is already present when receiving these mails. In openARC verification mode for incoming mails, a ARC AR, Seal, and Signature header are added. I want to make sure that delivery to local recipients incorporates AR headers arc cv=pass details even if local AR header says dmarc=fail. Maybe such concerns are no longer required, because the current openARC fork already addresses this in a another way; the original version did not.

Thanks!