On Wed, Apr 26, 2023, at 5:47 PM, Scott Kitterman wrote:
> 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.
That assumes every mailing list authenticates its rfc5322.from authors and that
every send-to-a-friend-er does not authenticate its rfc5322.from authors. This
list does not. The send-to-a-friend-er I work for does. Maybe we don't want to
trust the method the send-to-a-friend-er uses to authenticate its authors, and
give a pass to the mailing list's method at the same time, but none of it
matters since there's no way a mail receiving organization can determine if the
message originated in an authorized context in either situation.
To be clear, I am not laying down on the tracks on the MUST NOT issue. Consider
me "humming".
Yes, I'd prefer something less pejorative than "send to a friend". I'd prefer
if any non-SPF/DKIM-authorized mail-emitting entity running into DMARC policies
could find a nugget of advice in the spec. I'd prefer some of the other ideas I
have constructively suggested in previous messages (granted, address-level
authentication is wishful thinking and maybe that discussion needs a different
forum). In the end, I will need to give this "how to mitigate" advice directly
and I will need to explain why every domain owner is adopting DMARC for reasons
other than the IETF is willing to condone. Having something to point to in the
spec other than this "MUST NOT" would make that message a lot easier to convey,
but doesn't change the fact that I will need to convey it.
Jesse
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
