ARC sign "AuthenticationResultsHeader.parse" should not be responsible for invalid headers

[Cyril N.]

Hi,

Sorry if the title is misleading, I couldn't find a proper way to explain the situation:

In some case, we receive an email that already contains a "Authentication-Results" that is wrongly formatted, like this (for debugging and help):

> Authentication-Results: mx3-fra-sp1.mta.salesforce.com x-tls.subject="/C=US/ST=California/L=San Francisco/O=salesforce.com, inc./OU=0:app;1:fra;2:fra-sp1;3:eu26;4:prod/CN=eu26-app1-23-fra.ops.sfdc.net"; auth=pass (cipher=ECDHE-RSA-AES256-GCM-SHA384)

or this :

> {redacted}.com; dkim=none (message not signed) header.d=none;{redacted}.com; dmarc=none action=none header.from={redacted-2}.com

(notice the header.d=none;domain.com)

In this case, the method ARC.sign (around line 953) will throw an error at :

```
grouped_headers = [(res, AuthenticationResultsHeader.parse('Authentication-Results: ' + res.decode('utf-8')))
                       for res in ar_headers]
```

Because that header is invalid.

I believe that in this case, it should just be ignored. If this header is needed, the `auth_headers` will then be empty and no ARC seal will be generated.

Otherwise, and this is the case here, the invalid AR header will be ignored, but ours, which is valid, will still be included and work as intended with a generated ARC signature.

Hope this makes sense.

[Scott Kitterman (kitterman)]

It does make sense. Thanks.

[Scott Kitterman (kitterman)]

Since this will be a change in behavior, I'm going to hold changing this until the next feature release.