On Fri 19/Aug/2016 01:40:42 +0200 Brandon Long wrote:
> On Wed, Aug 17, 2016 at 2:47 AM, Alessandro Vesely <[email protected]> wrote:
>> On Sat 13/Aug/2016 17:22:52 +0200 Dave Crocker wrote:
>>>
>>> [...] With DKIM, trust assessment is of the entity doing the
>>> signing, typically the originating service. With ARC, that
>>> assessment still must be made, but it must be coupled with an
>>> assessment of the first ARC-signing entity.
>>>
>>> Maybe that's not a big deal. But I think that combinatorial
>>> trust assessments are new and therefore might be challenging.
>>
>> That challenge can only be accepted by mailbox providers who are
>> large enough to maintain a statistically meaningful perspective of
>> global Internet mailing. Smallish MTAs will likely have to take
>> recourse to dnswl.org, possibly after some more attempts at
>> creating protocol-specific white lists.
>>
>> Formal criteria to establish when valid ARC fields can inhibit
>> DMARC's policy would seem to be better suited for protocol
>> specifications. I proposed ARC-0, but there may be better methods
>> than that.
>> [...]
>
> With ARC, one's MTA could do the DKIM check, fix the message, and
> then ARC sign the result.
How can that ARC set be used by the next hop? *Guidance for receivers*
is based on /sufficient history/:
Final message recipients may or may not
choose to examine these results when messages fail other
authentication checks. They are more likely to override, say, a
failing DMARC result in the presence of an intact ARC chain where the
participating ARC message handlers have been observed to not convey
"bad" content in the past, and the initial ARC participant indicates
the message they received had passed authentication checks.
Say A -> B -> C are the MTAs: C sees a message where B is cited in the
To: or Cc: header fields. The message is ARC signed by B. B says A's
DKIM signature was good, but now it is broken. A's DMARC policy says
that C should reject in that case. What should C do?
If C is gmail, it likely has sufficient history to know how A and B
behave. But what about small MTAs whose email flow is statistically not
enough to use combinatorial trust assessments?
If A had added a second DKIM signature, signing just the To: or Cc:
field(s) which cited B, with l=0 for the body, then that signature
likely survived B's fixing and hence C could infer that B is a true (not
self-styled) forwarder. IOW, A's second (weak) signature provides C
with a formal criterion to instruct its local policy to accept email
that fails the DMARC mechanism check even if A has published a "reject"
policy.
So, what I called ARC-0 in my former proposal, doesn't really have much
to do with ARC. The concept is weak signatures. Of course, they won't
work unless carefully standardized and implemented. The question is if
they will ever work at all, and if this WG is willing to consider them.
If not, we need to address Dave's concern some other way, or resign
ourselves to building a solution which will likely work 98.7% for some
and 0.2% for others.
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
