Re: [dmarc-ietf] Overall last-call comments on DMARC

Murray, I was hoping your proposal to advance ARC was serious.

Google has solved the problem of limited ARC deployment.  To my mind, this
means that we cannot revoke the experiment and we cannot do much to change
it, so we might as well advance it to standards track.  It became a
de-facto standard on February 1.

When an evaluator wants to accept Special Sender traffic, he needs two
pieces of information:

   1. How to detect that the message might qualify as a Special Sender
   2. How to authenticate the Special Sender to differentiate that source
   from malicious actors.

As my proposed text should have indicated, the evaluator has a huge
obstacle when the Special Sender's Mail From address has been lost due to
secondary forwarding.
ARC fixes that problem rather well, while facilitating the entire process.

To Ale's concerns, I think a registration process would help mailing lists,
but there are many options, and we do not need to define one single
solution.   Most of the mailbox providers already have a registration
process for bulk senders, with a feedback loop for problem situations.  I
see plenty of opportunity for them to build on that.

On the other hand, I don't see our current document having much impact
toward better message disposition; it simply does not break enough new
ground.  So I see no need to rush to completion.  However, I can envision
how the benefit from having ARC integrated into our text.  I don't think we
have satisfied our charter without it.  I see every reason to proceed with
ARC first.

Doug Foster

On Thu, Apr 4, 2024 at 12:14 PM Murray S. Kucherawy <superuser@gmail.com>
wrote:

> On Thu, Apr 4, 2024 at 8:50 AM Alessandro Vesely <vesely@tana.it> wrote:
>
>> > I know what "contract" means abstractly, but what does this actually
>> look
>> > like to someone that's looking for specific guidance?  The text you
>> have
>> > here, by itself, is vague and I don't think many operators will know
>> what
>> > to do with it.
>>
>> A file in each user's home directory listing allowed pairs of ARC's d=
>> domain
>> and the list-id identifier of a List-Id: field?
>
>
> I'm a Gmail user.  What's a "home directory"?
>
>
>> Whatever.  What do Google use
>> to determine if an ARC seal is trusted?
>>
>> We don't have much concrete experience on how to set up a contract,
>> though.
>>
>
> This is what I'm worried about.  We're in WGLC for the base document, so
> this discussion is in that context.  But is WGLC really a good time and
> place to be introducing abstract ideas about how this might or might not
> work?  Aren't we looking to create something fairly complete and concrete
> in a Proposed Standard?
>
> >> Meanwhile, we can mention ARC, in Section 5.8  (minimal text proposed
>> in
>> >> another thread[*]).  How much can we expand that?  For example, can we
>> >> whisper something about the need to trust specific sealers for
>> specific
>> >> streams?
>> >
>> > If you really need ARC to make all of this work and interoperate with
>> > lists, then I think we need to start talking about how we want to move
>> ARC
>> > out of "Experimental" first so it can become a normative reference.
>>
>> Back to timing here.  DMARCbis I-Ds seem to be mature enough to go out,
>> even if
>> there are not yet a practical solutions to the ML problem.  Further
>> delaying
>> them until we find one is inadvisable.
>>
>
> Then why are we tossing about all these ideas during WGLC, muddying the
> waters?
>
>
>> Yes, we need ARC, but we also need a method to convey agreements based on
>> it.
>> We couldn't spell out a solution even if ARC were standard track already.
>>
>
>> We can just hint at it.  Parts of the Doug's text sound good for that.
>> Here's
>> a variation on it, mixed with the 2nd paragraph of Section 5.8:
>>
>> [...]
>>
>
> So if I can summarize, I believe you're saying:
>
> Here's a Proposed Standard.  In some common deployment scenarios, we know
> that it has some undesirable side effects.  There isn't any concrete way to
> fix that as part of the PS.  You could do some X, which is this new-ish
> experimental thing, or you could do some Y, or maybe both, and Z might
> help, "whatever", but only one of those is well-defined, and none of them
> are part of this PS nor are they published yet, and there's a non-zero
> chance that we'll run out of energy and not actually do so.
>
> Is that what you want to send to the IESG?
>
> -MSK
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>