Subject: Re: [dmarc-ietf] Sender vs From Addresses

From: Gren Elliot <[email-masked]>
Date: Wed, 24 Mar 2021 18:41:20 +0000

Hi,

For better or worse, there is long established practice in the Calendaring community when implementing iMIP (rfc6047) when an assistant is working on behalf of a manager for the manager’s email address to populate the “From:” header and the assistant’s email address to populate the “Sender:” header.  Mailing software seems to go to lengths to follow this convention even when it doesn’t do so for other email messages “sent on behalf of”.  I assume this means that things will break somewhere if this convention isn’t followed for at least some peoples calendaring software.

So, it looks like at the moment people will need to make a choice between enforcing DMARC and having calendaring software continue to function.

Surely it is possible to offer different levels of DMARC enforcement where there is a level that forces using the “From:” header and a newer level which follows the existing email standards for validating who the author is – i.e. use “Sender:” if present, else use “From:”?

Alternatively, we really ought to update the Email RFCs to deprecate the “Sender:” header.  Otherwise you effectively have canonical standards from the same standards body which flatly contradict each other.

Software and standards layered on top of email like iMIP would also need similar updates.  .  I’m not actually recommending this – whilst we might design things differently now, the existing practice with “From:” and “Sender:” makes sense to me and the level of complexity with dealing with this seems trivial compared to other things we need to deal with.

Regards,
Gren

---

From: "John Levine" <[email-masked]>
Date: 24 Mar 2021 16:20:58 -0400

It appears that Gren Elliot  <[email-masked]> said:
>For better or worse, there is long established practice in the Calendaring community when implementing iMIP (rfc6047) when an
>assistant is working on behalf of a manager for the manager’s email address to populate the “From:” header and the
>assistant’s email address to populate the “Sender:” header.  Mailing software seems to go to lengths to follow this
>convention even when it doesn’t do so for other email messages “sent on behalf of”.  I assume this means that things will
>break somewhere if this convention isn’t followed for at least some peoples calendaring software.
>

DMARC only looks at the domain part of the From header.  How often do the manager and assistant have e-mail addresses that
are not in the same domain?

>Surely it is possible to offer different levels of DMARC enforcement where there is a level that forces using the “From:”
>header and a newer level which follows the existing email standards for validating who the author is – i.e. use “Sender:” if
>present, else use “From:”?

I talk to people at large mail providers a lot, and I do not recall
this partiticular situation coming up as a problem, ever.  Do you have concrete
experience to the contrary?

The problem with keying DMARC to the sender is that if you believe that people look at the From
header, it turns DMARC into filtering based on the reputation of the DKIM or SPF identity.  Mail
providers already knew how to do that before DMARC existed.  Noting what Dave said, I'm not sure
how closely people look at the From header, but I do know that other than desktop Outlook, MUAs do not show
the sender at all.  Gmail and web Outlook don't.

R's,
John

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 24 Mar 2021 13:27:38 -0700

On Wed, Mar 24, 2021 at 1:21 PM John Levine <[email-masked]> wrote:

> >For better or worse, there is long established practice in the
> Calendaring community when implementing iMIP (rfc6047) when an
> >assistant is working on behalf of a manager for the manager’s email
> address to populate the “From:” header and the
> >assistant’s email address to populate the “Sender:” header.
>
> DMARC only looks at the domain part of the From header.  How often do the
> manager and assistant have e-mail addresses that

John,

This goes back to your Roman Empire scenario. It's not necessarily common,
but it isn't unheard of for domain mismatches especially in the case of
acquisitions or other corporate structuring changes.

--Kurt

---

From: Gren Elliot <[email-masked]>
Date: Wed, 24 Mar 2021 20:37:00 +0000

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.

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wednesday, 24 March 2021 at 20:27
To: John Levine <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Gren Elliot <[email-masked]>
Subject: Re: [dmarc-ietf] Sender vs From Addresses

On Wed, Mar 24, 2021 at 1:21 PM John Levine <[email-masked]<mailto:[email-masked]>> wrote:

John,

This goes back to your Roman Empire scenario. It's not necessarily common, but it isn't unheard of for domain mismatches especially in the case of acquisitions or other corporate structuring changes.

--Kurt

---

From: "John R Levine" <[email-masked]>
Date: 25 Mar 2021 14:23:46 -0400

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

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, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Charles Gregory <[email-masked]>
Date: Thu, 25 Mar 2021 19:31:35 +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
[email-masked]
(678) 778-7200

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

-----Original Message-----
From: dmarc <[email-masked]> On Behalf Of John R Levine
Sent: Thursday, March 25, 2021 2:24 PM
To: Gren Elliot <[email-masked]>; Kurt Andersen (b) <[email-masked]>; [email-masked]
Subject: Re: [dmarc-ietf] Sender vs From Addresses

> 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, [email-masked], Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly

---

From: "John R Levine" <[email-masked]>
Date: 25 Mar 2021 16:35:57 -0400

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

Are they rejecting on DMARC failure because you're publishing p=reject? 
If so, they're doing exactly what you're asking them to do.  If you don't 
want them to reject your mail, why are you telling them to do that?

I realize that getting large organizations to act coherently is close to 
impossible, but that doesn't mean the rest of the world has to work around 
their failures.  If it's not important to them to make their DMARC records 
match their actual practices, it's not important to anyone else, either.

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

Yes, we all know DMARC's problems.  I complained as loudly as anyone when 
AOL and Yahoo abused it to push the costs of their security failures onto 
everyone else.

But the people who designed it knew a lot about the way that mail works, 
they they did what they did.  Prior attempts to key on sender were a 
complete failure.  I hope you have read RFC 4407.  You don't have to like 
the way that DMARC ignores Sender, but it's not an accident, and telling 
people they are stupid is not going to change any minds.

Regards,

---

From: Charles Gregory <[email-masked]>
Date: Thu, 25 Mar 2021 21:39:11 +0000

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

>Are they rejecting on DMARC failure because you're publishing p=reject? 

NO p=none

>If so, they're doing exactly what you're asking them to do.  If you don't want them to reject your mail, why are you telling them to do that?

>I realize that getting large organizations to act coherently is close to impossible, but that doesn't mean the rest of the world has to work around their failures.  If it's not important to them to make their DMARC records match their actual practices, it's not important to >anyone else, either.

>Yes, we all know DMARC's problems.  I complained as loudly as anyone when AOL and Yahoo abused it to push the costs of their security failures onto everyone else.

>But the people who designed it knew a lot about the way that mail works, they they did what they did.  Prior attempts to key on sender were a complete failure.  I hope you have read RFC 4407.  You don't have to like the way that DMARC ignores Sender, but it's not an >accident, and telling people they are stupid is not going to change any minds.

I don't remember saying anything like that John.  I doubt anyone in this thread has a low IQ.  In fact, I am very thankful for this discussion and everyone who is taking part.  I am learning things from each of you outside of my general scope of operation.

I DO think this is an unnecessary problem that CAN be fixed/improved in one of two fairly straightforward manners through DNS (behavior switch or list authorized alternate domains).  And I can't see anything but upside in doing so; nobody has demonstrated a downside anyways.  Yet I have no idea how such decisions are made or the part that anyone plays here.  I will review RFC 4407.  Thanks.

Best,

Charles Gregory

---

From: "John R Levine" <[email-masked]>
Date: 25 Mar 2021 17:53:25 -0400

>> Are they rejecting on DMARC failure because you're publishing p=reject?

I know people at Yahoo, and their filtering is largely based on complaint 
statistics.  If they're blocking your mail, the recipients are marking a 
lot of it as junk.  What do you see in the feedback reports?

> I DO think this is an unnecessary problem that CAN be fixed/improved in 
> one of two fairly straightforward manners through DNS (behavior switch 
> or list authorized alternate domains).  And I can't see anything but 
> upside in doing so; nobody has demonstrated a downside anyways.

I explained the downside to Sender a few messages back: it lets people put 
any address they want in the From line so it becomes just a filter on the 
reputation of the DKIM or SPF domain.  If that were adequate, they 
wouldn't have invented DMARC.

I agree that there is no particular downside to something like ATPS, but 
the fact that we've had ATPS for a decade and nobody has implemented it 
tells me that this is not a problem that the industry thinks is worth 
solving.

Regards,

---

From: Charles Gregory <[email-masked]>
Date: Thu, 25 Mar 2021 22:00:45 +0000

" I explained the downside to Sender a few messages back: it lets people put any address they want in the From line so it becomes just a filter on the reputation of the DKIM or SPF domain.  If that were adequate, they wouldn't have invented DMARC."

Not using the 'authorization of specific domains through DNS' solution which is clearly the more thorough of the two I mentioned.

Charles A. Gregory
CEO

"If it's time sensitive, e-mail AND call." - Charles Gregory

-----Original Message-----
From: John R Levine <[email-masked]> 
Sent: Thursday, March 25, 2021 5:53 PM
To: Charles Gregory <[email-masked]>; Gren Elliot <[email-masked]>; [email-masked]
Subject: RE: [dmarc-ietf] Sender vs From Addresses

>> Are they rejecting on DMARC failure because you're publishing p=reject?

I know people at Yahoo, and their filtering is largely based on complaint statistics.  If they're blocking your mail, the recipients are marking a lot of it as junk.  What do you see in the feedback reports?

> I DO think this is an unnecessary problem that CAN be fixed/improved 
> in one of two fairly straightforward manners through DNS (behavior 
> switch or list authorized alternate domains).  And I can't see 
> anything but upside in doing so; nobody has demonstrated a downside anyways.

I explained the downside to Sender a few messages back: it lets people put any address they want in the From line so it becomes just a filter on the reputation of the DKIM or SPF domain.  If that were adequate, they wouldn't have invented DMARC.

I agree that there is no particular downside to something like ATPS, but the fact that we've had ATPS for a decade and nobody has implemented it tells me that this is not a problem that the industry thinks is worth solving.

Regards,

---

From: Hector Santos <[email-masked]>
Date: Thu, 25 Mar 2021 18:26:07 -0400

> option to DKIM in 2012, and after nine years, nobody implements it. 

Wildcat! SMTP implements RFC6541 "Authorized Third Party Signature" 
(ATPS)/ I'm sure I am not the only one and/or others have the options 
to enable it.

There are wizard for ADSP+ATPS and DMARC+ATPS:

https://secure.winserver.com/public/wcADSP
https://secure.winserver.com/public/wcDMARC

It works in proving the assertion by a 1st party Author Domain 
authorization for the existence of a specific 3rd party signer domain 
signature. Results are stamped in "Authorization-Results" header.

Add "atps=1" to your DMARC record and create a ATPS record to 
authorize 3rd party signature domains.

These domains are authorized to resign mail for the domain isdg.net

jchjykxmwknbyfge2bg4td6add264olh._atps TXT   ( "v=atps01; 
d=winserver.com;" )
kjshf2duqstols65zbhuytbbyr3zdecf._atps TXT   ( "v=atps01; d=gmail.com;" )
lykm653kj7yxeia665va7lszzthcx7jj._atps TXT   ( "v=atps01; 
d=beta.winserver.com;" )
pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT   ( "v=atps01; d=ietf.org;" )
tudfisabn5dz3vjm2kxcehc5attdbqh6._atps TXT   ( "v=atps01; 
d=santronics.com;" )

It can be managed like any other system.

This allows receivers to support a MAILING LIST that has resigned mail 
- the key problem we had since ADSP and now since DMARC because DMARC 
never bothered to even address the main concern with ADSP - the lack 
of a method to authorized a 3rd party.

ATPS offers it.

As to why the IETF.ORG mailing list does not support it or explore it 
and has chosen instead to rewrite, I don't know, but its so simple --- 
a DNS Lookup without any 5322.From tampering.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

---

From: Dotzero <[email-masked]>
Date: Thu, 25 Mar 2021 23:39:13 -0400

On Thu, Mar 25, 2021 at 5:53 PM John R Levine <[email-masked]> wrote:

> It's real simple. Delegate a subdomain or provide a signing key to a 3rd
> party. In my previous incarnation we managed 6,000+ domains and both
> Ironport and Message Systems allowed us to DKIM sign on the fly for any of
> the our own domains at our border MTAs. Earlier on we were able to do the
> same with a little more effort with well known open source mail servers. If
> service providers aren't willing or able to work with either delegated
> subdomains or delegated DKIM keys, shame on them. That is a business
> problem on their part, not an interoperability problem. I am slightly more
> sympathetic in the case of mailing lists which is a different problem space.
>

This was the problem with  *Sender ID* and PRA. Back in the day I used to
taunt the folks at Microsoft (Craig and Harry) by sending them email with
their own From address by leveraging the Sender address and PRA to
game a  *Sender
ID* neutral. It frustrated the hell out of them. As has been pointed out
many times, there is no way of determining if Sender domain has any
relationship to From domain unless it is in the same administrative domain.

> +1

Michael Hammer

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 26 Mar 2021 19:04:58 +0100

On Thu 25/Mar/2021 20:31:35 +0100 Charles Gregory wrote:
> 
> 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.

Do they trust MailChimp?  If they do, let MailChimp create a DKIM key and sign 
the messages they send on behalf of CompanyA as:

    DKIM-Signature: v=1; d=CompanyA; s=MailChimp; ...

To publish the public key that MailChimp will hand out as said selector is 
CompanyA's act of faith.  Indeed, the effect is not much different than 
authorizing specific domains through DNS.

Best
Ale
--

---

From: "Jim Fenton" <[email-masked]>
Date: Sat, 27 Mar 2021 14:03:06 -0700

On 25 Mar 2021, at 11:23, John R Levine wrote:

>> Calconnect’s TC-CALSPAM group is currently looking at this issue 
>> and yes, the reason is because of real world corporations that use 

Agreed, but in some cases, such as US Government agencies, the 
publication of a p=reject policy is required:

https://cyber.dhs.gov/bod/18-01/

Unfortunate IMO that they created this requirement based on an 
informational RFC.

-Jim

---

From: "John R Levine" <[email-masked]>
Date: 27 Mar 2021 18:00:18 -0400

On Sat, 27 Mar 2021, Jim Fenton wrote:
> Agreed, but in some cases, such as US Government agencies, the publication of 
> a p=reject policy is required:
>
> Unfortunate IMO that they created this requirement based on an informational RFC.

The government agencies have a different problem -- they do it on the 
cheap with SPF only, so mail falls on the floor if it's forwarded.  I 
handle the mail for my local town government, most of which is forwarded 
to their gmail accounts, and they were losing a lot of important mail from 
the US Census.

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 29 Mar 2021 21:52:47 -0700

On Thu, Mar 25, 2021 at 2:39 PM Charles Gregory <[email-masked]>
wrote:

> one of two fairly straightforward manners through DNS (behavior switch or
> list authorized alternate domains).  And I can't see anything but upside in
> doing so; nobody has demonstrated a downside anyways.  Yet I have no idea
> how such decisions are made or the part that anyone plays here.  I will
> review RFC 4407.  Thanks.
>

Even if ATPS had taken off, there's a matter of scale: Very large mailbox
providers like Gmail, Yahoo, etc., would need to find some way to populate
such a list.  They could let their users do it (though getting users to do
more work to manage their accounts is certain to be an uphill battle with a
lot of configuration detritus as collateral), or they could try to automate
it (a non-trivial and probably open-ended engineering investment).  Neither
path is appealing.

-MSK