Re: [dmarc-ietf] Signaling MLMs

[Scott Kitterman <[e-mail]>]

On Friday, April 14, 2023 1:20:28 PM EDT Alessandro Vesely wrote:
> On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:
> > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" 
<[e-mail]> wrote:
> >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely <[e-mail]> wrote:
> >>> Heck, MLMs should start rejecting messages sent from domains that
> >>> publish a
> >>> blocking policy *when they fail authentication on entry*!!
> >> 
> >> That's not enough to avoid the damage we're talking about.
> 
> Agreed.  Yet, it is a sane half-way between crazy rejecting always and
> completely ignoring ABUSE.
> 
> >>> From: rewriting is the de-facto standard.  In DMARCbis we can only
> >>> substitute "de-facto" with "proposed".  Better methods, implying
> >>> different, possibly experimental, protocols are to be defined in
> >>> separate documents. >>
> >> 
> >> Are you suggesting we put that forward as our Proposed Standard way of
> >> dealing with this problem?  It's been my impression that this is not a
> >> solution that's been well received.
> 
> I agree there are better solutions, but they're not yet developed.  As ugly
> as it may be, From: munging is the emerged solution.  It is a _fact_.  Now
> repeat again that the IETF standardized facts, not theories...
> 
> >>> Let me recall that when I proposed something like that, I was told that
> >>> that was phase II and the WG was then already in phase III.  So, let's
> >>> complete DMARCbis /without cannibalizing the spec/ by saying that it
> >>> MUST NOT be used (as it is being used already).
> >> 
> >> What you describe as "cannibalizing" is actually a matter of presenting
> >> the
> >> correct normative advice about interoperability.
> 
> It is nonsensical.  It means DMARC is only useful for looking at the
> reports. If that's really what we think, we'd be better off deprecating p=
> completely. Otherwise, let's wait until next April 1st and publish it as
> such.  It's ridiculous.
> 
> >>  So I don't agree at all with that characterization.
> > 
> > Agreed.  If people can't get over saying some domains will have
> > interoperability problems when that's demonstrably a technically accurate
> > statement (and I don't see anyone claiming it isn't), I don't see how
> > progress is possible.
> 
> I agree that we have to say that some domains have interoperability problems
> as a consequence of DMARC.  Let's say that MLMs MUST do From: munging
> unless (or until) better solutions arise, or unless they don't alter
> messages.
> 
> We're proposing email authentication, not anything less.

Yes, but we don't get to close our eyes and pretend the rest of the world 
doesn't exist.

If we want to change this, we're going to have to update RFC 5321, which I 
think is out of our scope.  In the section on aliases and lists (3.9), it 
says:

>    However, in this case, the message header section (RFC 5322 [4]) MUST
>    be left unchanged; in particular, the "From" field of the header
>    section is unaffected.

I think it would be wrong to mandate From rewriting for a lot of reasons, but 
I don't think we get to just ignore an Internet Standard.  I think we 
particularly don't get to ignore an Internet Standard and make it through an 
IETF wide last call.

I still don't hear anyone claiming there's no interoperability problems when 
some domains publish p=reject.  Can we please just agree to document reality 
and move forward?

Scott K