Re: [dmarc-ietf] Signaling MLMs

The solution to move forward is:

- Recommend MUST NOT publish if domain wants to allow users to use domain in public list systems,

- Warn MLS/MLS  to avoid From Rewrite and recommend to honor p=reject by rejecting subscription, submissions. This is already in practice since 2011.

- Update section 4.4.3 to assist domains with a desire to use p=reject to consider supporting extended technologies to help with public usage of p=reject.

- Add a section for marketers of DMARC security systems to assist in correcting this problem with less aggressive campaigns to be prepare mail hosting customers with p=reject policies before they’re ready to do so. Always start with p=none.

- Make DMARCbis Informational status for faster IETF adoption  As a proposed standard, it’s going to be a rough poison pill too shallow after ADSP was abandoned for the same problems.  The difference now is this MUST NOT publish and honor for DMARCbis.  This may be enough to get IETF endorsement for a proposed standard.  

—
HLS

> On Apr 14, 2023, at 1:58 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 <mailto:dmarc@ietf.org>
> https://www.ietf.org/mailman/listinfo/dmarc