Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

[Alessandro Vesely <[e-mail]>]

On Thu 27/Apr/2023 22:49:31 +0200 Scott Kitterman wrote:
> On April 27, 2023 4:02:32 PM UTC, Alessandro Vesely <[e-mail]> wrote:
>>On Wed 26/Apr/2023 13:21:33 +0200 Scott Kitterman wrote:
>>> On April 26, 2023 8:08:39 AM UTC, Alessandro Vesely <[e-mail]> 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
--