Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

Scott Kitterman <sklist@kitterman.com> Mon, 17 April 2023 13:43 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 A52CAC151B04 for <dmarc@ietfa.amsl.com>; Mon, 17 Apr 2023 06:43:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.397
X-Spam-Level:
X-Spam-Status: No, score=-4.397 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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="ien1tUff"; dkim=pass (2048-bit key) header.d=kitterman.com header.b="BAAQoNEN"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbwUnqNnfQT4 for <dmarc@ietfa.amsl.com>; Mon, 17 Apr 2023 06:43:29 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56CDDC151B02 for <dmarc@ietf.org>; Mon, 17 Apr 2023 06:43:29 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id 02654F802F7 for <dmarc@ietf.org>; Mon, 17 Apr 2023 09:43:19 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1681738984; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=KqWRo+GsYAN99HyCnUB4J4tkyxmGBiT6cuuI71HdME0=; b=ien1tUffRWlgs/JyAMOwI24KSRTFqMhsE5X0uL88qq4oYGNwltH25dNy33N0oDqAvOJOb rQ9wiK9SWarBWW3Cg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1681738984; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=KqWRo+GsYAN99HyCnUB4J4tkyxmGBiT6cuuI71HdME0=; b=BAAQoNENXnmTgsoFPwQkJXp5Hl4qrzHp7y8kWPs6svhxuMVVkr9F2eplhLONQSu0Qq2Kd bMe1vNlwS7ipizQpXrt5no6VIdWB3kdoW56q/MEvoJ+JdWjfGi1hVOaNq2SFrPyFIhozptV 7kWXGI7N79Qxq9UNEDcsRN71J3EetBk7W0S4FfqZdQVk9dmH2tdNvJFoDin8ZgFG5Z0LcC2 R2UGxHoOzcxzcN0IH2zQuxMb+KX+RzuuPcw/RlGATxKN69TQ7iRCU9KywK5nq3K2jg26CoT ULkhStWsrdsdvjJE3V/ZRcO8y0aVl8SfrAfMAG73wHCvh+MwPogIwD7x5r7Q==
Received: from localhost.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id 24C63F80110 for <dmarc@ietf.org>; Mon, 17 Apr 2023 09:43:04 -0400 (EDT)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Mon, 17 Apr 2023 09:43:00 -0400
Message-ID: <3412961.LncKL8lBis@localhost>
In-Reply-To: <1937153A-4731-408B-92DA-3E459789651C@wordtothewise.com>
References: <4FD1C711-7A7D-40E5-88DE-95CDD248F92B@wordtothewise.com> <4091078.A07lAYmWBP@localhost> <1937153A-4731-408B-92DA-3E459789651C@wordtothewise.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/lPjJQOF9wKwsoUahicHjM065Z80>
Subject: Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 17 Apr 2023 13:43:33 -0000

On Monday, April 17, 2023 9:37:55 AM EDT Laura Atkins wrote:
> > On 17 Apr 2023, at 14:15, Scott Kitterman <sklist@kitterman.com> wrote:
> > 
> > On Monday, April 17, 2023 4:29:45 AM EDT Laura Atkins wrote:
> >> Reading through the various discussions about how to document the harm
> >> DMARC causes for general purpose domains, I started thinking.One way
> >> that a lot of major SaaS providers have chose to deal with DMARC is
> >> spoofing their customer’s in the 5322.from Comment string. There are
> >> numerous examples of this: Paypal, Docusign, Sage, Intuit are 4 big
> >> examples I can think of off the top of my head.
> >> 
> >> All of these companies send out financial or business mail on behalf of
> >> their customers, some of whom do use p=reject on their own domains. Some
> >> of
> >> them also use restrictive DMARC policies for this mail, others don’t.
> >> 
> >> Is this another issue we should document and make recommendations about?
> >> I
> >> was thinking along the line that transactional SaaS providers should
> >> fully
> >> support DMARC and should not allow companies using p=reject in their
> >> business mail to access the service?
> >> 
> >> I keep going back and forth that this is not an interoperability issue -
> >> the mail works fine even when the business is spoofed in the 5322.from
> >> comment string. But on a practical level it looks exactly like phishing
> >> mail because it’s financial (or contractual) docs from a particular
> >> company coming from a random domain. I keep ending up this isn’t an
> >> interoperability issue, it’s just an end run around DMARC and it’s not
> >> the
> >> IETF’s place to comment on that.
> >> 
> >> But I thought I’d bring the discussion up here to see if other folks had
> >> different opinions.
> > 
> > Many mailing lists do the same as part of their DMARC From re-writing
> > work-
> > around.
> > 
> > I think it's out of scope for DMARC.  DMARC is wired to 5322.from and not
> > the Comment string.
> 
> I apparently didn’t clearly express myself as both you and Michael
> misunderstood what I was saying.
> 
> Should the IETF make the interoperability recommendation that SaaS providers
> who send mail on behalf of companies support aligned authentication? That
> means custom SPF domains and custom DKIM signatures.
> 
> And if they can’t, then do we make a different recommendation regarding
> spoofed mail that evades a company’s DMARC policy?
> > The thing is, it's a comment string, so on what basis is any particular
> > comment good or bad?  That's a complicated question and I think we have
> > enough to do without trying to tackle this too.
> 
> I honestly wasn’t trying to bring up that discussion. I was more focused on
> ensuring SaaS companies can support DMARC. Many of them, even in the
> financial space, don’t currently do so.

OK.  The discussion of the 5322.From comment through me off, I guess.

I think there's probably room for the IETF to document Bext Current Practices 
(BCP) around DMARC usage.  I think it's a step beyond the interoperability 
discussion we need for the DMARCbis protocol document.  Assuming we think we 
know enough, we might consider that for additional WG scope after we have 
(essentially) completed the currently chartered work.

Scott K