Re: [dmarc-ietf] Sender vs From Addresses

Charles Gregory <Charles@possumdelight.com> Thu, 25 March 2021 19:31 UTC

Return-Path: <Charles@possumdelight.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 666EC3A2AD6 for <dmarc@ietfa.amsl.com>; Thu, 25 Mar 2021 12:31:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Kia3OnW8gxIN for <dmarc@ietfa.amsl.com>; Thu, 25 Mar 2021 12:31:36 -0700 (PDT)
Received: from mail.possumdelight.com (mail.possumdelight.com [107.130.215.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 816403A2AD7 for <dmarc@ietf.org>; Thu, 25 Mar 2021 12:31:36 -0700 (PDT)
Received: from EX.possumdelight.com (fd07::1:0:0:1:4) by EX.possumdelight.com (fd07::1:0:0:1:4) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Thu, 25 Mar 2021 15:31:35 -0400
Received: from EX.possumdelight.com ([fe80::ad5d:d7f1:b37d:a89f]) by EX.possumdelight.com ([fe80::ad5d:d7f1:b37d:a89f%7]) with mapi id 15.02.0792.010; Thu, 25 Mar 2021 15:31:35 -0400
From: Charles Gregory <Charles@possumdelight.com>
To: John R Levine <johnl@taugh.com>, Gren Elliot <gelliot@mimecast.com>, "Kurt Andersen (b)" <kboth@drkurt.com>, "dmarc@ietf.org" <dmarc@ietf.org>
Thread-Topic: [dmarc-ietf] Sender vs From Addresses
Thread-Index: AQHXIN1IihmmxnZnSJC0xMH2ibjOraqT17oAgAAB3ACAAAKeAIABbRwA///F5JA=
Date: Thu, 25 Mar 2021 19:31:35 +0000
Message-ID: <07b0c7962b3e455bb341972e7fc4ca70@possumdelight.com>
References: <F1E2D8D7-9978-4C4B-9FD7-AB6428D12789@contoso.com> <20210324202058.91E777134D1B@ary.qy> <CABuGu1ovwwwwZALDOed74nBu1gOHcom8W+UDKC2GdWiEE_7yKw@mail.gmail.com> <4677E791-B028-4CAC-9752-0F4D8F1B0103@mimecast.com> <2ea2767-4940-77d1-e09e-a0ab215f9c9e@taugh.com>
In-Reply-To: <2ea2767-4940-77d1-e09e-a0ab215f9c9e@taugh.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.1.2.29]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/X2-VR3P8NK62XOg-AxOqyGVWg3w>
Subject: Re: [dmarc-ietf] Sender vs From Addresses
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: Thu, 25 Mar 2021 19:31:41 -0000

"It sounds like they're asking DMARC to do things it doesn't do. If you can't ensure that everything sent with your domain on the From line is signed with your signature, you shouldn't publish a DMARC policy."

It is a problem when receiving servers use DMARC existence and pass/fail to increase/decrease deliverability rates. - And when Yahoo/AOL pretty much block everything you send - even with a 98 sender score, SPF, DKIM, and clean opt-in lists.

"If your user's Sender and From domains belong to the same owner, it should be a SMOP to add a signature in the From domain."

Believe me, the corporate red tape of a multinational corporation is not a SMOP.

Consider how this SHOULD work with email service providers to a small business.  Emails should appear FROM CompanyA while the SENDER appears FROM MailChimp.  These are legitimately separate concerns.  Bounces go back to MailChimp for processing.  The receiver sees CompanyA in the from field.  

DMARC threw the baby out with the bathwater.  If you want to eliminate spoofing and cut down on SPAM/Phishing/Scams without crippling SMTP and all the collateral damage, a domain should have the ability to authorize other domains to send mail on their behalf.  Any "unauthorized" domains would fail DMARC. 

CompanyA specifies mailchimp.com as an authorized sending domain.  SPF verifies the sending email server IP address is authorized to send on behalf of mailchimp.com.

"I'm not saying it's trivial, but this is how DMARC works."

Going back to the beginning, DMARC breaks how SMTP worked.  The Sender address serves a purpose.  This is the address bounces should return to.  DMARC took a steamroller to the Sender address and it didn't have to.

"The rest of the world will not change the way it works to adapt to your situation rather than you fixing your setup to work with DMARC as it exists."

Maybe; but I am not alone on this.  The way DMARC disregards the Sender address has unintended consequences that negatively affected countless companies and applications - and reduces the functionality of SMTP.  I would like to think that things could be improved.  Then again, it really seems like it's time to go back to the drawing board and start over... SMTP 2.0???

Best,

Charles A. Gregory
CEO
Possumdelight Technologies
Charles@possumdelight.com
(678) 778-7200

“If it’s time sensitive, e-mail AND call.” - Charles Gregory

-----Original Message-----
From: dmarc <dmarc-bounces@ietf.org> On Behalf Of John R Levine
Sent: Thursday, March 25, 2021 2:24 PM
To: Gren Elliot <gelliot@mimecast.com>om>; Kurt Andersen (b) <kboth@drkurt.com>om>; dmarc@ietf.org
Subject: Re: [dmarc-ietf] Sender vs From Addresses

> Calconnect’s TC-CALSPAM group is currently looking at this issue and 
> yes, the reason is because of real world corporations that use 
> multiple brands with different domains.  Typically employees got a 
> single email address on one of their domains but often work with 
> people who have email addresses in different domains.

Oh, OK.

"It sounds like they're asking DMARC to do things it doesn't do. If you can't ensure that everything sent with your domain on the From line is signed with your signature, you shouldn't publish a DMARC policy."

It is a problem when receiving servers use DMARC existence and pass/fail to increase/decrease deliverability rates.

While I am not opposed to a future tweak to DMARC to add some way to say that A can sign for B, even if we did it, it would be a long time if ever that DMARC verifiers implement it.  RFC 6541 added a third-party signature option to DKIM in 2012, and after nine years, nobody implements it.

This is not the same problem as we have with mailing lists. If your user's Sender and From domains belong to the same owner, it should be a SMOP to add a signature in the From domain. I'm not saying it's trivial, but this is how DMARC works. The rest of the world will not change the way it works to adapt to your situtation rather than you fixing your setup to work with DMARC as it exists.



Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly