Re: [dmarc-ietf] Signaling MLMs

Interoperability problems occur because MLMs believe they are exempt from
the security problems that lesser mortals face.

I am not obligated to deliver every message that arrives for my users.  If
DMARC causes an evaluator to block a message that his user wants, they have
a  customer service problem, not an interoperability problem.   The
protocol correctly provided information which the evaluator used as he saw
fit.

The Sender or MLM may be unhappy if lost eyes mean lost revenue, but an
evaluator is tasked with disappointing senders, many times per day.

Document the issue as a customer service problem and I am on board.

Doug

On Fri, Apr 14, 2023, 1:59 PM Scott Kitterman <sklist@kitterman.com> wrote:

> 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"
> <superuser@gmail.com> wrote:
> > >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely <vesely@tana.it>
> 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
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>