Subject: [dmarc-ietf] Domains

From: Joseph Brennan <[email-masked]>
Date: Tue, 1 Dec 2020 20:42:58 -0500

I want to ask again why DMARC should consider any domain other than
the one in the Header From. The purpose of DMARC should be stated
right at the top of the proposed standard. It is intended to control
use of a domain in the Header From. If the Header From has
[email-masked], the DMARC record for _dmarc.example.com should
apply.

It does not make sense to me to say that if the Header From is
[email-masked], and there is no _dmarc.alpha.example.com
record, then recipient systems should continue to look for
_dmarc.example.com and apply the dmarc rule there. I know of no other
standard that requires this type of relationship. This is something
new. It will require administrators to continually check what their
sub- and supra-domains are doing in order to escape interference by
DMARC records they did not create. I think this is unreasonable. Only
domains interested in applying DMARC should be involved with DMARC.
Others should be able to do what they want. I know that otherwise will
out rule out DMARC for the "columbia.edu" domain that I administer.

-- 
Joseph Brennan
Lead, Email and Systems Applications
Columbia University Information Technology

---

From: "John Levine" <[email-masked]>
Date: 1 Dec 2020 21:50:26 -0500

In article <[email-masked]> you write:
>I know of no other
>standard that requires this type of relationship.

Here at the IETF, the CAA DNS record that specifies which certificate
authority can sign for what domains does a tree walk. If there is a
CAA record at example.org it controls signing of foo.example.org and
foo.bar.example.org and so forth unless they have their own CAA record.

Every applicaton of the public suffix list implicitly does something
akin to a tree walk. Its original application was to control
cross-site web cookies, to say whether www.foo.co.uk can drop a cookie at
foo.co.uk (yes) or co.uk (no).

> This is something new. It will require administrators to continually check what their
>domains interested in applying DMARC should be involved with DMARC. ...

Well, it's not that new since we published the DMARC spec five years
ago, but this is what I have referred to as the Holy Roman Empire
problem. In organizations that are not universities, the entity that
is responsible for the registered domain generally sets policies for
the whole organization, and a good deal of the DMARC design is there
to let them figure out who is sending mail with their name on it from
any of their subdomains and identify and adjust senders whose mail
doesn't match the policy.

We realize that universities are different, organized along the lines
of the Holy Roman Empire, and the Elector of Central Asian
Cross-Disciplinary Studies feels very strongly about any incursion on
their autonomy including their mail setup.

On the other hand, I observe that Brown, Cornell, Dartmouth, U Penn,
and Yale, whose situations are not altogether unlike Columbia's, all
publish DMARC records. Closer to home so do NYU and CUNY. They all say
p=none with rua= to collect reports. You might give them a buzz to see
how it works for them.

R's,
John

---

From: Todd Herr <[email-masked]>
Date: Wed, 2 Dec 2020 11:21:57 -0500

On Tue, Dec 1, 2020 at 9:50 PM John Levine <[email-masked]> wrote:

>  In organizations that are not universities, the entity that
This is, I think, one of the most underappreciated features of DMARC. With
p=none, a proper rua= value, and enough time, one can collect all the
information needed to address any authentication shortcomings within a
designated portion of the DNS namespace before moving forward to p=reject,
assuming that that is one's goal with a DMARC implementation. Even for less
lofty goals such as ensuring that all mail is properly DKIM signed, or that
the SPF record properly enumerates all mail sources, I can't think of a
better tool than DMARC aggregate reports for ferreting out that third party
that the Marketing department hired to send mail on the company's behalf,
or locating that one mail stream emanating from the "server" sitting at the
side of Eddie the Engineer's desk.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [email-masked]
*p:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 2 Dec 2020 11:48:02 -0800

> out rule out DMARC for the "columbia.edu" domain that I administer.

If DMARC is thus constrained and you have a "p=reject" on "columbia.edu"
only, then nothing stops me from generating unauthenticated email with a
>From field indicating "foobar.columbia.edu" for any subdomain "foobar",
whether or not it actually exists in the DNS.

-MSK

---

From: Jesse Thompson <[email-masked]>
Date: Wed, 9 Dec 2020 15:32:40 -0600

> p=none with rua= to collect reports. You might give them a buzz to see

The fact that Joseph is here raising valid deployment concerns shouldn't be overshadowed by an assumption that these other universities are ahead of the game.

I participated in a hi-ed cybersecurity committee to create an "email security maturity" rubric - basically just something that CISOs can use to reflect/compare to each other.  I advocated that publishing p=none and consuming the reports is a good first step, but just maturity level 1 (of 5).  

Some university cybersecurity organizations feel like publishing p=none (and, perhaps, not actually looking at the reports) puts them into "compliance" with this DMARC thing that only their email admins really grok. 

I would hesitate to assume that seeing p=none on a domain as an indicator that they are serious about deploying DMARC and reconciling their own Holy Roman Empire conundrums; rather it's there just to not be seen as lagging behind their peers, justifying funding for more SOC staff and perhaps buying some tools (*some* of which, hopefully, may be deployed to actually solve the issues identified in the DMARC reports).

For better or worse, DHS BOD 18-01 mandated that all federal agencies publish p=reject on their domains.  Now, *that* must have forced each agency to figure out how to actually deploy DMARC and deal with the implications.  I applaud the tenacity.

On 12/2/20 10:21 AM, Todd Herr wrote:
> This is, I think, one of the most underappreciated features of DMARC. With p=none, a proper rua= value, and enough time, one can collect all the information needed to address any authentication shortcomings within a designated portion of the DNS namespace before moving forward to p=reject, assuming that that is one's goal with a DMARC implementation. Even for less lofty goals such as ensuring that all mail is properly DKIM signed, or that the SPF record properly enumerates all mail sources, I can't think of a better tool than DMARC aggregate reports for ferreting out that third party that the Marketing department hired to send mail on the company's behalf, or locating that one mail stream emanating from the "server" sitting at the side of Eddie the Engineer's desk.

I agree with all of this.  As I mentioned above, I just question the assumption that seeing p=none in a DMARC record is a good indicator that the organization is actually doing all of the things you enumerate.

It's also pretty clear from my own experience that it's impossible for complex organizations to address all of their non-compliant sources of mail flow.  Eventually, you just need to draw a line in the sand and cause the mail from random campus servers and ESPs who use domains without authorization to be rejected (or quarantined, in our case).  

On 12/2/20 1:48 PM, [email-masked] wrote:
> If DMARC is thus constrained and you have a "p=reject" on "columbia.edu" only, then nothing stops me from generating unauthenticated email with a From field indicating "foobar.columbia.edu" for any subdomain "foobar", whether or not it actually exists in the DNS.

I also advocated that sp=reject would be a sign of a high level of maturity.  I was in the minority and criticized for complicating the situation (only the flagship domain needs protection - said some).  Win some battles, lose some battles.

Regardless, I still feel like the tree walk is better than the org domain model since it would actually allow us to get to sp=reject.  With the org domain model, we'll probably be stuck at sp=none indefinitely.

Jesse

---

From: "John Levine" <[email-masked]>
Date: 9 Dec 2020 22:31:54 -0500

In article <[email-masked]> you write:
>I would hesitate to assume that seeing p=none on a domain as an indicator that they are serious about deploying DMARC and reconciling their
>own Holy Roman Empire conundrums; rather it's there just to not be seen as lagging behind their peers, justifying funding for more SOC
>staff and perhaps buying some tools (*some* of which, hopefully, may be deployed to actually solve the issues identified in the DMARC
>reports).

I figure they're collecting reports to see where their mail is going.
That's what I do. The reports are interesting even if you have no
intention of ever publishing a policy other than p=none.

>For better or worse, DHS BOD 18-01 mandated that all federal agencies publish p=reject on their domains.  Now, *that* must have forced each
>agency to figure out how to actually deploy DMARC and deal with the implications.  I applaud the tenacity.

Hahaha. It means they published SPF and DMARC p=reject records and
checked it off. I've been dealing with fairly important mail to my
users falling on the floor ever since.

R's,
John