On April 26, 2023 9:39:08 PM UTC, Jesse Thompson <z...@fastmail.com> wrote:
>On Wed, Apr 26, 2023, at 11:06 AM, John Levine wrote:
>> It appears that Scott Kitterman <skl...@kitterman.com> 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. local-flower-s...@yahoo.com)
>
>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
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
