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

[Dotzero <[e-mail]>]

On Wed, Aug 5, 2020 at 12:39 PM Jesse Thompson <jesse.thompson=
[e-mail]> wrote:

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

Not a knock on M3AAWG but many of the members are more interested in
deliverability than anti-abuse. The Sender side of M3AAWG is dominated by
ESPs rather than Brand Senders. I say this as the Founder and Chair of
Brand SIG for 10 years until I left my employer that was a member of M3AAWG.

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

You were presenting what you did. It may or may not have been
counterproductive.

>
>
> >> 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 implemented for an Enterprise with large ecommerce/social sites and 20k
seats. The only people that were allowed to keep accounts on the primary
domains were people who directly supported the websites and they were not
allowed to use those accounts for anything other than supporting the
websites. They had accounts at the other domain just as all the other users.

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

Their identity at that organization is subject to the determinations of the
organization. It is amazing how quickly after a one time transition that
users get used to  their new "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.
>

You need buy-in from senior management for any email authentication
efforts. When you add up the costs of customer support contacts for dealing
with fraudulent email claiming to be from your organization, reputation
damage, etc., management becomes more willing to buy into a comprehensive
strategy.

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

If it is only IT pushing this, you are probably doomed to failure.


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

Organizations make choices based on perceived benefits and costs.

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

The assumption was/is that the organizational domain most closely tracks
the risk for abuse and is therefore the one that most needs protection.
Therefore inheritance should be the rule rather than the exception. It also
means you don't have to walk the full tree. You only need to check the base
domain if the subdoain doesn't specify a policy.

>
>
> > 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
>
> The .gov space has an interesting and long history with regard to email
authentication. In 2011, Pat Peterson (Agari) and I were asked by EOP
(Executive Office of The President) to create and give training on email
authentication for .gov that was turned into a virtual training environment
that was available for all government employees. The specific impetus were
a series of incidents that included fake malicious White House ecards
purporting to be online Christmas cards that were sent to government
contractors and others. Required authentication for .gov domains moved
forward in fits and starts up to the point of the DHS mandate. DHS
approached the use of DMARC and authentication as a blunt one size fits all
instrument.

The reality is that the devil is always in the details.

Michael Hammer