On Thu 27/Apr/2023 22:49:31 +0200 Scott Kitterman wrote:
On April 27, 2023 4:02:32 PM UTC, Alessandro Vesely <[email protected]> wrote:
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.
If we think internet standards are meaningful, then if the applied work around
directly conflicts with an internet standard (which From rewriting does: RFC
5321 and predecessors), then it he as substantially less merit.
My recollection is that mailing lists were never standardized. They arose as a
local-scoped alternative to Usenet, piggybacked on SMTP, following methods and
traditions derived from common sense and convenience. The onset of From:
rewriting is the latest step in their evolution, which testifies for their
flexibility.
From a user's perspective, From: rewriting in no way an improvement.
Semantically, it poses the questions of authorship and identity of individuals
with respect to the community. To the extent that DMARC marks a turning point
in the email landscape, From: rewriting can be considered like sparks flying
from the tire rim if the curve is too sharp. It'll settle eventually.
Otherwise, we can try to stick to tradition and condemn DMARC, refusing to
acknowledge the need for human authentication that seems to emerge. Why? To
honor a tradition? To respect a standard that was never issued?
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
