Re: [dmarc-ietf] Signaling MLMs

RFC 5321 restrictions on forwarding cease to be applicable when the message
is modified.   Once the MLM changes the message, the ML domain owns it,
which is why the MLM-created message SHOULD use the ML domain on the new
message.

Additionally:
- The recipient may not trust the author domain, for any number of
reasons.   This is overcome when the ML domain takes responsibility for the
message.
- The list visual appearance is easily impersonated, so the list members
can be deceived without the fake message transiting the list at all.   This
is also overcome if list messages use a From in the list domain and protect
it with DMARC.

There is no alchemy that will cause an evaluator to trust the list until
the list takes responsibility for the message by using its own domain in
the From address.

On other active topics:

   - The strategy of providing a p=none domain is not likely to be
   embraced.   Assume that "example.com" uses "p=reject", but "
   insecure.example.com" uses "p=none".    Any system admin will understand
   that the organization remains at risk as long as "insecure.example.com"
   is allowed to operate on the corporate backbone.

   - The strategy of rejecting subscriptions from "p=reject" domains has
   not been embraced, and I doubt it will be in the future.   Rejecting
   subscriptions requires disclosures that serve to embarrass the list:.   "Im
   sorry, your subscription cannot be accepted because your domain protects
   your email identity from impersonation, which obstructs our ability to add
   our highly-valued subject tags and footer information to every message.
   Please resubscribe using a domain that allows us to modify your messages
   and allows spammers to use your identity to mislead your family, friends,
   church, employer, community group, medical providers, and municipal
   government."   I don't think lists will ever be willing to do full
   disclosure.

DF

On Sat, Apr 15, 2023 at 12:10 PM Scott Kitterman <sklist@kitterman.com>
wrote:

> On Saturday, April 15, 2023 11:45:34 AM EDT Alessandro Vesely wrote:
> > On Sat 15/Apr/2023 16:42:32 +0200 Scott Kitterman wrote:
> > > On April 15, 2023 1:55:59 PM UTC, Jesse Thompson <zjt@fastmail.com>
> wrote:
> > >>And the "If a mailing list would like to provide the best customer
> > >>experience...MUST rewrite" suggestion seems like a reasonable way out
> of
> > >>this "interoperability vs reality" standoff.  How about if I soften it
> up
> > >>further:
> > >>
> > >>"Any sender (mailing list, forwarder, ESP, or otherwise) which is
> tasked
> > >>to send unauthenticated email from an address within a
> > >>p=reject|quarantine domain it MUST refuse to send the message or send
> the
> > >>message using an RFC5322.from address in a different domain.">>
> > > That kind of customer experience guidance isn't what goes in an IETF
> > > protocol specification with normative language.  There can, and
> probably
> > > should be, some discussion about that in an appendix, but without the
> > > MUSTard.
> > >
> > > As I recently mentioned in another thread, the From rewriting trick is
> > > explicitly contrary to MUST NOT language in RFC 5321 on mailing lists.
> > > We should quit pretending it's in scope as a component of DMARCbis and
> > > move on.
> > I hope they amend that passage.  There are several shortcomings in that
> > section.  By the same argument, MLMs shouldn't add List-* header field
> > either.
>
> Perhaps, but I don't think the fact that when RFC 2321 was updated, they
> didn't make explicit provisions for RFC 2919 and perhaps should have,
> gives us
> any wiggle room around the fact that From is the one field in the header
> that
> is specifically called out as not being changed.
>
> Scott K
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>