Re: [dmarc-ietf] New authentication method, DNSWL

[Alessandro Vesely <[e-mail]>]

On Thu 01/Aug/2019 07:27:10 +0200 Murray S. Kucherawy wrote:

> On Wed, Jul 31, 2019 at 9:40 PM Scott Kitterman <[e-mail]>
> wrote:
> 
>> Can we discuss this choice?  I know this has been implemented already, so 
>> I'm at least slightly reluctant to do the semi-standard lets rename
>> existing stuff dance that the IETF often does, but I really don't like
>> this.  There isn't an email authentication system out there that doesn't
>> rely on DNS.  I think DNS as a ptype is way too broad.

Policy is even broader.  What's wrong in being broad?  Registering this ptype
does not preclude future methods from using it as well.

In fact, even if all email authentication systems rely on DNS, none of the
properties registered thus far derive from there.  Existing ptypes, body,
header, smtp and policy, report data found in their respective areas, none of
which is the DNS.


>> Also, if I rsync a copy of the list and process it locally, is it still
>> OK to use the dns ptype when there is no DNS involved?


I do rsync a copy, and then serve it via rbldnsd (actually through a bind
forward-only zone).  MTAs will run a query using the DNS protocol anyway.
Courier is smart enough to query an internal zone and report its public name.


>> What about something like extpolicy: The property reported relates to an
>> external policy input?


Hm...


>> Would you be willing to do something like that?  If so, I think we could 
>> also register dns, but with status of decprecated since it's in use and 
>> documenting in use stuff is good.  Then Courier can change at some point
>> when it's convenient, but still be using a registered paramet.>>
> 
> <designated expert hat on>
> 
> Thanks for commenting on this.  I'm overdue to provide a review and
> feedback.
> 
> I rejected this application prior to RFC8601 primarily because the language
> used then to restrict what goes in the registry didn't allow for
> registrations of stuff that wasn't actually part of the message, and a DNS
> whitelist or blacklist result is not (nor for example is the client IP
> address, or the result of any query entirely external to the message body,
> header, or even envelope).  The good news is that the language of RFC8601
> is more relaxed, in particular in Section 2.3 it allows for a
> property/ptype that covers "some other aspect of the message's handling",
> so that's no longer a blocking factor.
> 
> To counter Scott's point, "dns" is a ptype that would exist within the
> method of "dnswl", so I think it's hard to see how it could be
> misinterpreted.  But I'd like to see how this discussion plays out.  I can
> see his point about "dns" being a rather broad ptype.
> 
> Appendix C of RFC8601 goes to some length to discourage the practice of
> including all the details that were inputs to the evaluation, specifically
> because the result of the evaluation at the border MTA is the only thing
> that should matter.  I thus have some trouble understanding why "policy.ip"
> and "policy.txt" are desirable things to include.


Let me narrate a use case.  Courier-MTA can be configured to reject on SPF -all
early in the SMTP dialogue, except if whitelisted.  It writes SPF as well as
dnswl results in the header, but does not interpret the policy.ip.  Downstream
filters can interpret the field based on the dns.zone.  I use that feature to
pass messages tagged "Heuristic" by the antivirus filter if policy.ip has a
positive trustworthiness.

As a matter of fact, Courier stopped to query "ANY" some months ago.  That way,
I miss policy.txt.  Its use was not automated, however.  A few times I happened
to manually retrieve it after delivery.  If I had a domain-based reputation
system available, I could use the domain name in policy.txt to make automated
delivery decisions.


> Related:
> 
> Section 3 of the draft appears to be commentary about what should go in TXT
> records, or how things querying DNSxLs should query and interpret TXT
> results.  This doesn't seem to be appropriate for a document about
> Authentication-Results; it's implementation guidance for MTAs or receiving
> agents.


Yes, the last paragraph is guidance about querying ANY.  It could go to an
appendix or be stroked, if we want to go through another revision.

The first paragraph is about how dnswl's may work.  Rfc5782 just says "DNSWLs
MAY have a TXT record that describes the reason for the entry."  I agree it is
slightly out of scope for registering the parameters.  OTOH, I'd like to know
more dnswl's in order to inform better on TXT record usage.


> And even if that were not true, I'm concerned that "policy.ip" could be
> interpreted as an IP address even though that's manifestly not what this
> is.

That's the reason why I wanted to call "dns.zone" the other property, which
could also be expressed as an IP address.


> Nevertheless, Scott's point about documenting current use is well taken and
> I like his idea in principle.  The only concern I have is that allowing
> this directly into a "deprecated" status still reserves the name "dns"
> should anyone later devise a use for it that's appropriate in breadth.  I
> suspect though we could just ask IANA to register both, one deprecated and
> one current, should that somehow ever come to pass.


Well, DNS is so broad that it's natural to expect that such ptype be used to
report more properties.  However, the way the registry is now structured, it is
only possible to deprecate the dns.zone property, not the very dns ptype, which
seems to be what Scott wishes.

"The DNS zone of a DNSWL" is much like the wording an MTA configuration manual
might use, isn't it?


Best
Ale

-- 
https://tools.ietf.org/html/draft-vesely-authmethod-dnswl