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

"mhammer@americangreetings.com" <mhammer@americangreetings.com> Thu, 25 May 2017 12:59 UTC

Return-Path: <mhammer@americangreetings.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B12C129535 for <dmarc@ietfa.amsl.com>; Thu, 25 May 2017 05:59:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level:
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=americangreetings.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHiNsNKYiecm for <dmarc@ietfa.amsl.com>; Thu, 25 May 2017 05:59:55 -0700 (PDT)
Received: from mailer2.americangreetings.com (mailer2.americangreetings.com [66.119.43.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 916D212944A for <dmarc@ietf.org>; Thu, 25 May 2017 05:59:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=americangreetings.com; s=q42010; c=relaxed/relaxed; q=dns/txt; i=@americangreetings.com; t=1495717194; x=1527253194; h=From:Subject:Date:To:Cc:Reply-To:Message-ID:MIME-Version:Content-Type; bh=+L4I1svCxkaAC5YeNOctMZZjtHA05hjqxvw/Lu0y0XQ=; b=LWF6re6EIwSzerLnZeNzXS33CqQUrCmV88CA72opyeoc26acRwM1nNdmIrtmCs/q ZDExJON52c73PEwpNOB9zckdoIzGmcDcGC6Ni290DNM3K/fzGLoR+W2sODILpHSn MF5e78BGc5ekXKZosb9FeOv4rv6Nq8Yh9LO8QmeuZzg=;
Received: from [66.119.43.83] ([66.119.43.83:31118] helo=dc3-mbox.ops.ag.com) by momentum7 (envelope-from <mhammer@americangreetings.com>) (ecelerity 3.6.18.52357 r(Core:3.6.18.0)) with ESMTP id 2D/50-38523-A45D6295; Thu, 25 May 2017 08:59:54 -0400
Received: from [10.210.42.34] ([10.210.42.34]) by dc3-mbox.ops.ag.com (8.14.4/8.14.4) with ESMTP id v4PCxrRH012406 for <dmarc@ietf.org>; Thu, 25 May 2017 08:59:53 -0400
To: dmarc@ietf.org
References: <CAOZAAfMC_EPhhBVc0UVJEbkhaR6G3wy7UQXUTrc_FM50SB0GRQ@mail.gmail.com> <CABa8R6tyhGffHXDpMsR_T31AyHyyHNdw6Nfk8UCk_KDSOFf44Q@mail.gmail.com>
From: "mhammer@americangreetings.com" <mhammer@americangreetings.com>
Message-ID: <4b8b3b8e-4c0a-1ea7-8328-bc2febd19db9@americangreetings.com>
Date: Thu, 25 May 2017 08:59:53 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CABa8R6tyhGffHXDpMsR_T31AyHyyHNdw6Nfk8UCk_KDSOFf44Q@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------B18D2E2F7CC1834D5B2B1015"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/_g8EDxbOVl70DN9DXhXxgRGtCJs>
Subject: Re: [dmarc-ietf] Does the concept of an ARC tempfail make any sense?
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 May 2017 12:59:58 -0000

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