Re: [dmarc-ietf] AND vs. OR (was Re: wiki vs. list?)
Brett McDowell <brettmcdowell@gmail.com> Mon, 27 October 2014 20:55 UTC
Return-Path: <brettmcdowell@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 522441AD4BC for <dmarc@ietfa.amsl.com>; Mon, 27 Oct 2014 13:55:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.397
X-Spam-Level:
X-Spam-Status: No, score=-1.397 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, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no
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 YSpsYYfX3LpG for <dmarc@ietfa.amsl.com>; Mon, 27 Oct 2014 13:55:34 -0700 (PDT)
Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A7B81AD3E9 for <dmarc@ietf.org>; Mon, 27 Oct 2014 13:55:31 -0700 (PDT)
Received: by mail-qa0-f42.google.com with SMTP id cs9so4464086qab.15 for <dmarc@ietf.org>; Mon, 27 Oct 2014 13:55:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=gyAKy6MhQz0x5s10cCHXI16EuW1naCuDzBkLkObO/mw=; b=qPBqg/9+1lV8WPpzxPguKBLF3+iKTGWILU/EB5sIty6Z10Mr2LGBZoe9Up9jz3Axv3 JkJBAiGtieods4oKGn/LAA+h9G9HQM2BTd+P3GGzhhdZCIciEL7PcpV/K7PIYBxvXq3s oi2dCzofuOm2Y5ehjTuVP6/i9x40Yy+1cT3Qib3etoA3OawUbu2Rlf/LPaNwiunFtheh z7qf7O4iKXbDOI/r1GUXExixIZ3NxI8SjJof6MpRF+jwHLTxpC2HdzUf8o4KJk4hbyL3 aqCe1j4RgARtU8TCI2ANKVFCcnKN9MtZEUgvjvcQZZbddfEbZF4p/zJFgnn479hn+OFJ Apqw==
X-Received: by 10.224.38.130 with SMTP id b2mr37026543qae.11.1414443330375; Mon, 27 Oct 2014 13:55:30 -0700 (PDT)
Received: from [192.168.1.114] (c-24-91-31-164.hsd1.ma.comcast.net. [24.91.31.164]) by mx.google.com with ESMTPSA id u46sm12079312qgd.3.2014.10.27.13.55.28 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 13:55:29 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_41466453-C974-42F7-9B64-C565B5EB1C35"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Brett McDowell <brettmcdowell@gmail.com>
In-Reply-To: <EED02883-386B-403E-80A5-73C17C2E45E3@gmail.com>
Date: Mon, 27 Oct 2014 16:55:25 -0400
Message-Id: <19409258-9DAE-49CF-BD37-DDD648BAFBED@gmail.com>
References: <CABuGu1qDAaF0es0ikVk2KbgQaPTFeybKDu-hP=jY17txSuJxaw@mail.gmail.com> <544A41D4.2000206@isdg.net> <544A60AB.3020308@meetinghouse.net> <CABDkrv0jiDuLCVNzH5bfwYp3inn-wcRz+mPogPoRuxz0sYTU5Q@mail.gmail.com> <EED02883-386B-403E-80A5-73C17C2E45E3@gmail.com>
To: Douglas Otis <doug.mtview@gmail.com>
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/zek2_nS2YnZMtOll0Czphsn9wvQ
Cc: dmarc <dmarc@ietf.org>, Mike Jones <mjones@mail.agari.com>
Subject: Re: [dmarc-ietf] AND vs. OR (was Re: wiki vs. list?)
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: Mon, 27 Oct 2014 20:55:37 -0000
Doug, you missed (at least) one option which I will characterize as “transient trust”. I suggest transient trust could be implemented at scale (for many use cases) via something like OAR [1] and a companion BCP. -Brett [1] http://tools.ietf.org/html/draft-kucherawy-original-authres-00 <http://tools.ietf.org/html/draft-kucherawy-original-authres-00> > On Oct 27, 2014, at 2:56 PM, Douglas Otis <doug.mtview@gmail.com> wrote: > > > On Oct 27, 2014, at 10:30 AM, Mike Jones <mjones@mail.agari.com <mailto:mjones@mail.agari.com>> wrote: > >> On Fri, Oct 24, 2014 at 7:22 AM, Miles Fidelman <mfidelman@meetinghouse.net <mailto:mfidelman@meetinghouse.net>> wrote: >> Hector Santos wrote: >> Hi Kurt, >> >> If we are going to be picky about logic, then lets consider the symbolic correctness with short circuiting optimization, and it would be: >> >> DMARC = SPF or DKIM >> >> <snip> >> >> Am I missing something here? As I understand it, DMARC is MORE than SPF and DKIM. Specifically, as I understand it, sender field alignment, that's bit all of us who run mailing lists, is specific to DMARC. >> >> You're not missing anything. >> >> aligned SPF pass OR aligned DKIM pass = DMARC pass > > Dear Mike, > > Agreed. To further clarify the obvious, the WG needs to deal with large ISPs asserting DMARC p=reject against normal user accounts where, for legitimate messages, the From header field offered by various third-party services can not be aligned with either SPF or DKIM. > > Possible mitigations: > > 1) Develop a scheme for the DMARC domain to assert domain specific policy exceptions in the case of legitimate third-party services. > > 2) Create a group syntax able to bypass DMARC p= policy assertions by offering visual indications in the From header field that an exception may have been made. > > 3) Munge the domain of the From header field and expect users to hand edit addresses. > > 4) Adopt a new generic method (not list specific) conditionally replacing the role of the From header field with a new (invisible) header field. > > IMHO, options 3 and 4 should be avoided. > > Regards, > Douglas Otis > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org <mailto:dmarc@ietf.org> > https://www.ietf.org/mailman/listinfo/dmarc <https://www.ietf.org/mailman/listinfo/dmarc>
- [dmarc-ietf] AND vs. OR (was Re: wiki vs. list?) Kurt Andersen
- Re: [dmarc-ietf] AND vs. OR (was Re: wiki vs. lis… Hector Santos
- Re: [dmarc-ietf] AND vs. OR (was Re: wiki vs. lis… Miles Fidelman
- Re: [dmarc-ietf] AND vs. OR (was Re: wiki vs. lis… Mike Jones
- Re: [dmarc-ietf] AND vs. OR (was Re: wiki vs. lis… Dave Crocker
- Re: [dmarc-ietf] AND vs. OR (was Re: wiki vs. lis… Douglas Otis
- Re: [dmarc-ietf] AND vs. OR (was Re: wiki vs. lis… Brett McDowell
- Re: [dmarc-ietf] AND vs. OR (was Re: wiki vs. lis… Douglas Otis
- Re: [dmarc-ietf] AND vs. OR (was Re: wiki vs. lis… Brett McDowell