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 <skl...@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 <z...@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 >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
