On Wed 26/Apr/2023 13:21:33 +0200 Scott Kitterman wrote:
On April 26, 2023 8:08:39 AM UTC, Alessandro Vesely <[email protected]> wrote:
On Tue 25/Apr/2023 20:27:18 +0200 Scott Kitterman wrote:
My recollection is that a general formulation that I proposed had at least
some traction out of both groups:
[some appropriate description] domains MUST NOT publish restrictive DMARC
policies due to interoperability issues
Leaving aside (for now) the question of what goes into [some appropriate
description] and with the assumption that there will be some non-normative
discussion to amplify whatever that is and probably give some indication about
what domains might do to not be one of those domains, is there anyone who just
can't live with that formulation of the situation?
Me, for one. Because more than 98% of domains are going to fall into the
description, however we word it, that statement makes the whole I-D
nonsensical. Cannot we just tell the problem without MUSTard?
In any case, using the complement of [some appropriate description] is
certainly easier. For example:
Forcing authentication into Internet mail by publishing restrictive DMARC
policies breaks some well established patterns of usage. Publishing such
policies is thus RECOMMENDED only for domains [in this other appropriate
description].
Thanks.
I understand your objection to be that the proposed description of the
interoperability problems would apply to too many domains, regardless of the
modifier we might use. Is that correct?
Nearly. Too many would be 40%. 98% is practically all. Indeed, we're talking
of mailboxes used by humans...
I don't understand the technical issue associated with that objection. I get
that you feel the construction is too negative, but I don't have a sense you
think it's inaccurate. Focusing on the technical aspects of this, would you
please help me understand what you think is technically incorrect about it?
Perhaps MUST NOT would have some sense if DMARC were breaking a well known
protocol. The established patterns of usage we break are in turn breaking some
other RFCs, aren't they?
Why would the applied workaround have less merit than the original hack, from a
formal POV? I mean, if we stand by the letter of the protocols so much as to
feel the need to say MUST NOT.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
