Subject: [dmarc-ietf] Message sender as part of ARC chain?

From: Martijn van der Lee <[email-masked]>
Date: Thu, 12 Jul 2018 09:58:44 +0200

This is more in regards to the Recommended Usage draft than the ARC spec
itself (and possibly this has been answered elsewhere before).

Is a message sender allowed (or perhaps even advised) to be part of the ARC
chain as the first set of the chain?

--
Martijn van der Lee

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 12 Jul 2018 03:55:44 -0700

On Thu, Jul 12, 2018 at 12:58 AM, Martijn van der Lee <
martijn=[email-masked]> wrote:

> Is a message sender allowed (or perhaps even advised) to be part of the
> ARC chain as the first set of the chain?
>

Allowed = yes; advised = no

The protocol was explicitly designed to require no changes on the part of
the initiating ADMD. It is only for intermediary ADMDs, and especially
those which do or may change the message in some fashion (that impacts
authentication mechanisms). Sort of by definition (SPF-wise), that would
include all intermediaries, but we mainly have in mind those which break
the validity of the DKIM signature(s).

--Kurt

---

From: Martijn van der Lee <[email-masked]>
Date: Thu, 12 Jul 2018 13:37:41 +0200

Perhaps "advised" was a wrong choice of words. I understand that ARC makes
no additional demands on the sender. But would it be beneficial or harmful
(or neutral) for the sender to do so anyway?

I can imagine validators taking note of ARC capability of an ADMD for
reputation tracking. If an email is send by a sender known to start the ARC
chain itself, the start of a chain by a malicious sender spoofing as an
intermediary could help a validator draw more appropriate conclusions about
it's trustworthiness. It would still be possible for a malicious party to
spoof an entire chain, but it would be just a little bit harder to do so. I
was just wondering if there could be any real-world validity to these
assumptions.

-- 
Best regards,

Martijn van der Lee
Software developer

DMARC Analyzer - Trusted. Email. Delivered.

Stationsplein 12 | 1211 EX | Hilversum | The Netherlands
www.dmarcanalyzer.com | +31 (0) 85 13 00 788

We are accredited on security and privacy by the DDMA Privacy Authority.

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 12 Jul 2018 09:03:21 -0400

On Thu, Jul 12, 2018, 07:38 Martijn van der Lee <[email-masked]>
wrote:

> ... would it be beneficial or harmful (or neutral) for the sender to do so
> anyway?
>

Interesting thoughts. Starting an ARC series at the initial ADMD could give
such a signal but I can think of easier ways to do so - perhaps a "I
support ARC" bumper sticker published via DNS 😀

--Kurt

---

From: Seth Blank <[email-masked]>
Date: Thu, 12 Jul 2018 09:15:35 -0700

On Thu, Jul 12, 2018 at 6:03 AM, Kurt Andersen (b) <[email-masked]> wrote:

>> ... would it be beneficial or harmful (or neutral) for the sender to do
>> so anyway?
>>
>
Sections 5.1.4 and 5.1.5 explicitly call out that it's safe to Seal. As
Kurt mentioned, the marginal benefit for a sender to Seal on origination is
thin, but it is by design not harmful.

> Interesting thoughts. Starting an ARC series at the initial ADMD could
> give such a signal but I can think of easier ways to do so - perhaps a "I

Some receivers are already considering using this as a heuristic,
especially as adoption ramps up and consistent Sealers become well known.
"If we always see an ARC Seal from domain example.org, and we get a message
that doesn't have one, scrutinize that message more thoroughly."

To Kurt's comment about ARC in DNS, that's trickier, because ARC is the
responsibility of a breaking intermediary, but a flag in DNS shifts some
responsibility to the sender about mailflow that sender can't know about.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 12 Jul 2018 10:15:08 -0700

> ARC chain as the first set of the chain?

Just for clarity, do you mean the author or the originator?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 12 Jul 2018 11:03:26 -0700

> responsibility to the sender about mailflow that sender can't know about.

I was (somewhat playfully) thinking that one could "advertise" the
authentication mechanisms which one employs both on the sending
(authentication by) and receiving (enforcement by) sides. For instance, a
DMARC record implies that one supports *SPF ^ DKIM" analysis of outbound
traffic but does not let a receiver know that they could also expect BATV
or other signals. Maybe "scout merit badges" would be a better analogy than
bumper stickers :-) It could be a way for ADMDs to indicate what *bona
fides* a receiver should look for.

On the receiver side, it could advertise FBLs, enforcement, reporting, etc.
but this strays a bit further from "ARC as a protocol" and "using ARC".

--Kurt