Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Douglas Foster <[e-mail]>]

Any form of security creates inconvenience.

Based on the header rewriting done by IETF, I have a hard time seeing how
its rewrite of Comcast addresses can cause any of the problems that you
cite.

But does your domain require even headers toi be rewritten?    Why doesn't
IETF ask you, and omit rewrite if that is what your domain wants?

It is hard for me to cry over mailing lists when they cannot ensure that a
post comes from the asserted poster and they cannot adapt their DMARC
defenses to the preferences of the recipient domains.   Life is hard.   It
only gets harder if I wait for someone else to solve problems that I can
solve myself.

Doug Foster










On Wed, Apr 12, 2023 at 6:23 AM Laura Atkins <[e-mail]>
wrote:

>
>
> On 12 Apr 2023, at 10:45, Alessandro Vesely <[e-mail]> wrote:
>
> On Sun 09/Apr/2023 09:50:46 +0200 Murray S. Kucherawy wrote:
>
> Mike Hammer asks, reasonably, whether an IETF standard containing a "MUST
> NOT" that we know people will ignore calls into question the IETFs
> relevance or legitimacy.  But I submit that the IETF issuing a standards
> track document which fails to take the strongest possible stance against
> deploying DMARC in a way that knowingly imposes substantial breakage, for
> any reason, is irresponsible and is the greater threat to our legitimacy.
> Keep in mind that improper deployment of DMARC results in damage to
> innocent third parties: It's not the sender or the MLM that's impacted,
> it's everyone else on the list.  It's breathtaking to me that we can feel
> comfortable shrugging this off under the banner of "security" or "brand
> protection".
>
>
>
> It is not clear whether the damage is caused by those who publish p=reject
> rather than by those who honor it.  For the protocol to work, both are
> needed.
>
> History ratified that mailing lists are the refractory element.  At the
> time, John compiled a list of possible DMARC workarounds[*].  Out of
> inertia, From: rewriting emerged as the de-facto standard.  It works.  It's
> amendable, though; there are cooperative solutions for example.  And ARC.
>
> Rather than considering how to better the coordination between senders and
> receivers, we disregard the mailing lists adaptation as undue.  Thus we're
> stuck at crossroads.  DMARC breaks mailing lists.  SPF breaks forwarding.
>
> For a possible way forward, senders can coordinate with receivers by
> identifying mail streams, pivoting on users who subscribe to mailing lists
> or require forwarding for email address portability.  Just like the
> classic, one-sided whitelisting of specific email addresses, but using
> email authentication.
>
> Can we stop longing for the 1980s?  Let's accept the damaged we caused.
> It's been mended already.
>
>
> I would disagree that the mailing list adaptation (header rewriting) works
> well and is benign. In fact, it causes problems for list participants. From
> my own experience:
>
>  It makes it difficult to implement filters based on poster address.
>
> It makes it difficult to search for posts by certain authors.
>
> It makes it difficult to respond to someone privately or to reach out to
> them for non-list related reasons.
>
> It can even make it difficult to identify who is speaking as some folks
> don’t sign their messages and they don’t provide .sig files to identify
> them.
>
> laura
>
> --
> The Delivery Experts
>
> Laura Atkins
> Word to the Wise
> [e-mail]
>
> Email Delivery Blog: http://wordtothewise.com/blog
>
>
>
>
>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>