[dmarc-ietf] Does the concept of an ARC tempfail make any sense?
Seth Blank <seth@valimail.com> Wed, 24 May 2017 18:30 UTC
Return-Path: <seth@valimail.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 7C7B512949E for <dmarc@ietfa.amsl.com>; Wed, 24 May 2017 11:30:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.099
X-Spam-Level:
X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 RA6Z1IsFLIyH for <dmarc@ietfa.amsl.com>; Wed, 24 May 2017 11:30:47 -0700 (PDT)
Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788E3124281 for <dmarc@ietf.org>; Wed, 24 May 2017 11:30:47 -0700 (PDT)
Received: by mail-qt0-x235.google.com with SMTP id c13so162869579qtc.1 for <dmarc@ietf.org>; Wed, 24 May 2017 11:30:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=tHqb3i3vq4HuyW0FNHPDJ7F92wtM5P8wxY5PlQt4IyM=; b=cVVYQOUo7O37I7u0O3Kth6ljL31ji2nkzzsU91M2RkUqlSSf2swN++58VCeePh7CCD toj9G/b6gIeTvIWRhizPd3hTR25c0nfwNQIbaiHW6aDCt0lJn6cAAg0W+l0wNzAyrYtA 6TIyGx3LKJhO5rzqfHbER07iWnjN2Nm5MhLs7HGsfXZk4FCOPtSPNqdHqAI6i56rmYTN UCXwd/jF+IyEdkr+iL6lP46mkrX5JDtkCz2YWm+vVJ0m+0nyRIHD2vZAxgBuNpgurYnX Em9aFMnKy8tRpT2iCMRqX9skvwH+QfIsmwaAzw8pl/RGUnuniIXHK/Kz/8EmyafS//Qp wwxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tHqb3i3vq4HuyW0FNHPDJ7F92wtM5P8wxY5PlQt4IyM=; b=NWUKI8L5e1bWEMT9KqQ1qIOmCEwACgNMnXg6+HHqjEIHLC20ZLJ3ucUIkif0rCtw4g 4D8d9FNAm0ksiLqJDTbY34LFS0lNajCwlBmEN6GwGAI9VpO3zec4VYYmfyBhb0l+rKvt ngJ4YC+1YKbqYuWYrdmQ2ZuCaaLJZhSemEkTrj0ZRUAHtjCSUVVHZCgdGdDIEeIO8dr+ 4KxrZGapKCDmCsTEKzQO2ogzKFeUxaseL7TK2I1FMZmbvMepgJmRZuxR23j7HbVi1kNb nBXhvYkA/FYV+0Ubk+XELyOxRr8tWvIMR2ersJ54q5nxLkMtFP16yAYn9n5ScMc10OxJ TZ0A==
X-Gm-Message-State: AODbwcDOXdg4mDi4bYIt/uDwE1uAFzvpi3lbyOgz/ah/h3XL8/ZaYK17 pQKGHUzbmQn6pUHwIl052gZJ++9I0QqaziI=
X-Received: by 10.200.34.98 with SMTP id p31mr37150648qtp.2.1495650646309; Wed, 24 May 2017 11:30:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.42.242 with HTTP; Wed, 24 May 2017 11:30:25 -0700 (PDT)
From: Seth Blank <seth@valimail.com>
Date: Wed, 24 May 2017 11:30:25 -0700
Message-ID: <CAOZAAfMC_EPhhBVc0UVJEbkhaR6G3wy7UQXUTrc_FM50SB0GRQ@mail.gmail.com>
To: dmarc@ietf.org
Content-Type: multipart/alternative; boundary="001a11403b7a7b6d190550494dd4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/W_09ppxZKW7dA61E6y0kUR7CBrM>
Subject: [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: Wed, 24 May 2017 18:30:49 -0000
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-ietf] Does the concept of an ARC tempfail … Seth Blank
- Re: [dmarc-ietf] Does the concept of an ARC tempf… Brandon Long
- Re: [dmarc-ietf] Does the concept of an ARC tempf… mhammer@americangreetings.com