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

[Scott Kitterman <[e-mail]>]

On April 26, 2023 9:39:08 PM UTC, Jesse Thompson <[e-mail]> wrote:
>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
>

I don't think the categorization is specific to ESPs.

Broadly, I think the failure modes are:

1.  Starts authorized, breaks in transit (e.g. mailing lists)

2.  Starts as unauthorized 3rd party and stays that way (e.g. send to a friend)

I don't think there is anything ESP specific in the failure modes.

Scott K