Should addition of ARC seal depend on DKIM signing? #1450

ikedas · 2022-07-20T07:10:19Z

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.

The text was updated successfully, but these errors were encountered:

ikedas · 2022-07-20T07:19:29Z

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

jrlevine · 2022-07-20T13:51:28Z

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 · 2022-07-20T14:16:13Z

@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 · 2022-07-20T14:19:58Z

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 · 2022-07-21T04:07:47Z

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 · 2022-07-21T16:06:23Z

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

ikedas · 2022-07-22T01:14:10Z

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 · 2022-07-22T03:24:46Z

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 · 2022-07-22T03:34:30Z

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 · 2022-07-22T04:12:57Z

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 · 2022-07-22T04:18:10Z

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 · 2022-07-22T16:52:31Z

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 · 2022-07-22T23:03:18Z

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 · 2022-07-27T04:29:46Z

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 (...) smtp.mailfrom=xxxxxxxxx@yyyyy.com
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 (...) smtp.mailfrom=xxxxxxxxx@yyyyy.com
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 (...) smtp.mailfrom=yyyyyyyyy@yyyyy.com
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 (...) smtp.mailfrom=yyyyyyyyy@yyyyy.com
Received: from ...
...
ARC-Seal: i=1; ...
ARC-Message-Signature: i=1; ...
ARC-Authentication-Results: i=1; zzzzzzzzz.com;
       dkim=pass header.i=@yyyyy.com header.s=selector header.b=XXXXXXXX;
       spf=pass (...) smtp.mailfrom=xxxxxxxxx@yyyyy.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=yyyyy.com
Received: from ...
...

ikedas · 2022-09-20T01:09:37Z

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

ARC: When ARC seal was added, DKIM signing should be forced (#1450) Forwarded messages should also be ARC sealed if possible ARC: Add Authentication-Results: field (AR), if useful one is not found Following typo fix in Mail::DKIM::ARC::Signer

ikedas added the design label Jul 20, 2022

ikedas mentioned this issue Jul 22, 2022

ARC: When ARC seal was added, DKIM signing should be forced (#1450) #1452

Merged

ikedas mentioned this issue Jul 24, 2022

ARC: Add Authentication-Results: field (AR), if useful one is not found #1453

Merged

ikedas added the ready A PR is waiting to be merged. Close to be solved label Jul 24, 2022

ikedas mentioned this issue Aug 6, 2022

Forwarded messages should also be ARC sealed if possible #1457

Merged

ikedas added this to the 6.2.72 milestone Sep 24, 2022

ikedas closed this as completed in #1452 Nov 15, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Should addition of ARC seal depend on DKIM signing? #1450

Should addition of ARC seal depend on DKIM signing? #1450

ikedas commented Jul 20, 2022

ikedas commented Jul 20, 2022

jrlevine commented Jul 20, 2022 •

edited

Loading

ikedas commented Jul 20, 2022 •

edited

Loading

jrlevine commented Jul 20, 2022 •

edited

Loading

ikedas commented Jul 21, 2022 •

edited

Loading

jrlevine commented Jul 21, 2022

ikedas commented Jul 22, 2022 •

edited

Loading

jrlevine commented Jul 22, 2022

jrlevine commented Jul 22, 2022

ikedas commented Jul 22, 2022 •

edited

Loading

ikedas commented Jul 22, 2022

jrlevine commented Jul 22, 2022 •

edited

Loading

ikedas commented Jul 22, 2022

ikedas commented Jul 27, 2022

ikedas commented Sep 20, 2022

Should addition of ARC seal depend on DKIM signing? #1450

Should addition of ARC seal depend on DKIM signing? #1450

Comments

ikedas commented Jul 20, 2022

ikedas commented Jul 20, 2022

jrlevine commented Jul 20, 2022 • edited Loading

ikedas commented Jul 20, 2022 • edited Loading

jrlevine commented Jul 20, 2022 • edited Loading

ikedas commented Jul 21, 2022 • edited Loading

jrlevine commented Jul 21, 2022

ikedas commented Jul 22, 2022 • edited Loading

jrlevine commented Jul 22, 2022

jrlevine commented Jul 22, 2022

ikedas commented Jul 22, 2022 • edited Loading

ikedas commented Jul 22, 2022

jrlevine commented Jul 22, 2022 • edited Loading

ikedas commented Jul 22, 2022

ikedas commented Jul 27, 2022

ikedas commented Sep 20, 2022

jrlevine commented Jul 20, 2022 •

edited

Loading

ikedas commented Jul 20, 2022 •

edited

Loading

jrlevine commented Jul 20, 2022 •

edited

Loading

ikedas commented Jul 21, 2022 •

edited

Loading

ikedas commented Jul 22, 2022 •

edited

Loading

ikedas commented Jul 22, 2022 •

edited

Loading

jrlevine commented Jul 22, 2022 •

edited

Loading