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

Dotzero <dotzero@gmail.com> Mon, 17 April 2023 13:01 UTC

Return-Path: <dotzero@gmail.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 934E2C15155F for <dmarc@ietfa.amsl.com>; Mon, 17 Apr 2023 06:01:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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=pass (2048-bit key) header.d=gmail.com
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 5zl7ScqToUEK for <dmarc@ietfa.amsl.com>; Mon, 17 Apr 2023 06:01:41 -0700 (PDT)
Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 AB2E0C15153D for <dmarc@ietf.org>; Mon, 17 Apr 2023 06:01:41 -0700 (PDT)
Received: by mail-vs1-xe2d.google.com with SMTP id l16so2978440vst.2 for <dmarc@ietf.org>; Mon, 17 Apr 2023 06:01:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681736500; x=1684328500; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fLV1Rt3GhXxFRIKwkUJ/x0oF6cdFt1nzfIlttN7OPy4=; b=VzWeBZRgZKubUpuHa91oSWslcwveEdnA7ZlEkfkXxpYm5shnuegWdq2QIvKY9O0C/i NukTj5Dq8n+GX0P+D1/cWwKYu3S51szAKhgXx6eer4LMhi0/oEW5m6NrGl4b9Bp56J1x JjVThZlgqXSRnMT/zKWVrLUAwz0/kPuQHLEH+rcu5+2zq1P1tz86goI1eICCWzxLoeHq EwjR7+XRaVHna5SdRfNTRer6vQXIN++XGYJUhWHLzFc9k2Tyk0jdTEG8tMH85FMd4Cxe +vcL+2h5eBuG44kgHanW8CTXr8rgIHqdCOwlVMM8ETLWLNvV3PI6iyl7t82tZ6lgjipP 9+LQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681736500; x=1684328500; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fLV1Rt3GhXxFRIKwkUJ/x0oF6cdFt1nzfIlttN7OPy4=; b=l0Sjm8Ckpt5uDhB9PXuS1mzNXUFODWgQlxp9/9tM2KzJvd5ECmhwNJbzfDRKe0RY2s bJZNL+MQz1RbSAuB564EmWITuir4MNE6nRnS4kMyhqbcS3q1SnR0ZSO9mEX9HMUPsNnB vRpPwF3AO4GnkXPCBbNvKQaVR04qWTrKf3dSLfXsE3EJSKuWDwP+R2ZmjSxr5CDGO+gW Rlgo2K2ZuKgM5Z6pmsJgMy1jD6mtNzIpzBMeGLqkF7CwsBjY5fFiz2QRNzPoTio2XGHg OBajgObnsvLxR7Hakmi/vvPVELr+HClaPeS6dOi8zIGr23ymLYLn9vpRxt/MOpVyLIX+ joLQ==
X-Gm-Message-State: AAQBX9ewk0NgroCiPpY91JkXrxBavM+LMgo0MOeibR7CTp1ApHmQZXI6 /k4Ll5OT704OGTF89h3o+mqTTguKD1tRrF+DVe15Eavt
X-Google-Smtp-Source: AKy350YLoYZkhjhvOXHmBugUzkR2SZRVWDKrmFYYbNmZfSNRlq+iGzIVC7AHxdKtgktNWRfqKi8hBHGAP0sO8AjSg40=
X-Received: by 2002:a67:e1cd:0:b0:42e:5599:7021 with SMTP id p13-20020a67e1cd000000b0042e55997021mr3917792vsl.5.1681736500348; Mon, 17 Apr 2023 06:01:40 -0700 (PDT)
MIME-Version: 1.0
References: <4FD1C711-7A7D-40E5-88DE-95CDD248F92B@wordtothewise.com>
In-Reply-To: <4FD1C711-7A7D-40E5-88DE-95CDD248F92B@wordtothewise.com>
From: Dotzero <dotzero@gmail.com>
Date: Mon, 17 Apr 2023 09:01:30 -0400
Message-ID: <CAJ4XoYfQtuavs28FwNrsbD5hBGxnTyVo=E334wJ1QZ-ATfihYg@mail.gmail.com>
To: Laura Atkins <laura@wordtothewise.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b58c7705f987ca67"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/8cKzXg3N2JeC50ZMiyD-s0VZfBc>
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:01:45 -0000

On Mon, Apr 17, 2023 at 4:30 AM Laura Atkins <laura@wordtothewise.com>
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?
>

Let's throw the baby out with the bath water. There are ways a
(transactional) domain owner can enable a vendor to generate/send email on
their behalf without the vendor "spoofing" the domain. A subdomain can be
delegated, private DKIM signing keys can be provided. Another approach is
routing outbound email from the vendor through the customer's mail
servers.  In addition, dedicated sending IPs can be required by the
customer. My personal favorite is delegating a subdomain because all of the
obligations can easily be specified contractually. In the past when
potential vendors have said "we don't do that" or "we can't do that" and
I've said "then we can't consider you in our vendor election process", it's
amazing how quickly they figure out how to do things if there is enough
money on the table. I speak from experience.

If enough people insist then vendors will productize these approaches into
their offerings more generally. It's a competitive differentiator until
enough vendors have offerings, at which time it will become the ante to
play in the game. So no, suggesting that the only solution is vendors
rejecting business from customers who publish p=reject is pretty much a
non-starter.


>
> 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.
>

I could see a discussion in a BCP as to why it's a bad practice. I don't
see it having a place in a standard.

Michael Hammer