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 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 protected]
<mailto:[email protected]>> 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
--
logo for sig file.png
Bringing Trust to Email
Seth Blank | Head of Product for Open Source and Protocols
[email protected] <mailto:[email protected]>+1-415-894-2724
<tel:415-894-2724>
_______________________________________________ dmarc mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/dmarc
<https://www.ietf.org/mailman/listinfo/dmarc>
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
