Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

"Douglas E. Foster" <fosterd@bayviewphysicians.com> Sat, 15 August 2020 22:33 UTC

Return-Path: <btv1==4963bfbccc3==fosterd@bayviewphysicians.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 16C5B3A0A12 for <dmarc@ietfa.amsl.com>; Sat, 15 Aug 2020 15:33:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.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 d9R6NTbeaU9F for <dmarc@ietfa.amsl.com>; Sat, 15 Aug 2020 15:33:49 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80FF3A0A06 for <dmarc@ietf.org>; Sat, 15 Aug 2020 15:33:49 -0700 (PDT)
X-ASG-Debug-ID: 1597530827-11fa3136ba105f0001-K2EkT1
Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id eOrcQRn7wcbGhTgA (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for <dmarc@ietf.org>; Sat, 15 Aug 2020 18:33:47 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=hZxEvWO592FB0J7n4/hbpu+APSXp52fQf877pz1mEGU=; b=X2jadYDjadKGjy01uc+8lGOnZCzPjwPq9P6/lX1yjgNJ8XGcuTmQw/v3zQhYMN8Em p0OIV7thBA6nnnPYXTg40h0K+l8o9Mac4ceCdOccNMPmpUNQJWhZmh+v7/6km7T2T nqcZeZinK3vxmYSiN39rsD/G0TYzIwKbH3NLZxX9E=
From: "Douglas E. Foster" <fosterd@bayviewphysicians.com>
To: "dmarc@ietf.org" <dmarc@ietf.org>
Date: Sat, 15 Aug 2020 22:33:38 +0000
X-ASG-Orig-Subj: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
Reply-To: fosterd@bayviewphysicians.com
Message-ID: <6755d0cef49e465bbf2bd170dbdc6aa3@bayviewphysicians.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="8d84e93a93cd4fe9a5b1282c48016ab4"
In-Reply-To: <CAL0qLwaVUi9QtV4zcCwncuy4N3YPwsGZPzFfd1q19io79UG2VQ@mail.gmail.com>
References: <CAJ4XoYcFbh8-nAxjxzzRgUahFfhcgcZQ2yMF2ewv_-DgUmhL=g@mail.gmail.com> <20200814164237.313071E971DB@ary.local> <CAJ4XoYeqj_5mpZu1PZP4rNfrWRyC5gC-2dfK7oX9xQHiR24QeA@mail.gmail.com> <085c6a5f-5451-ae8c-4873-133673ba1754@tana.it> <CAL0qLwaVUi9QtV4zcCwncuy4N3YPwsGZPzFfd1q19io79UG2VQ@mail.gmail.com>
X-Exim-Id: 6755d0cef49e465bbf2bd170dbdc6aa3
X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1597530827
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 22949
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83922 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/TjovofL4DWiSL1FiAFf9iDH5y_M>
Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
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: Sat, 15 Aug 2020 22:33:52 -0000


Based on the discussions here, it appears that the notion of From address validation was envisioned from the beginning Sender Authentication discussions.    We have written evidence that Form address validation was anticipated in the DKIM and ATPS RFCs prior to DMARC.    So we have more than a decade of warnings that From address validation was coming.   While not everybody has time to read every RFC, the Mailing List trade press must have should have been reporting on it as something to watch.

Even after DMARC was in use, it appears that nobody in the mailing list community felt inconvenienced until the AOL/Yahoo hack and their decision to implement DMARC with p=reject.   This was the moment of Unhappy Surprise.    Bad guys had obtained many valid email addresses, so one of the concerns was how to prevent them from spoofing those users to send spam.   They could not use those address in the SMTP address because of SPF, but only DMARC could prevent those addresses from being misused in the Message From address.     It was the obvious thing to do and it would have been reckless for them to do otherwise.   Can you at least admit that the mailing list community was surprised because they failed to prepare for this contingency?   

But that moment is now in the rear view mirror.    Mailing lists can get delivery to all subscribers by confirming to the requirements of the DMARC-participating domains, by using their own domain in the From address, at least for those domains.    I assume that there are still mailing list operation that are not unable to comply with DMARC-participant expectations, because they have failed to upgrade.   But an individual organization’s failure to adapt is not a problem worthy of a standards body.   I liked XP just fine and hated Vista, like Windows7 OK but hated Windows 8.   But Microsoft killed support for XP and Windows 7 and my organization is adapting.    Life is unfair.  COVID-19 is unfair and has caused a lot of problems.   Every organization has problems, and we all have jobs so that we can help solve them.    The time to cry in your beer is over.  Mailing lists have a interoperability solution, and they should use it whether they like it or not, because that is what is necessary to get their mail delivered according to the requirements of the recipient organization.    As a result, mailing list operators really have no standing in this discussion, although they can certainly speak as unhappy individual users and on behalf of their unhappy users.  

Consequently, the real problem before us becomes the existence of users who are unhappy because the From address on some mail does not meet their preferences.    I have to ask why that is a problem worthy of a standards body?     I have about 8 different scenarios in my head where a user might be have unmet expectations with the format of the From address, or might experience mailing list deliverability problems because of the email filtering policy of its domain relative to the addressing practices of his mailing list.   If our requirement is to make every user happy, shall we head down the path of all 8 problems, not just this one?

This project was supposed to discuss moving DMARC from informational to standards track.   It has been hijacked by those who, to paraphrase Shakespeare, “have not come to praise DMARC, but to bury it.”   This has been abetted by the chair’s assertion that we must square a circle – meet the MLs requirement for them to impersonate without authorization while continuing to advance the DMARC requirement to prohibit impersonation without authorization.

As part of that hijacking, we have been inundated by Mr. Crocker’s assertions that the message From Address does not matter.  All the years of theoretical analysis that preceded DMARC and all of the operational success from implementations of DMARC are just wrong, simply because he says so.   Worse yet, he asserts without justification that the message From address should be unimportant to everybody except mailing list subscribers, for the simple reason that the Message From is so very important to his Mailing List subscribers.   It is comparable to asserting that the earth is flat, for everyone except astronauts.    This is sheer nonsense.

More importantly, this discussion has failed to address the actual objective, which is to solve the asserted Mailing List problem as it relates to AOL/Yahoo/Verizon.   That enterprise does not seem to be involved in this process, and no one has offered reason why they will be swayed by anything said here.    The strategy seems to be that if we tell these people how stupid they are, that they will do whatever we tell them they must do, even if the solution is to weaken security for everyone on the Internet.    That is not a winning strategy.

DMARC has been mandated by at least three national governments,, by a variety of businesses, and by this one consumer-oriented email hosting service.   It is here to stay, and any extensions to the specification will need to improve security, not weaken it for the benefit of a special interest group.

Instead, we should be anticipating that the U.S. government will begin mandating DMARC for its contractors, in phases based on contractor categories.    Simply requiring it for Department of Defense contractors would be sufficient to include most of the major research-oriented universities.   But every school that takes student loan payments is also considered a government contractor, which covers almost all of them.    Every branch of state and local government also feeds from the federal trough, and concerns about election meddling means that they are likely targets for voluntary or required implementation of DMARC.   Essentially every health care institution is also a government contractor, because they take payments from Medicare or Medicaid, usually both.

It is time to begin a discussion rooted in what is feasible, and what is appropriate for IETF to undertake.

 

----------------------------------------
From: "Murray S. Kucherawy" <superuser@gmail.com>
Sent: 8/15/20 5:02 AM
To: Alessandro Vesely <vesely@tana.it>
Cc: IETF DMARC WG <dmarc@ietf.org>, John Levine <johnl@taugh.com>, Dotzero <dotzero@gmail.com>
Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
Emphatically hatless:

On Sat, Aug 15, 2020 at 12:47 AM Alessandro Vesely <vesely@tana.it> wrote:
>> Lists have been around a lot longer than DMARC has.

That doesn't grant lists any extra right.  Others consider current
global usage as a priority gauge.

This line of thinking has bothered me for a long time.

Imagine you're a large soft drink manufacturer.  Your delicious, popular product is sold in grocery stores the world over, sometimes directly from your production line, sometimes via a local reseller.  Your sales team does one or the other depending on the use case.  Business has been good for a generation or two.  One day you decide you don't like resellers anymore because some of them mis-promote your product, so you somehow arrange that the cans in the stores that passed through resellers suddenly and randomly begin invalidating themselves by bursting, making a mess of the store and soaking customers.  Other products nearby are also ruined.  This reflects poorly on the resellers, some of whom are forced to stop doing business with you.  Stores get angry and are forced to reconsider doing business with you as well, but you're big and popular and so many of them have to deal with your mess on an ongoing basis.  Many customers take their business elsewhere; the stores suffer.

The argument here appears to be that is that this is justified, because the ecosystem of manufacturers, grocery stores, resellers, and customers that has existed for as long as you can remember has no right to operate that way if you suddenly decide you don't want it to; it's your brand, and your word about your brand is final irrespective of how you choose to enforce it.  You're suddenly, for reasons you feel are legitimate, asserting that the ecosystem was broken to begin with despite the fact that you've been a willing participant for decades, and therefore you are at liberty to disrupt it (though, admittedly, you may have been unaware of the blast radius of doing so).

Now, you may be right that the ecosystem was built on the incorrect premise that domain names don't need to be treated as sacrosanct.  (Let's ignore for the moment the stuff about hindsight.)  But that assertion clearly differs from the well-established foundation upon which a great deal rests today.  It is far from trivial to change that now.  It's possible to do, to be sure, but dropping it into the world overnight has a hugely disruptive impact.  Such a change needs to be an evolution, with the cooperation and collaboration of a preponderance of the participants, not a philosophical light switch you get to throw and expect everyone else to conform.

I don't want any more soda on me.

Why people's mailboxes must be spoofable?

I don't know about "must", but changing the fundamental assumption that it's acceptable in some cases for X to pretend to be Y (which is what MLMs do), at X's discretion, is a tectonic change that should have been rolled out with more community collaboration and grace than it was.  I think we need to be more considerate of that fact if there is to be progress.

Syllogism goes like so:  Mailing list must not accept strict DMARC
policies, humans may happen to use mailing lists, therefore email
domains which hosts mailboxes used by humans must not publish strict
DMARC policies.  Is that really what we seek?  I hope not.

It is our current reality, and in my humble opinion, we've nobody to blame but ourselves.

-MSK, participating.