Subject: Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 3 Dec 2019 12:22:28 -0800

On Mon, Nov 11, 2019 at 7:54 AM John Levine <[email-masked]> wrote:

> In article <CAL0qLwbo1AtJ6LG1UuSSoBC-GwjdQsc5CA2h6q5VqMxH=
> [email-masked]> you write:
> >Just to be clear: The policy for changes to that registry is "Expert
> >Review", but since the action that put it there was a document with IETF
> >consensus, I'm pretty hesitant about just approving this change based on a
> >formal request.  I'd rather at least see some consensus discussion about
> >it, or even better, a revision/update to RFC8601.
>
> Hey, wait, Expert Review is supposed to be considerably looser than RFC
> Required.
>

Sure is.

Since there's no danger of running out of token names, I'd encourage
> you to accept new ptypes if they have a clear spec and a plausible use
> case.  In this instance, I think the description in the I-D is OK, but
> for the use case I would like some evidence that someone, somewhere is
> implementing it and doing something with the result.
>

As far as I know we're talking about "dnswl" which is a method, not a
ptype.  There is one known implementation (CourierMTA, I believe) which is
the impetus for the registration.  I think the name is constrained to
whitelists even though DNS-published lists might have the opposite meaning,
so I wish there had been some discussion before there was an
implementation.  But unless someone wants to argue a risk of actual harm
from that, I don't see any reason not to approve it given its very limited
deployment so far.

Assuming the ptype we're talking about is "dns" which is defined in the
same document, the definition is terse and there's not much guidance for
the designated expert about what things should be allowed with respect to
future registrations.  I think Scott basically said the same thing.  I'd
like to see those points addressed before green lighting it.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 3 Dec 2019 16:21:47 -0500

> On Mon, Nov 11, 2019 at 7:54 AM John Levine <[email-masked]> wrote:

Nice to know I'm not the only one who lets my mail marinate for a while.

> like to see those points addressed before green lighting it.

Seems reasonable.  Ale should be able to spin up a new one.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 04 Dec 2019 02:13:48 -0500

> Seems reasonable.  Ale should be able to spin up a new one.

I'd prefer to see the new dns ptype separated from the dnswl discussion.  I 
can see broad utility in the dns ptype (for example, if you want to indicate 
that a domain is testing DKIM, I think we need dns because that's where you 
find the information - it's not an attribute of the signature).

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 4 Dec 2019 11:38:13 +0100

On Tue 03/Dec/2019 21:22:28 +0100 Murray S. Kucherawy wrote:
> As far as I know we're talking about "dnswl" which is a method, not a ptype. 
> There is one known implementation (CourierMTA, I believe) which is the impetus
> for the registration.  I think the name is constrained to whitelists even
> though DNS-published lists might have the opposite meaning, so I wish there had
> been some discussion before there was an implementation.

Started in 2010, resumed in 2013, the discussion about how to implement whitelisting in Courier-MTA was mainly concerned on configuration syntax.  It is archived here:
https://sourceforge.net/p/courier/mailman/courier-users/thread/4CA0879B.9020707%40tana.it/

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 4 Dec 2019 11:38:38 +0100

> find the information - it's not an attribute of the signature).

Ptypes are already shared.  Define once, use freely.  (Except that each method
has to define which properties it uses, and hence which ptypes.)

IMHO, a simplification step, whenever someone is going to address rfc8601bis,
would be to factor the results as well.  For example, every method carefully
specifies pass, fail, temperror and permerror to have the same, agreed
semantics.  The IANA page nicely allows to sort the table by code, a bemusing
experience.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 13 Dec 2019 10:31:17 +0100

On Tue 03/Dec/2019 21:22:28 +0100 Murray S. Kucherawy wrote:
> Assuming the ptype we're talking about is "dns" which is defined in the same
> document, the definition is terse and there's not much guidance for the
> designated expert about what things should be allowed with respect to future
> registrations.  I think Scott basically said the same thing.  I'd like to see
> those points addressed before green lighting it. 

The doc just says "The property being reported belongs to the Domain Name
System".  I think that definition broadly includes any tag found in a domain's
TXT record.  For example, we could agree that within a resinfo of a given
method, any dns ptype refers to tags in the relevant record or retrieval
thereof, unless otherwise specified.  So one could have, say:

Authentication-Results: example.com;
  spf=pass smtp.mailfrom=example.net dns.sec=y;
  dkim=pass header.i=@example.org header.b=jIvx30NG dns.s=tlsrpt

The point is where would such kind of convention be made explicit.  I don't see
what additional text can be added to the dnswl I-D in order to make that issue
clearer.  Any proposal?

Best
Ale
--