Re: [dmarc-ietf] Rethinking DMARC for PSDs
Scott Kitterman <sklist@kitterman.com> Tue, 09 April 2019 00:37 UTC
Return-Path: <sklist@kitterman.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 4F356120162 for <dmarc@ietfa.amsl.com>; Mon, 8 Apr 2019 17:37:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=GlYETMyE; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Q5Hse2P4
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 hK0oeESk0ahp for <dmarc@ietfa.amsl.com>; Mon, 8 Apr 2019 17:37:54 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1603B12014D for <dmarc@ietf.org>; Mon, 8 Apr 2019 17:37:54 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 27C9BF80920; Mon, 8 Apr 2019 20:37:53 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1554770272; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=LPw/tv3BFolt3cd8ASY3NyW5zzJwVuIb6wpKnvmTiew=; b=GlYETMyEgn+mqXdrHhoEcrf3DPDTv8avRXeFRRzv7tbUbikZkyEt8mGQ 94AmC/k8bE+GEr5WKQJPbDiXNJXFCQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1554770272; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=LPw/tv3BFolt3cd8ASY3NyW5zzJwVuIb6wpKnvmTiew=; b=Q5Hse2P4xgSvAN3eYIuY2h/UKhfG77H1v4I9HY+10BmIJ2046b7Pe5eM gXKS3gLLC1RYNNXvcXz4VS1HghIEHThOJVIOb+uwrgImUUjpfg5km8aEcr 8DktpVV206BAoz+h3Z7aHPXf/q/Nwc5VhZJwSajEKbslZhwSXgpsB8fOUk FgiCo0NNOe+O2sOHzCyRBgZ+8NrepnFl5jcL+TI+kVoq582qGyWS30Oi8u dRGYAlEBsQ9PLzIDuTlKvBbgOBfZoho/Lxo8TEMQJttfumBRuHZ/7epRg3 aK9cZPCsyWvbNmWCb267TsdH2N0Ab75bqZjjw4Q3tpqjEOhFvwrpOQ==
Received: from [10.82.211.29] (mobile-166-170-31-60.mycingular.net [166.170.31.60]) by interserver.kitterman.com (Postfix) with ESMTPSA id 99F36F807D4; Mon, 8 Apr 2019 20:37:52 -0400 (EDT)
Date: Tue, 09 Apr 2019 00:37:51 +0000
In-Reply-To: <3e3a5997f71544f1a29fca8845fcbf60@bayviewphysicians.com>
References: <08252783d22443e79b707537df97c872@bayviewphysicians.com> <CABuGu1qdU4TbL3okQnNMn6yr+xODFfBG6o9ZOwJ1SgdjGJ95nA@mail.gmail.com> <08693A61-D3AD-448D-B64C-B36262756C65@kitterman.com> <3e3a5997f71544f1a29fca8845fcbf60@bayviewphysicians.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
To: dmarc@ietf.org
From: Scott Kitterman <sklist@kitterman.com>
Message-ID: <7EFE60BD-0EBB-431D-AC6B-C63383ECDFD0@kitterman.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/8r4iLh4J00ljZdirFNEqROSbvmg>
Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
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, 09 Apr 2019 00:37:56 -0000
No, I think you seriously misunderstand what the IETF does. It doesn't do product specifications, it does interoperability specifications. This is seriously off-topic for the DMARC working group list anyway. Scott K P.S. There are open source components to accomplish all the requirements you listed, some assembly required. Discussion though should happen somewhere else. On April 9, 2019 12:27:06 AM UTC, "Douglas E. Foster" <fosterd@bayviewphysicians.com> wrote: >Scott, you misunderstand what this type of standard would look like. >It >would defines Use Cases that the device should address, with some >acknowledgement to the tradeoffs between perceived risk and perceived >difficulty of implementation. > >Implementation suggestions may be part of the use case. It would be >hard >to implement SPF-like capability without using SPF data, but there are >many >ways that SPF data could be utilized. > >There are also fundamental security principles that everyone should be >following. > "Trusted communication (whitelist) should not occur until and unless >the >identity of the correspondent is confirmed." > Escalation of privilege (in this context, bypassing integrity >tests) >should be limited to the minimum necessary set of privileges to achieve >the >business requirement. > Mr. O'Driscoll's comments seemed to make the same mistake. The >configuration of email defenses will be different between a residential > >ISP, a large bank, and the US Army. However, the principles and use >cases >will be similar because any threat actor could take aim at any target. > >What differs is the perceived risk and the perceived complications from > >mitigating the risk, matched to each organizatoin's tolerance for risk. > > Nothing in this standard could be an absolute mandate, because only >government has the legal authority to say "This product cannot be sold >for >purpose X because it does not have feature Y," It could say, "You >must >implement this feature to claim compliance with RFC xxxx" This type >of >standard can and would pressure vendors to move in the right direction. > It >would also help purchases know how to be more intelligent shoppers. > > There is plenty of difficulty in reaching a consensus statement on >something like this, not least because each vendor wants to look >acceptable, no matter how inferior his current product may be. Just >because a topic is difficult does not mean there is no reason to >discuss >it. Working Groups exist because these issues take time and effort to > >flesh out. It is hard to argue that spam-getting-through is not an >important topic, but I suppose some people may try to do so. > > > > > >---------------------------------------- > From: "Scott Kitterman" <sklist@kitterman.com> >Sent: Monday, April 8, 2019 7:13 PM >To: dmarc@ietf.org >Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs > >On April 8, 2019 11:08:30 PM UTC, "Kurt Andersen (b)" ><kboth@drkurt.com> >wrote: >>On Mon, Apr 8, 2019 at 3:55 PM Douglas E. Foster < >>fosterd@bayviewphysicians.com> wrote: >> >>> I don't know how to express my shock at today's conversations. One >>of >>> the shocks comes from this: >>> >>> We have consensus that the better email filters do not need the >DMARC >>for >>> PSDs standard, because they are already blocking non-existent >>domains. >>> >> >>This neglects the benefit to the domain operators of receiving the >>reports >>about abuse of their domain space. For the end recipient of the bogus >>traffic, there is no difference. >> >> >>> The inferior email filters are not expected to implement this >>feature, >>> because they are inferior products. >>> >> >>Somewhat tautological, but most likely true. >> >> >>> Therefore the new standard has no expected benefit, but we need to >>finish >>> it anyway. >>> >> >>Incorrect - see my first point. > >The entire thing is further premised on the false premise that because >two >small mail operators find one filtering technique appropriate for their > >situation and scale, anyone that has a different design is inferior. > >Scott K > >_______________________________________________ >dmarc mailing list >dmarc@ietf.org >https://www.ietf.org/mailman/listinfo/dmarc >
- Re: [dmarc-ietf] Rethinking DMARC for PSDs Scott Kitterman
- [dmarc-ietf] Rethinking DMARC for PSDs Douglas E. Foster
- Re: [dmarc-ietf] Rethinking DMARC for PSDs John Levine
- Re: [dmarc-ietf] Rethinking DMARC for PSDs Jeremy Harris
- Re: [dmarc-ietf] Rethinking DMARC for PSDs Douglas E. Foster
- Re: [dmarc-ietf] Rethinking DMARC for PSDs Douglas E. Foster
- Re: [dmarc-ietf] Rethinking DMARC for PSDs Douglas E. Foster
- Re: [dmarc-ietf] Rethinking DMARC for PSDs John R Levine
- Re: [dmarc-ietf] Rethinking DMARC for PSDs Douglas E. Foster
- Re: [dmarc-ietf] Rethinking DMARC for PSDs Ken O'Driscoll
- Re: [dmarc-ietf] Rethinking DMARC for PSDs Douglas E. Foster
- Re: [dmarc-ietf] Rethinking DMARC for PSDs Dotzero
- Re: [dmarc-ietf] Rethinking DMARC for PSDs Kurt Andersen (b)
- Re: [dmarc-ietf] Rethinking DMARC for PSDs Scott Kitterman
- Re: [dmarc-ietf] Rethinking DMARC for PSDs John Levine
- Re: [dmarc-ietf] Rethinking DMARC for PSDs Douglas E. Foster
- Re: [dmarc-ietf] Rethinking DMARC for PSDs Douglas E. Foster
- Re: [dmarc-ietf] Rethinking DMARC for PSDs Scott Kitterman
- Re: [dmarc-ietf] Rethinking DMARC for PSDs Murray S. Kucherawy
- Re: [dmarc-ietf] Rethinking DMARC for PSDs Tim Wicinski
- [dmarc-ietf] More rethinking on DMARC for PSDs Alessandro Vesely