David Krantz writes:
Is there any known issues with ARC that I should be aware of?
Doesn't Postfix do ARC yet? :-( rspamd seems to be recommended by a couple of Linux distros, supports the milter interface that Postfix uses to call out to 3rd party processes, and the website looks good. See rspamd.com. That said, if you want to use Mailman's support...
Our support doesn't have issues that I know of. You can check the issue tracker: https://gitlab.com/mailman/mailman/issues. On second thought, don't bother. I did and "ARC" picks up scads of irrelevant junk, "authenticated received chain" nothing, and a couple of other tries don't pick up anything useful either.
I run the latest release of mailman (3.3.0 of core) on Python 3.7.6 and I use postfix as MTA.
[various data deleted]
I haven't looked at ARC in some months, so it's possible that our current implementation is out of date with best current practice. However, in a quick scan I see no difference in RFC 8617 vs. ID-ARC-23, so I don't know what might have changed there.
Are the messages being refused by those sites because of the ARC errors, or are they being delivered anyway? We probably need to see the message as received by Mailman, the message as emitted by Mailman, and the message as received at the validating site to have a hope of diagnosing this.
The things that I can see from the data you've provided that might be related are
If it's just the body hash that's a problem, there may be one or more MXes that convert Content-Transfer-Encoding between your Mailman and the receiving sites. That would be easy to check if you have the messages as sent and as received.
You have an awfully aggressive list of signed header fields. In
particular, the Resent-* fields are treated as trace fields: there may be multiple instances of each. I don't understand the semantics of DKIM/ARC signing for those headers very well, but it's something that I would think easy to mess up. You might try deleting those.
You are supposed to sign any existing DKIM-Signature fields, but that's not in the list.
The ARC RFC 8617 says that an ARC Sealer must add any DKIM-Signature *before* ARC sealing. I suppose this could be a problem, since our ARC implementation doesn't DKIM sign. (On the other hand, I don't see how it would be a problem, since any MX along the way might add a DKIM signature, and you're not signing DKIM-Signature according to your list of signed fields.)
It would be helpful if instead of quoting small parts of error messages, you gave us the entire body of a delivery status notification message or the entire MTA log. If there's stuff (domains, mailboxes, IP addresses) you want to redact, feel free, just make sure that it's obvious what was redacted.
I will check our implementation, principally to make sure that the authentication results used are computed on the raw incoming message and the ARC sealing is done on the raw outgoing message after all other message modifications are done. I will also see if I can conjure up tests that test the site's MTA(s) as well as just our implementation, as we currently test our implementation using static data from the ARC implementation we use (ie, we ARC-process a given message and then do a byte-by-byte comparison on an allegedly correct ARC-Sealed version of the same).
Sorry I can't give more precise help. Maybe something here will be of use.
Steve