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

[Jesse Thompson <[e-mail]>]

On 8/7/20 2:12 PM, John Levine wrote:
> In article <[e-mail]> you write:
>> I feel like what is happening sometimes is that central university IT is trying to drag their whole institutions into a
>> more secure posture before anybody in a position to stop them fully understands what's going on lest they be told to
>> stop because it might make things a little inconvenient.
> 
> I was with you up until that sentence, since it trivializes the real
> problems that overly strict DMARC policies cause.

Maybe Autumn was reflecting the reality that the industry has already trivialized DMARC problems for these "misdeployments".  

 
> Just yesterday I was sorting out a problem with people trying to
> finish editing a revised IETF standard about real-time web
> applications. Some of the authors' messages were disappearing,
> apparently at random. I saw what the problem was, one of the authors
> is at a big company whose IT department insists on p=reject (and has
> blown off complaints from fairly senior people about the problems it
> causes), the other uses an MIT alumni address that recently moved its
> hosting to Microsoft without telling anyone that the new host enforces
> DMARC policy while the old one didn't.
> 
> My guess is that MIT figured Microsoft will host this for free, that's
> great, totally unaware that some of its users' mail would silently
> break.

Customers of Microsoft don't like to call things bundled in an expensive package "free".

My peeve in recent years is that universities were essentially coerced (economically) into being the customers of Microsoft/Google and then the email admins are told to sit down and let the adults talk about what they think customers need from DMARC, ARC, etc.  It's why I'm constantly sticking my foot in my mouth here and M3AAWG; trying to assert a voice.

We need faculty/alumni/emeriti forwarding to work without being told that Microsoft can't do it without breaking DMARC.

We need spoofing protection for all of our domains without being told we're misdeploying.

We know that we need advanced local policy controls for DMARC enforcement and we don't want to be blamed when the vendor doesn't give us those controls (to your MIT example) 


> I told them as a workaround they needed to directly cc each other when
> they send anything to the group list, but the whole thing is a
> self-inflicted wound.

Maybe it was inflicted by the domain owner onto the person maintaining the mailing list.  (In my experience, this is where people realize that no one has been maintaining/patching the mailing list, unaware of DMARC, etc.)

Again, I think MLM header munging is here to stay, and list recipients needs to get used to it (I'd like p=quarantine pct=0 be the default behavior so that domains choosing to misdeploy DMARC aren't second class).  

I'd like to see a way to un-munge mail from trusted intermediaries, but that sounds impractical.  

I think ARC has promise but it has some challenges that I hope can be overcome; notably a mechanism for the receiver to indicate trust to the intermediary (so that it knows it doesn't need to munge).

At that point, I can start to figure out how to deal with the mailbox-level forwarded mail for faculty/alumni/emeriti...

Jesse