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

From: Seth Blank <[email-masked]>
Date: Wed, 24 May 2017 11:30:25 -0700

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

-- 

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols
[email-masked]
+1-415-894-2724 <415-894-2724>

---

From: Brandon Long <[email-masked]>
Date: Wed, 24 May 2017 15:56:16 -0700

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 <[email-masked]> wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 25 May 2017 08:59:53 -0400

I'm normally not a fan of reputation but this may be a case where 
reputation might be useful. I'd have to think on this some more.

Mike

On 5/24/2017 6:56 PM, Brandon Long wrote:
> 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 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 <[email-masked] 
> <mailto:[email-masked]>> 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).
>
>     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.
>
>     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
>
>     -- 
>
>     logo for sig file.png
>
>     Bringing Trust to Email
>
>     [email-masked] <mailto:[email-masked]>+1-415-894-2724
>     <tel:415-894-2724>
>     _______________________________________________ dmarc mailing list
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/dmarc> 
>