Subject: [dmarc-ietf] DMARC marketing
From: Jim Fenton <[email-masked]>
To: [email-masked]
Date: Wed, 22 Jul 2020 15:55:06 -0700
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>

This:

On 7/21/20 12:29 PM, Joseph Brennan wrote:
>
> My understanding of DMARC's purpose was to protect transactional
> messages from sources like banks, credit card issuers, online shopping
> venues, and the like. It supposed that those messages should pass only
> directly from the source to the end point, and that that was so
> important to security that transport through any intermediary should
> be rejected as possible forgery. For example my bank statements come
> from a different domain than mail from a person at the bank.

and:

On 7/21/20 1:17 AM, Laura Atkins wrote:
> But I would argue that much of the marketing and justification around
> DMARC has been around end users and improving their trust in brands
> and protecting them from phishing. 
> [...]
>
> That is not how I’ve seen DMARC being sold. Most of the marketing I’ve
> seen about DMARC is all about user experience and the user being able
> to trust mail is “from who it claims to be from.” And now people are
> explicitly layering on another protocol that is all about what the
> user sees in the MUA.

and also:

On 7/20/20 5:31 AM, Dotzero wrote:
> You have left out one significant way of convincing receiver domains
> and their admins. We used to have our CSRs (customer service) tell
> people who received spoof emails (resulting in phishing, malware
> compromise, etc.) from emails claiming to be from our domains that
> they should contact their mail provider or email admin because the
> problem could have been avoided if DMARC were being checked. We would
> even provide them with the details and a form with all the information
> in non-technical terms. It is amazing how quickly a provider pays
> attention when their customers/users are complaining to them that the
> provider could have prevented the heartache and grief but chose not
> to. Again, this was for domains sending transactional mail with only a
> limited number (intentionally) of role and support accounts.

These get to the heart of the problem: DMARC policy was designed for
official mail that is about business transactions. If that was the way
it is actually used, we wouldn't be having this problem. But it was
oversold, and it is being used in use cases (like on domains that have
mailing list users) that were not intended. I'm not convinced that this
is a problem that has a satisfactory technical solution.

-Jim