Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

[Jesse Thompson <[e-mail]>]

On Wed, Apr 26, 2023, at 11:06 AM, John Levine wrote:
> It appears that Scott Kitterman  <[e-mail]> said:
> >>Domains owners who have users who individually request 3rd parties to emit mail as an address within the domain MUST NOT publish a
> >restrictive DMARC policy if they wish to support their users' usage of any potential 3rd party. Examples of 3rd parties include
> >mailing lists and email service providers. These 3rd parties are not always aware of, or willing to work around, DMARC. Domain owners
> >implementing DMARC as a means for governance by restricting the unauthorized usage of the domain MUST be aware that not all of the
> >3rd parties will make changes to work around DMARC, resulting in interoperability issues for their users' usage of the 3rd parties.
> >Domain owners SHOULD provide an alternative address for these users within a cousin domain or subdomain that is not directly
> >associated with the organization's brand-associated domain that is used for marketing and transactional email that needs the security
> >benefits of DMARC. These users MUST use an address within a domain that does not have a restrictive DMARC policy.
> >>
> >>(Not a troll. Not directly aware of humming (sorry, it's on my bucket list). Hopefully, didn't touch the 3rd rail. Honestly, in good
> >faith, representing the perspective of an extremely large domain owner, users within said policy-restricted domain, and as a 3rd
> >party commonly used by these, and similar, users.)
> > ...
> >I can see what you're attempting here and I see the logic.  I think the normative part would need to be about 90% shorter.
> 
> I was going to say the same thing.

I agree it is too lengthy, but wished to convey the logic.


> 
> >I think it misses the impact on innocent bystanders.
> 
> It seems to me there are two somewhat different kinds of DMARC damange
> that we might separate. One is what happens on discussion lists, where
> messages get lost and in the process unrelated recipients get
> unsubscribed. The other is simple forwarding and send-to-a-friend
> which gets lost but is less likely to cause problems for the
> recipients beyond not getting the mail they want.

I know you don't like talking about ESP concerns, but for the sake of fitting into the categorizations you state, I think that usage of ESPs falls into the send-to-a-friend category. Is there a better term than "send-to-a-friend" that is more aligned to the vast variety of use cases and types of customers that ESPs have grown to support? The term sounds a bit pejorative. Think about use cases like: digital receipts sent from point of sale systems via an ESP on behalf of small businesses who don't have the ability to delegate authorization to the entire domain (e.g. [e-mail])

And for the record, the ESP can either have unhappy customers due to rejected email, or they can do something like this (but not call it "rewriting") https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail#Replace_address_with_a_generic_one

Jesse