IETF Logo Mail Archive

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

Douglas Otis <doug.mtview@gmail.com> Wed, 18 March 2015 22:40 UTC

Return-Path: <doug.mtview@gmail.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3031A90EE for <dmarc@ietfa.amsl.com>; Wed, 18 Mar 2015 15:40:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 1G2NKHk2UvZo for <dmarc@ietfa.amsl.com>; Wed, 18 Mar 2015 15:40:33 -0700 (PDT)
Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (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 A43B31A8927 for <dmarc@ietf.org>; Wed, 18 Mar 2015 15:40:33 -0700 (PDT)
Received: by pabyw6 with SMTP id yw6so55586196pab.2 for <dmarc@ietf.org>; Wed, 18 Mar 2015 15:40:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=q3HFEQmkiYaCWrBwdSWEALm5F8eMTFjtt/tgFa2l0Yc=; b=Uyp8uaMqgkwde1mUAmV/CuiqtVNAm1qnvqoMQFl9dAhFQh+N7nfy/sz+jntPIAHTub vv1eOPCRECgntl2VIImFCNC63EE7F1NVJnNzM/voYJTKxO0xO6NJVMMzUjMayxIiCR/R N74LqI0oAkizFBt30RAEG27P0Zgd4HQrxSO8Z1rDvELHedg1+8ouxYdoTTZOr0qeLdBS 1hpIcTs/onOaSs0RjNKQqRe0Yt+RvL0AvwTlRBP++ZOYihd4lSl6Xd2JnIsMLrkMTiJU Uw7nGfscNevGcxeSy+Vx2nVY3JF50THRwK1RYNuMarYIOkWiam+x2cCSODJTwT50ta4N 6HGg==
X-Received: by 10.66.241.36 with SMTP id wf4mr110776315pac.8.1426718433317; Wed, 18 Mar 2015 15:40:33 -0700 (PDT)
Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id y2sm29252437pdm.31.2015.03.18.15.40.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Mar 2015 15:40:32 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: text/plain; charset="us-ascii"
From: Douglas Otis <doug.mtview@gmail.com>
In-Reply-To: <CAL0qLwbvp_-zt61ZBFUkChHoB55Z3RjCoMmD-uHaU3RD4RZM9Q@mail.gmail.com>
Date: Wed, 18 Mar 2015 15:40:30 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <C50BF729-D096-438C-A4A6-F720E59BFC9C@gmail.com>
References: <20150318200459.23F9B18020A@rfc-editor.org> <CAL0qLwbvp_-zt61ZBFUkChHoB55Z3RjCoMmD-uHaU3RD4RZM9Q@mail.gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmarc/zWfm-t1UYwldoYCblfq6qxQ7dSk>
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 18 Mar 2015 22:40:35 -0000

Dear DMARC WG,

Now that RFC7489 has been published, there remains several 
unresolved problems this WG is charted to resolve, primarily--
1. Addressing the issues with indirect mail flows

These are reviewed by
https://tools.ietf.org/html/draft-dmarc-interoperability-00

https://tools.ietf.org/html/draft-otis-dmarc-author-align-01
was written to highlight possible solutions.

John Levine's recommendation that mailing-list operators take on 
the costly burden of having their participants change their providers 
is not practical.  Based upon the almost complete lack of interest of
bulk email providers at promoting a solution, it seems the path
forward is to define a new non-aligned header field able to retain the 
author role information, otherwise the From is likely overwritten as 
the only practical means of ensuring message acceptance in the face of 
provider DMARC (ab)use.

By defining a new header field, this should reduce disparity in where to 
find the author role than that caused by current ad hoc solutions.  Such 
a definition would also better avoid downgrading 'reject' into 
'quarantine'.

Any thoughts?

Regards,
Douglas Otis

v2.23.0 | Report a Bug | By Email