On Sat, Aug 20, 2016 at 4:02 AM, Alessandro Vesely <ves...@tana.it> wrote:
> On Fri 19/Aug/2016 01:40:42 +0200 Brandon Long wrote: > > On Wed, Aug 17, 2016 at 2:47 AM, Alessandro Vesely <ves...@tana.it> > 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 your MTA is too small to use combinatorial trust assessments, then you are stuck with the same two options you have today: manual whitelists or using a service to give you that information. If you're small enough, I don't think manually whitelisting the mailing list servers your users are subscribed to would be that challenging, especially if you receive the DMARC reports your server generates. 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. > So, any message sent from A to B can then be used as a replay with any content to any party as long as the To/Cc are intact? That seems pretty useless. Brandon
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
