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

Laura Atkins <laura@wordtothewise.com> Fri, 14 August 2020 16:35 UTC

Return-Path: <laura@wordtothewise.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 2BE793A0E00 for <dmarc@ietfa.amsl.com>; Fri, 14 Aug 2020 09:35:21 -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=wordtothewise.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 kX2cbe3n_yv1 for <dmarc@ietfa.amsl.com>; Fri, 14 Aug 2020 09:35:18 -0700 (PDT)
Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 6908F3A0D96 for <dmarc@ietf.org>; Fri, 14 Aug 2020 09:35:18 -0700 (PDT)
Received: from [192.168.0.227] (unknown [37.228.245.144]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 051CA9F1F7 for <dmarc@ietf.org>; Fri, 14 Aug 2020 09:35:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1597422917; bh=1IH+ZuxtCnX4bRzLdUf19kJ7fKFGG1VdnFY71/lP8CA=; h=From:Subject:Date:References:To:In-Reply-To:From; b=OtaO/w0prqzq6u0VoU0/zWCdkck+3NbaS4cvtHdC0HipMncTEbTMF2pChpSo7owBa iMGJjoS7O5/2wRs0GcuKwWnCLXzW2rXY0iWyKfzWuhUQuGqVyKWcgAWJ4nHj58sqME vrPp3bJtlQirPo0uVUUA34AqS3lmwPiqZ5Z86si8=
From: Laura Atkins <laura@wordtothewise.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_ED6E16BD-40F7-4CDB-8A12-624AB2B05136"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 14 Aug 2020 17:35:14 +0100
References: <CAJ4XoYfpGMUmkDkQYN0qZeNFi_xZjfR=99yVu0dgLz-z19iwfA@mail.gmail.com> <20200814020806.7D8BF1E92E0C@ary.local> <CAJ4XoYcFbh8-nAxjxzzRgUahFfhcgcZQ2yMF2ewv_-DgUmhL=g@mail.gmail.com> <3253B303-7A8B-436A-BB14-3E59FA6C96B1@wordtothewise.com> <CAJ4XoYc0nGARKvdW54hc7ERAVOr0c81_gM6rZjHh4PaMngOQ+A@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
In-Reply-To: <CAJ4XoYc0nGARKvdW54hc7ERAVOr0c81_gM6rZjHh4PaMngOQ+A@mail.gmail.com>
Message-Id: <6616567A-3C50-4366-8B31-6EB8BBA30E7D@wordtothewise.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/PGd2w4aNzF8KS7UtSHa-oULucdc>
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: Fri, 14 Aug 2020 16:35:21 -0000


> On 14 Aug 2020, at 17:18, Dotzero <dotzero@gmail.com> wrote:
> 
> 
> 
> On Fri, Aug 14, 2020 at 10:46 AM Laura Atkins <laura@wordtothewise.com <mailto:laura@wordtothewise.com>> wrote:
> 
> 
>> On 14 Aug 2020, at 09:27, Dotzero <dotzero@gmail.com <mailto:dotzero@gmail.com>> wrote:
>> 
>>  Now I have come to the conclusion that they should reject list submissions from accounts at domains which publish a DMARC policy of p=reject. Domains should not be able to externalize their internal problems to others.
> 
> This effectively cuts off users at multiple ISPs from ever participating in mailing lists. Which is exactly what we’re trying to fix with this proposal. 
> 
> Does the proposal actually fix the problem? Does the proposal actually fix the problem without creating other problems? After reading an re-reading Dave's draft, my conclusion is that the answer is no to both questions. 

And that’s why we’re having this discussion, to determine if it does or not. 

> 
> Just because a user has an address at a consumer mailbox provider that publishes p=reject does not make them a second class citizen banned from participating in any mailing list. 
> 
> You are conflating the provision of Internet connectivity  with the provision of email services. That ship sailed a long time ago. There are a number of ISPs which no longer provide email accounts/port 25 services. If a user with an account at one of those domains wanted to use their login as an email address are you suggesting that others should send responses to that "email address" even though no MX is available for that account and mail will never reach that user?

I was speaking of companies like Yahoo and AOL, companies that provide email services and not internet connectivity. They publish p=reject and any solution that is ‘well, they just don’t get to use mailing lists” seems to create a problem. At one point, gmail announced they will be publishing p=reject, which meant users of 2 of the 3 major consumer mailbox providers would be prohibited from joining mailing lists. 

> It is clear to me that a domain owner/admin has the right to determine how that domain will or will not be used. The individual is not banned from ever participating in a mailing list. They simply can't use an account from that particular domain. There are plenty of other places they can get an email account from. They also have the opportunity to tell their existing provider they are unhappy with policy. Providers can and do change their policies. For the longest time, the address block associated with Amazon Simple Mail Service was a swamp of badness. Legitimate users and organizations started deciding to not use other Amazon AWS services as a result of their mail being blocked. Amazon got religion and started cleaning up their mess. So yes, even large players can respond to market and community pressures.
> 
> I'm not the person who initially suggested MLMs reject users/email from domains that publish p=reject. That was John Levine. Perhaps he was being sarcastic, perhaps not. It is certainly a forcing mechanism. And that may just be what is needed for domains to think carefully about how they implement DMARC.

That is not how the quoting came through on my client. I was attempting to be succinct and trim the message. Here’s the full email I was responding to. In my client you appear to be the one saying MLMs should reject anyone using a domain with p=reject. If the quoting was incorrect, I apologize for the mistake. 

> On 14 Aug 2020, at 09:27, Dotzero <dotzero@gmail.com> wrote:
> 
> 
> 
> On Thu, Aug 13, 2020 at 10:08 PM John Levine <johnl@taugh..com <mailto:johnl@taugh.com>> wrote:
> In article <CAJ4XoYfpGMUmkDkQYN0qZeNFi_xZjfR=99yVu0dgLz-z19iwfA@mail.gmail.com <mailto:99yVu0dgLz-z19iwfA@mail.gmail.com>> you write:
> >> "DISCUSS" shouldn't really be a joke. draft-crocker-dmarc-sender suffers
> >from a similar problem as PRA in the SenderId draft. There is no way to
> >validate that the specific intermediary is authorized by the (From) domain
> >originating the email through it's generic signalling that it
> >authorizes intermediaries. This means that any source can emit a message
> >claiming to be a legitimate intermediary just as any source could game PR
> >to gain a neutral result.
> 
> That's a feature, not a bug. I want recipients to be able to assess
> the mail my lists send on its own merits.
> 
> And recipient domains do just that using local policy override. DMARC policy is at best a request to the Validator/Receiving Domain. If a Validator/Receiving Domain chooses to honor the published DMARC policy for a domain such as p=reject, then they are in fact assessing the mail your lists send based on the merits as they see them. The same goes if they decide to not honor that published DMARC policy and accept mail from your lists. Earlier in my DMARC journey I felt that MLMs should adjust and send list mail as themselves. Now I have come to the conclusion that they should reject list submissions from accounts at domains which publish a DMARC policy of p=reject. Domains should not be able to externalize their internal problems to others.
> 
> >One could achieve similar outcomes using
> >only reputation and local policy override of DMARC policy.
> 
> Only if you believe that the domain on the From: line is automatically
> more credible than the one on the Sender: line. The whole third party
> problem is that the people sending their mail through lists or
> whatever are in fact doing so legitimately, but for various reasons
> their organizations' DMARC policies lie and say they aren't.
> 
> I think you are misusing the term "credible". Domains which are publishing p=reject policies are making an assertion regarding mail purporting to be authorized by their domain. It is not an assertion that their mail is "good" or should be delivered to a recipient or even given preferential treatment with regard to filters or policy. The assertion is simply that mail purporting to be authorized by my domain must pass either SPF or DKIM validation or else we request that in the event of neither of these properly validating for a particular email message, please reject this message. Don't think of it as being about "legitimate" or "not legitimate". There is a certain (normally small) amount of mail that fails to validate even when it passes directly from the outbound MTA to the recipient domain's MTA. The sending domain is accepting that this otherwise valid mail may (SHOULD?) be rejected by the receiving domain. The organizations DMARC policies aren't lying. They are simply saying "If this then that."
> 
> This ultimately goes back to the elephant in the room. Does an individual user's use of an account at a domain trump the organization's right to define how an account at a domain may/should be used? I absolutely agree that in an ideal world this issue should not be externalized yet here we are. This is why I made the point above that lists should respect DMARC policy and not accept submissions from domains with DMARC p=reject policies. It becomes "Not your circus and not your monkey". and forces the problem back to the domain and it's users. If an MLM isn't modifying the message then the DKIM signature should survive and this discussion is irrelevant. I think this covers the range of MLM use cases that have been a topic of discussion. If the MLM admin really wants to poke those domains publishing p=reject then they can respond to user subscribe attempts or submissions that are rejected with an explanation that they need to go have a meaningful discussion with their mail admin/IT staff/domain account provider or whoever is responsible for publishing p=reject for tht domain but still allowing users to sign up for MLMs or attempt to use other intermediaries. popcorn is of course optional.
> 
> Michael Hammer
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

laura 


-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
laura@wordtothewise.com
(650) 437-0741		

Email Delivery Blog: https://wordtothewise.com/blog