IETF Logo Mail Archive

Re: [dmarc-ietf] implementation update

Brandon Long <blong@google.com> Tue, 23 May 2017 15:51 UTC

Return-Path: <blong@google.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 B6274129B94 for <dmarc@ietfa.amsl.com>; Tue, 23 May 2017 08:51:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level:
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 3zr9EY3Ep00V for <dmarc@ietfa.amsl.com>; Tue, 23 May 2017 08:51:42 -0700 (PDT)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 0E893129B81 for <dmarc@ietf.org>; Tue, 23 May 2017 08:51:42 -0700 (PDT)
Received: by mail-oi0-x235.google.com with SMTP id h4so206738116oib.3 for <dmarc@ietf.org>; Tue, 23 May 2017 08:51:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jOm9IrvwCpN6gIfWaS7qZri+I2V61bG9Zu3iNNs5tKk=; b=L4/eNSQhvvb6dJHvU9KEDkvJDH0geb5hhXE2KHz9m1hRCciOyPjjrMScKTLw/QBg+R AWHTRrlBDK6KIuwnMZh4cQWdLfojta0HGsSYSnpBGq4Mj7utY6SE4tr2d2F1HQAqqeAv BaCyxBPPSj0yCCsD3jeQXVZ6eAu4G58MucLAZfIxNu646iyYuw2f+qSUVNBz3VMWIT5t sFNBqkLg+iiKHTYY7NBi3/iSm4TSHmSAKx73xze59SyJPbU6wyWaxCc6HIXtiSmAdLXR k9AMUz74Js6Hf39aYL+oyKbJiPSGc4KV0hStQAdfoHBUjtTmz03J/nGX52OLgaTnZ3Q1 a20A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jOm9IrvwCpN6gIfWaS7qZri+I2V61bG9Zu3iNNs5tKk=; b=VsiTtlRtaPBbbLQ+xABSNhfz2bErsUaMvRrM9Y7u5M89sAx+DlUOJoz7PyaOl1NdN9 ah1uPdyx3toj8RtVDbn0c4HFihS/o+1RwJVMQva1WZpFoJDQYbPgT7KWbM4AFnAAuMPW ZSBnio+1oeAGICVtQuRn/m9FKqkFr7U8uYgnXsSwlpgJiBHwHzcyA5BN4J1oRDXXqWt3 o4L+eclvl4xF4GIYgFgeS14AG2Fy8bJClvLhqTIiYxBTMfO9ZkdIaguCYu76raMPPu5k yQmsWjpTm9gylnSh9VpGtHaTc6uKDYtXhVUvkFjANi90dGMJegNzC+fKAOQh98uKo/nX eZ3Q==
X-Gm-Message-State: AODbwcChoXwRPODyQkGU7v/cOqSN1H1W2ZnVhdBabHv8AU15Br8CHXZd ZTDucgV4LvPfGZzdC69DUm807zT13cB3sGs=
X-Received: by 10.202.102.229 with SMTP id m98mr13150043oik.177.1495554701063; Tue, 23 May 2017 08:51:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.8.34 with HTTP; Tue, 23 May 2017 08:51:40 -0700 (PDT)
Received: by 10.182.8.34 with HTTP; Tue, 23 May 2017 08:51:40 -0700 (PDT)
In-Reply-To: <592454C6.9020203@isdg.net>
References: <CABa8R6sMXhvXY5CojeHfRZ2HsmHM=RUCkCaaL-1jTXc7Sf4eiA@mail.gmail.com> <CABa8R6v9kjrVKDXx+CvYXKPJe+6nZRhqCxBbGb6q9yS3d+UdnQ@mail.gmail.com> <592454C6.9020203@isdg.net>
From: Brandon Long <blong@google.com>
Date: Tue, 23 May 2017 08:51:40 -0700
Message-ID: <CABa8R6s5xA_2G9U1P8h-Uu_S7OciK3n15kET108CBQ4DT1rEVA@mail.gmail.com>
To: Hector Santos <hsantos@isdg.net>
Cc: dmarc@ietf.org
Content-Type: multipart/alternative; boundary="001a1140b04ab35a92055032f67a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/lCEjoSRihZhmfaNmaAvg4Flb2ik>
Subject: Re: [dmarc-ietf] implementation update
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: Tue, 23 May 2017 15:51:44 -0000

Why should the sender be involved in determining which forwarding is
allowed?

The arc chain specifies each of the hops, and the receiving domain is in
the best position to know about the intermediaries.

I can imagine a whitelist style rbl allowing folks to know which
intermediaries to trust, but I don't get having to have each sender know
all intermediaries ahead of time.

Brandon

On May 23, 2017 8:27 AM, "Hector Santos" <hsantos@isdg.net> wrote:

> On 5/11/2017 7:08 PM, Brandon Long wrote:
>
>>
>> We're still a couple weeks away from using this information in dmarc
>> evaluation.
>>
>
> If my understanding is correct of the ARC work done, and thanks to Murray
> for his draft rewrite ("better" flow, mail tech read),  ARC will allow an
> "indirect" message, i.e. list message, to survive the original author
> domain signature, provided the final receiver reads the ARC headers with a
> 3rd party ARC seal?
>
> If so, are we still missing a *deterministic* author domain 3rd party
> signature authorization procedure/protocol that links DMARC with ARC?
>
> When I last left this work, I called that a "Registration" scheme,
> process, I thought was inherently missing in all the DKIM "policy" proposed
> solutions.
>
> Before I begin to look at implementing ARC for our mail server,  I am
> still hopeful for a "registration" DKIM/POLICY protocol.   This is could be
> as simple as an extended DMARC "arc" tag, hopefully as an optional signal
> to augment something like ATPS (Authorized Third Party Signature). Maybe a
> ATPAS (Authorized Third Party Arc Seal)?
>
> Thanks
>
> --
> HLS
>
>
>

v2.23.0 | Report a Bug | By Email