On Sat 15/Apr/2023 18:10:08 +0200 Scott Kitterman 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.
That's right. Yet, that's what everyone does hitting «forward» on a MUA. Such
action is indeed exemplified as what a mediator does not do in RFC 5598, near
the beginning of Section 5. We're slightly changing Internet mail architecture.
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
