Re: [dmarc-ietf] Sender vs From Addresses

[Charles Gregory <[e-mail]>]

"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
[e-mail]
[phone]

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

-----Original Message-----
From: dmarc <[e-mail]> On Behalf Of John R Levine
Sent: Thursday, March 25, 2021 2:24 PM
To: Gren Elliot <[e-mail]>; Kurt Andersen (b) <[e-mail]>; [e-mail]
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, [e-mail], Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly