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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Aug 2019 00:04:59 -0700

On Wed, Jul 31, 2019 at 10:27 PM Murray S. Kucherawy <[email-masked]>
wrote:

>
> 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.  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.
>
>
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.  About the only sentence I see in there that makes sense to include
that's relevant to a registration action is the one about encoding
non-ASCII content.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 1 Aug 2019 18:32:43 +0200

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

> On Wed, Jul 31, 2019 at 9:40 PM Scott Kitterman <[email-masked]>
> 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.
> 
> 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.

> 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

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 01 Aug 2019 22:15:30 +0000

Taking a step back, iprev uses the policy ptype.  It's also based on local interpretation of DNS data.  Why doesn't policy work for dnswl just like for iprev?

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Aug 2019 23:18:20 -0700

> positive trustworthiness.

I think this is a bit unusual, but RFC8601 doesn't preclude it.  Seems to
me you're effectively throwing away the result, "pass" or "fail", if
downstream agents actually know more about the applied algorithm than the
border MTA adding it.

> more dnswl's in order to inform better on TXT record usage.

As long as the text is focused on the registration and not providing
opinion about RFC5782, it's fine.  I'm not so sure where the current text
lands.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 2 Aug 2019 11:59:58 +0200

> Taking a step back, iprev uses the policy ptype.  It's also based on local interpretation of DNS data.  Why doesn't policy work for dnswl just like for iprev?

Let me note that Section 3 of rfc8601, /The "iprev" Authentication Method/,
does not contain the term "policy".  My recollection is that reporting the
client IP is immaterial, as for SPF.  The term policy.iprev is certainly
misleading, since the value is not related to a locally-defined policy, and is
not a reversed ip.  To stick with A-R semantics, it should have been named
tcp.ip, remote.ip or some such.  If a property warrants deprecation, it's
policy.iprev.

Now for dnswl.  Knowing which zone was queried is substantial in order to
interpret policy.ip, because there is no standard format.  Yet, an
implementation could just throw a DNS query to a given local IP, instead of a
FQDN to the default DNS server.  In that case, one would have, for example:

   dnswl=pass policy.ip=127.0.9.2 policy.zone=127.0.0.2

In that case one can hardly tell which is which.  A meaningful ptype helps.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 2 Aug 2019 12:10:44 +0200

On Fri 02/Aug/2019 08:18:20 +0200 Murray S. Kucherawy wrote:

>> 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.>>
> 
> I think this is a bit unusual, but RFC8601 doesn't preclude it.  Seems to me
> you're effectively throwing away the result, "pass" or "fail", if downstream
> agents actually know more about the applied algorithm than the border MTA
> adding it.

In the case at hand, in fact, failed lookups are never reported.  If no dnswl
query is configured, it makes no sense to configure which trustworthiness value
is needed to counterbalance which negative heuristics.  The "pass" just
confirms it's mere presence.

In general, however, a filter may want to distinguish dnswl!=pass from no dnswl
query at all.  A negative query (NXDOMAIN or NO DATA) would be dnswl=none.  No
"fail" is provided for in the I-D.

Best
Ale
--

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 2 Aug 2019 10:22:50 -0700

On Fri, Aug 2, 2019 at 3:00 AM Alessandro Vesely <[email-masked]> wrote:

>   To stick with A-R semantics, it should have been named
> tcp.ip, remote.ip or some such.
>

Note that  RFC8617 section 10.2 (
https://tools.ietf.org/html/rfc8617#section-10.2) does add in an
smtp.remote-ip method item.

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 2 Aug 2019 12:58:30 -0700

On Fri, Aug 2, 2019 at 3:00 AM Alessandro Vesely <[email-masked]> wrote:

> does not contain the term "policy".
>

Wow.  I'm amazed I got away with that.

But it is clear from the things in the registry that that's how you do it.

My recollection is that reporting the
> tcp.ip, remote.ip or some such.  If a property warrants deprecation, it's

The choice of "policy" for "iprev" is rooted in history, because the
earlier versions of the document (as you well know) demanded that the
things being reported had something to do with the message itself.  "iprev"
was an exception the community chose to allow.  It pre-dated RFC5782 which
introduced DNSxLs formally.

For guidance here, I would rely on anecdotes of implementation.  Has anyone
implemented something that attaches "iprev" results?

> In that case one can hardly tell which is which.  A meaningful ptype helps.

Why would the thing attaching "dnswl=pass" not also interpret "policy.ip"?
I would expect it to have that knowledge, not downstream things.  Again, I
don't know what the value of "dnswl=pass" is if the thing attaching it
doesn't even know how to interpret the result it got.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 3 Aug 2019 17:28:13 +0200

> doesn't even know how to interpret the result it got.

If the A-R producer could interpret the encoding then it could write something
like policy.trustworthiness=x instead of policy.ip=127.x.y.z.  However, in the
words of rfc5782:

   There is no widely used convention for mapping sublist names to bits
   or values, beyond the convention that all A values SHOULD be in the
   127.0.0.0/8 range to prevent unwanted network traffic if the value is
   erroneously used as an IP address.

It turned out that there is no simple syntax to configure which bits of the A
value bear which meaning.  For usability reason, in the case at hand, the
syntax was simplified  by requiring the color of the zone, that is[*]:

   -block=zone[,var[/n.n.n.n][,msg]] or -allow=zone[,var[/n.n.n.n[,]]]

IOW, dnswl=pass means the sender was whitelisted.

Best
Ale

-- 
[*] https://www.courier-mta.org/couriertcpd.html

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 3 Aug 2019 17:40:23 +0200

On Fri 02/Aug/2019 19:22:50 +0200 Kurt Andersen (b) wrote:

>> To stick with A-R semantics, it should have been named tcp.ip, remote.ip
>> or some such.>>
> 

That's much better.  If the definition of ptype smtp were "a parameter of the
SMTP session used to relay the message" it would be perfect.  I'd propose that
policy.iprev be deprecated and smtp.remote-ip used instead.

Best
Ale
--

---

From: Jeremy Harris <[email-masked]>
Date: Sat, 3 Aug 2019 17:18:21 +0100

> implemented something that attaches "iprev" results?

Exim does.

-- 
Cheers,
  Jeremy

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 03 Aug 2019 16:30:21 +0000

On August 2, 2019 7:58:30 PM UTC, "Murray S. Kucherawy" <[email-masked]> wrote:
...
>implemented something that attaches "iprev" results?
...

The authres Python module that I maintain has implemented the structure and has examples/tests that match what you are suggesting.

It implements all the registered A-R variants for completeness.  I don't know if there are any applications that use iprev.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 7 Aug 2019 08:14:22 -0700

> IOW, dnswl=pass means the sender was whitelisted.

If that's the case, why do downstream agents need "policy.ip" at all?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 7 Aug 2019 08:16:29 -0700

> policy.iprev be deprecated and smtp.remote-ip used instead.

Given that RFC8601 was published just last month, it'll probably be a while
before this happens.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 8 Aug 2019 11:48:32 +0200

On Wed 07/Aug/2019 17:14:22 +0200 Murray S. Kucherawy wrote:
> On Sat, Aug 3, 2019 at 8:28 AM Alessandro Vesely  wrote:
>>

To be whitelisted just means that the sender is a legitimate SMTP
server, AFAICS.  I add Matthias to the recipients list as he can be
much more precise on such criteria, at least for the whitelist he runs.

policy.ip carries more details.  In my use case, "HEURISTIC" viruses
have a significant probability of being false positive.  A downstream
filter extracts the trustworthiness from the policy.ip and makes a
decision based on that value.  Note that this filter runs after the AV
filter, after the end of DATA, while dnswl=pass can be used at HELO to
mitigate SPF forwarding issues.

Some ISPs, albeit whitelisted, either have policies so sloppy as to
tolerate infected customers, or don't spend enough energy to sanitize
them anyway.  The trustworthiness somehow reflects that quality.
Dnswl.org also reports the category, another octet of policy.ip.

Best
Ale

---

From: "Stan Kalisch" <[email-masked]>
Date: Thu, 08 Aug 2019 22:04:25 -0400

On Fri, Aug 2, 2019, at 3:58 PM, Murray S. Kucherawy wrote:
> The choice of "policy" for "iprev" is rooted in history, because the earlier versions of the document (as you well know) demanded that the things being reported had something to do with the message itself. "iprev" was an exception the community chose to allow. It pre-dated RFC5782 which introduced DNSxLs formally.
> 
> For guidance here, I would rely on anecdotes of implementation. Has anyone implemented something that attaches "iprev" results?

IIRC, Fastmail's Authentication Milter does. But I also have some vague recollection that they stopped using policy.iprev, specifically.

Now looking at headers from my Fastmail customer account, it appears to me that this is indeed what they did, although I would have to recheck the actual distribution they share with everyone else to be sure. I'm sure someone at Fastmail can comment on what actually precipitated the move.

Stan

> Why would the thing attaching "dnswl=pass" not also interpret "policy.ip"? I would expect it to have that knowledge, not downstream things. Again, I don't know what the value of "dnswl=pass" is if the thing attaching it doesn't even know how to interpret the result it got.

---

From: "Marc Bradshaw" <[email-masked]>
Date: Fri, 09 Aug 2019 14:28:50 +1000

> Now looking at headers from my Fastmail customer account, it appears to me that this is indeed what they did, although I would have to recheck the actual distribution they share with everyone else…

We (Fastmail) do attach IPRev results. We used policy.iprev for the remote IP up until October 2018, although it may have been slightly later when the change made it through to production. I recall the change being made as part of a larger set of changes which came out of an ARC interop working session.
Current code uses smtp.remote-ip for a few reasons, mostly as it is more correct to attach this to the IP to the smtp type, it is also more in line with what some other providers are doing. For context, we are using this when processing messages with a trusted ARC set.

--

 Marc Bradshaw
marcbradshaw.net | @marcbradshaw <https://twitter.com/marcbradshaw>