On Mon, Aug 20, 2018 at 7:18 PM, John Levine wrote:
> In article gmail.com> you write:
> >My contention to Seth is that in a multi-hop scenario, the *only* report
> >with meaningful data will be the one from the handler who made the "fail"
> >determination and any subsequent reports are untrustw
In article
you write:
>My contention to Seth is that in a multi-hop scenario, the *only* report
>with meaningful data will be the one from the handler who made the "fail"
>determination and any subsequent reports are untrustworthy.
Assuming that "subsequent" means earlier in the chain, I agree.
We are planning the next in-person ARC interop day on Friday, 2018-10-12
(the Friday following the Brooklyn M3AAWG meeting). For people attending in
person, the meeting will be hosted at the Empire State Building.
More details are still being finalized, but if you are coming to the M3AAWG
meeting,
Seth and I discussed this topic today and I think that the central problem
that is being debated has to do with *generating* the DMARC report content.
Almost everyone agrees that a broken chain is broken and unredeemable -
whether that breakage is structural or whether it is because of
non-validati
Hi,
I agree with your comments.
My input.
Keep in mind, that ignorant (non-supportive) ARC nodes will continue
to process all DKIM-signature(s) found, such as what I see with your
message:
Authentication-Results: dkim.winserver.com;
dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.
(back from vacation and catching up)
On Tue, Aug 14, 2018 at 8:58 PM, Seth Blank wrote:
> There are THREE consumers of ARC data (forgive me for the names, they're
> less specific than I'd like):
>
> 1) The ARC Validator. When the Validator sees a cv=fail, processing stops,
> the chain is dead, a
