Should addition of ARC seal depend on DKIM signing?

[ikedas]

For example:

sympa/src/lib/Sympa/Spindle/ProcessOutgoing.pm

Lines 228 to 233 in 3ee40dd

	my ($dkim, $arc);
	if ($message->{shelved}{dkim_sign}) {
	$dkim = Sympa::Tools::DKIM::get_dkim_parameters($message->{context});
	$arc = Sympa::Tools::DKIM::get_arc_parameters($message->{context})
	if $message->{shelved}->{arc_cv};
	}

This seems to me that, even if incoming message has a valid ARC seal, when Sympa is not configured to add DKIM signature, Sympa won't add new ARC seal.

One of possible workaround is setting dkim_signature_apply_on as any to make Sympa always add DKIM signature.

However, I think it is possible to use ARC seals without DKIM signatures.

[ikedas]

@jrlevine, do you have any opinion on this issue? May we have independent control over DKIM signing and ARC sealing?

[jrlevine]

While it is technically possible to add ARC seals without DKIM, it makes no sense. They use the same keys, so any system that can add ARC seals can add DKIM signatures with no more configuration. Any system that looks at ARC will also expect to see DKIM.

[ikedas]

@jrlevine , thanks for your response.

However I found an implementation using ARC without DKIM: gmail adds ARC seal when it is configured to forward messages to the other address. In this case it won't add DKIM signature to the forwarded messages. Currently Sympa seems not to take such cases into account: If a gmail account forwards a mail to a Sympa list, it does not add an ARC seal (nor DKIM signature), so the ARC verification fails at the delivery destination.

[jrlevine]

Sympa should be able to add an ARC seal to the mail that Gmail forwards. It will use whatever DKIM signatures are present, but ARC just records whatever authentication was present.

Gmail doesn't add another DKIM signature because it is forwarding mail unmodified, so previous signatures should still be valid. Mailing lists modify messages so they have to add a new DKIM signature to the modified message.

[ikedas]

I see. I understood as following, is my understanding correct?

• ARC seal represents Sympa's trust in authentication in previous hops of delivery.
• DKIM signature represents trust in changes (or creation) of the messages made by Sympa itself.

Since they both use the same key but for different purposes, I think they should be able to be enabled/disabled independently of each other.

[jrlevine]

There is no benefit whatsoever to doing ARC while not doing DKIM on a Sympa list. Why provide a useless option?

[ikedas]

In any case, I think the current behavior is problematic: If DKIM signature is not added (i.e. prevented by dkim_signature_apply_on parameter), ARC sealing by Sympa is prevented.

Even if I agree with your argument that "there is no benefit whatsoever to doing ARC while not doing DKIM", I think we should change the behavior: If ARC sealing by Sympa is enabled, the DKIM signature is always (i.e. not according to dkim_signature_apply_on) added.

---

[EDIT]

However, RFC 8617 says:

The ARC-Message-Signature (AMS) header field allows an ARC-
participating ADMD to convey some responsibility (custodianship) for
a message and possible message modifications to future ARC-
participating custodians.

(Emphasis is by the quoter.)

There seems to be unnecessary to further add DKIM signature when AMS is added along with ARC sealing.

[jrlevine]

Um, really, I know the people who wrote ARC. You absolutely want to add a new DKIM signature to show this really came from the Sympa installation rather than some bot that is munging old posts. One of ARC's limitations is that the recipient can't believe any of the ARC seals unless it has reason to trust the entity that added the most recent seal. The DKIM signature says "yes this is me sending the message.

How hard would be be to adjust the controls so that there's one switch for None/DKIM/DKIM+ARC ?

[jrlevine]

In case it's not clear, when Google adds an ARC seal to a forwarded message, it doesn't change the message so any existing DKIM signature will still be valid and the recipient can verify that. But since Sympa generally adds subject tags, headers, footers, and so forth, any existing DKIM signatures are all broken so it needs to add a new DKIM signature to the outgoing modified message that the recipient can verify.

[ikedas]

One of ARC's limitations is that the recipient can't believe any of the ARC seals unless it has reason to trust the entity that added the most recent seal. The DKIM signature says "yes this is me sending the message.

I see. It makes sense that the recipient cannot determine if the modification of the message is legitimate or not using ARC.

How hard would be be to adjust the controls so that there's one switch for None/DKIM/DKIM+ARC ?

As I wrote, it is possible: We may make changes on Sympa so that, when ARC seal is added, DKIM signing will be forced. I'll submit a PR later.

[ikedas]

At this point, I'd like to confirm one more thing.

Currently documentation says:

It also requires that the MTA that delivers emails to Sympa adds an Authentication-Results: header that shows how a message was (or wasn’t) authenticated as it arrived.

However, it seems to be possible to add the AR by Sympa itself: The information obtained during the processing of check_dkim_signature() and check_arc_chain() look equivalent to the contents of the AR added by MTA.

Would it be OK that we will make Sympa to add AR (and to include it in the AAR of the ARC seal)?

[jrlevine]

It is better if the inbound MTA adds the A-R header because it has information that Sympa doesn't, but if the MTA can't add the header, and Sympa adds one it's better than nothing.
To do SPF validation it needs to know the remote IP on the SMTP session, which the MTA knows and Sympa doesn't. Sometimes Sympa might be able to guess the IP from Received headers, but MTAs are set up in so many different ways that the guesses are often wrong.
The documentation might note that it is easy to for the MTA to add an A-R header using the opendmarc milter in sendmail, Postfix, and Exim. Or Exim can do it directly using the authresults internal string macro.

[ikedas]

I see. In fact Sympa has only the information about ARC chain and DKIM signatures, so it can not include information about SPF and so on if it add AR by itself.

The documentation might note that it is easy to for the MTA to add an A-R header using the opendmarc milter in sendmail, Postfix, and Exim. Or Exim can do it directly using the authresults internal string macro.

Note on documentation looks good idea.

[ikedas]

Examples of results with the PRs above:

Message with neither ARC seal nor AR.

• No AR was added by MTA.
• AR, ARC fields and DKIM signature were added by Sympa.

...
Received: by ...
DKIM-Signature: v=1; ...
ARC-Seal: i=1; ...
ARC-Message-Signature: i=1; ...
ARC-Authentication-Results: i=1; auth.service.id; arc=none
Authentication-Results: auth.service.id (Sympa); arc=none
Received: by ...
...

Message with no ARC seal and unuseful AR.

• The second (earlier) AR was added by MTA, but did not include entry for "arc".
• The first (newer) AR, ARC fields and DKIM signature were added by Sympa.

...
Received: by ...
DKIM-Signature: v=1; ...
ARC-Seal: i=1; ...
ARC-Message-Signature: i=1; ...
ARC-Authentication-Results: i=1; auth.service.id; arc=none;
	dkim=pass header.d=yyyyy.com header.s=selector header.b="XXXXXXXX";
	dmarc=pass (policy=none) header.from=yyyyy.com;
	spf=pass (...) [email protected]
Authentication-Results: auth.service.id (Sympa); arc=none
Authentication-Results: auth.service.id;
	dkim=pass header.d=yyyyy.com header.s=selector header.b="XXXXXXXX";
	dmarc=pass (policy=none) header.from=yyyyy.com;
	spf=pass (...) [email protected]
Received: from ...
...

Message with ARC seal and useful AR.

• The first (i=1) ARC fields were added at the previous hop.
• AR was added by MTA and included entry for "arc".
• The second (i=2) ARC fields and DKIM signature were added by Sympa.

...
Received: by ...
DKIM-Signature: v=1; ...
ARC-Seal: i=2; ...
ARC-Message-Signature: i=2; ...
ARC-Authentication-Results: i=2; auth.service.id;
	dkim=pass header.d=yyyyy.com header.s=selector header.b=XXXXXXXX;
	arc=pass (" ... :i=1");
	dmarc=pass (policy=none) header.from=yyyyy.com;
	spf=pass (...) [email protected]
Authentication-Results: auth.service.id;
	dkim=pass header.d=yyyyy.com header.s=selector header.b=XXXXXXXX;
	arc=pass (" ... :i=1");
	dmarc=pass (policy=none) header.from=yyyyy.com;
	spf=pass (...) [email protected]
Received: from ...
...
ARC-Seal: i=1; ...
ARC-Message-Signature: i=1; ...
ARC-Authentication-Results: i=1; zzzzzzzzz.com;
       dkim=pass [email protected] header.s=selector header.b=XXXXXXXX;
       spf=pass (...) [email protected];
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=yyyyy.com
Received: from ...
...

[ikedas]

I submitted update on documentation: Please see sympa-community/sympa-community.github.io#95 and point out any problems.