Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jesse Thompson <[e-mail]>]

On 8/4/20 11:52 AM, Alessandro Vesely wrote:
> On 2020-08-04 6:10 p.m., Dotzero wrote:
>> On Tue, Aug 4, 2020 at 11:39 AM Jim Fenton <[e-mail]> wrote:
>>> On 8/2/20 5:43 PM, Douglas E. Foster wrote:
>>>> As to the transparency question, it should be clear that there will be
>>>> no simple solution to the ML problem.
>>>
>>> Actually, there is: If your domain has users that use mailing lists,
>>> don't publish 'reject' or 'quarantine' policies. Generally this means to
>>> just use those policies for domains used for transactional email.
>>>
>>> Unfortunately we seem to be focused on very complex technical solutions
>>> to a misdeployment problem.

I've never heard this misdeployment viewpoint in the context of M3AAWG, so that might be a good audience to validate the viewpoint that users' domains can't benefit from p=quarantine|reject.  Perhaps it should be included in a BCP?  Maybe it is, and I'm misremembering?  Granted, I've only been a member for a few years.  Maybe it was a common understanding years ago and no one talks about it anymore?

For example, when I was invited by the technical committee to present our strategy and challenges deploying DMARC for our institution, no one told me we were misdeploying.  The session was pretty well attended, and I don't think I put everyone to sleep.  Now I feel like my speech was counterproductive because I may have encouraged others to misdeploy DMARC too.


>> There is another solution. Move users to a separate domain from the domain

Long ago we put users on our org domain as a way to unify users (in a very decentralized institution) under a single domain identity, and that branding decision is not going to be undone, politically.  Any project to move users from one domain identity to another is a huge lift; it takes a lot of time, effort, and never actually completes due to stragglers with very legitimate reasons to not give up sending from their old address.  

I think that end-users would rather see their list mail be rewritten than be told to change their identity.  I know that some people on this list think that the domain in the from header isn't commonly visible anymore, but the domain is extremely important to users' sense of identity.  


>> your transactional mails are sent from. You can also put users on a
>> separate subdomain.

To the idea of clean separation:  We only encourage (without DMARC there is no way to enforce) subdomains for transactional email despite "brand minded" people insisting on using the org domain (or just using it without asking).  Despite everyone having an address in the org domain, we still have many users using legacy subdomains, and some of those subdomains are mixed-use.  

DMARC is great for getting visibility on this "separation" problem.  It's not until we moved past p=none that we could get any sticks behind our carrots.  

What I'm saying is that mixed-use domains are common and they proliferated due to the lack of domain alignment enforcement prior to DMARC.  Even when there is intention by IT to separate the use cases, they need DMARC to get both the visibility and the manageability/enforcement.

I've observed other universities using their single org domain for everything, and they don't find out they have a problem until they try to implement DMARC.  It's easier for them to move the transactional email to subdomains than to move users.  That is, unless they just give up on the idea of DMARC altogether.

This might be a stretch, but I think the "DMARC is different for user vs transactional domains argument" dovetails with the need for sp to walk the domain tree.  If the assertion is that the domain with users is fundamentally different than domains used for transactional email, and most institutions use their org domain for their users, and subdomains are a mixed bag of varying use cases, then the org domain's DMARC policy isn't the best candidate for inheritance.  


> Yet another solution would be to not use DMARC.  The status quo ante.
> 
> While p=none is a technically valid position, there seems to be a
> demand of a mail infrastructure where spoofing is not allowed.

Not only a demand, but a requirement: https://cyber.dhs.gov/bod/18-01/

I don't think DHS got the memo about misdeploying DMARC, either.  I know that around 2018, the person maintaining the MLM for our astrophysics center had to scramble to implement header munging because of all of the .gov's publishing p=reject

Jesse