Re: [dmarc-ietf] Does the concept of an ARC tempfail make any sense?

So, last year I did add the concept of a dmarc tempfail to our code, but
the main utility of that was to respond with a 4xx error on p=reject
instead of a 5xx error.

I could imagine having an arc temp fail that could have otherwise
overridden a p=reject having the same utility.

I could also imagine that an arc temp fail at a non-modifying hop shouldn't
be any different than just not signing that hop.  If if is a modifying hop,
then the chain will break on the next hop that's able to successfully
evaluate.

If you encapsulate the failure in the chain, does that gain anything?  Can
a subsequent hop basically override the tempfail to a fail or pass?

I guess a tempfail hop would still have valid spf/dkim data in the new AAR,
just an inability to use any previous information.  In that sense, it's
like removing the existing chain and replacing it.  Again, in that sense, a
tempfail would be like not processing the arc chain at all, validity wise.
Ie, you can sign an arc chain without validating it.  If you did that with
a cv=pass, you're taking "ownership" of a potentially invalid chain, but if
we add cv=tempfail, maybe the ownership is voided.

I think it makes the chain harder to reason about, and I'm not sure the
added utility is useful.

Brandon

On Wed, May 24, 2017 at 11:30 AM, Seth Blank <seth@valimail.com> wrote:

> I couldn't find prior discussion about this, if I missed it somehow could
> someone cluestick me?
>
> We've been working with Murray on openarc, and there are some chain
> validation failure modes that closely resemble a dkim tempfail (for
> instance, DNS unresponsiveness when trying to query for a key).
>
> Right now, these create chain states of cv=fail.
>
> We believe this is the correct behavior, as a message in transit amongst
> multiple hops cannot cleanly have a temporary error retried, so the
> temporary failure effectively becomes a permanent error for the chain and
> cv=fail is justified because the chain is dead from this point forward.
>
> That said, is there any value (especially for final receivers), in
> transmitting that this failure was due to a temporary error and not
> necessarily a permanent one? And is so, where would this transmission live?
>
> Seth
>
> --
>
> [image: logo for sig file.png]
>
> Bringing Trust to Email
>
> Seth Blank | Head of Product for Open Source and Protocols
> seth@valimail.com
> +1-415-894-2724 <415-894-2724>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
>