IETF Logo Mail Archive

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

Terry Zink <tzink@exchange.microsoft.com> Wed, 18 March 2015 23:38 UTC

Return-Path: <tzink@exchange.microsoft.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 160D31A9174 for <dmarc@ietfa.amsl.com>; Wed, 18 Mar 2015 16:38:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 VZCrGsBJw-xR for <dmarc@ietfa.amsl.com>; Wed, 18 Mar 2015 16:38:33 -0700 (PDT)
Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40F6B1A9170 for <dmarc@ietf.org>; Wed, 18 Mar 2015 16:38:33 -0700 (PDT)
Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([10.255.109.167]) by BL2SR01MB604.namsdf01.sdf.exchangelabs.com ([10.255.109.166]) with Microsoft SMTP Server (TLS) id 15.1.130.2; Wed, 18 Mar 2015 23:38:31 +0000
Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.4.240]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.4.240]) with mapi id 15.01.0130.000; Wed, 18 Mar 2015 23:38:30 +0000
From: Terry Zink <tzink@exchange.microsoft.com>
To: "dmarc@ietf.org" <dmarc@ietf.org>
Thread-Topic: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
Thread-Index: AQHQYcySX0+9LP+ZM0WUWBZb9GzSo50i5WUQ
Date: Wed, 18 Mar 2015 23:38:30 +0000
Message-ID: <BL2SR01MB60534ABA5171ABD31679F4A96000@BL2SR01MB605.namsdf01.sdf.exchangelabs.com>
References: <20150318200459.23F9B18020A@rfc-editor.org> <CAL0qLwbvp_-zt61ZBFUkChHoB55Z3RjCoMmD-uHaU3RD4RZM9Q@mail.gmail.com> <C50BF729-D096-438C-A4A6-F720E59BFC9C@gmail.com>
In-Reply-To: <C50BF729-D096-438C-A4A6-F720E59BFC9C@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:ed31::2]
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB604;
x-microsoft-antispam-prvs: <BL2SR01MB60472598E00AF0CEA57256296000@BL2SR01MB604.namsdf01.sdf.exchangelabs.com>
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(189002)(377454003)(199003)(33656002)(62966003)(77156002)(102836002)(15975445007)(68736005)(2900100001)(86362001)(450100001)(106356001)(105586002)(54356999)(50986999)(106116001)(76176999)(2501003)(92566002)(64706001)(46102003)(19580405001)(19580395003)(2950100001)(107886001)(2656002)(87936001)(2351001)(97736003)(101416001)(110136001)(3554006)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB604; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009); SRVR:BL2SR01MB604; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB604;
x-forefront-prvs: 051900244E
received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: exchange.microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2015 23:38:30.6018 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB604
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmarc/KluR4dpXsS3kL9VH-MAteOcvOGU>
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 23:38:35 -0000

> 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.

If bulk email providers have shown no interest in promoting a solution, why do we think they'd latch onto this new non-aligned header field as a solution?

-- Terry

-----Original Message-----
From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Douglas Otis
Sent: Wednesday, March 18, 2015 3:41 PM
To: Murray S. Kucherawy
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

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






_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

v2.23.0 | Report a Bug | By Email