Subject: [dmarc-ietf] OT: Yet another addition to dmarc-rfc7601bis-00

From: Alessandro Vesely <[email-masked]>
Date: Sun, 18 Mar 2018 12:25:05 +0100

Would it be possible to insert a dnswl method in the new spec?

Last time I asked for its insertion, (via expert opinion) it was rejected based
on the definition of ptype, according to which The exception to ptype +
property indicating which particular part of the message from which the data is
extracted is policy.[*]  Instead, dnswl method[**] provides for a ptype of
"dns".  For a live example:

    Authentication-Results: wmail.tana.it;
        dnswl=pass dns.zone=list.dnswl.org
        policy.ip=127.0.9.2
        policy.txt="ietf.org https://dnswl.org/s/?s=1703"

Adding that method in the main spec would certainly result in a better
visibility, which is why I'm asking.  It is a very easy method for those many
servers that put no authentication at all on the messages they relay.

Besides, that ptype could also be used to define DKIM algorithm as, say, dns.a
or dns.key-a instead of header.a --just an idea.

Best
Ale

[*] https://mailarchive.ietf.org/arch/msg/apps-discuss/zoMqTkkSkAXiwFTnFGWgXIaXy0c
[**] https://datatracker.ietf.org/doc/draft-vesely-authmethod-dnswl/

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 18 Mar 2018 13:27:01 +0100

> or dns.key-a instead of header.a --just an idea.

Ops, I got confused by another argument[*].  Yet, dns it could used for
the t= key flag.

[*] https://mailarchive.ietf.org/arch/msg/dmarc/T_--uL3ZmSju3vlkkrx1T7hiziw

Ale

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 18 Mar 2018 12:43:56 +0000

On Sun, Mar 18, 2018 at 11:25 AM, Alessandro Vesely <[email-masked]> wrote:

> [...]

I'd prefer to do this as its own document.  The current one is feeling very
"kitchen sink" already, and this change has more meat to it than the others
that have been requested.

>         policy.txt="ietf.org https://dnswl.org/s/?s=1703"

I have a few things I'd like to see done differently in your expired draft:

* "dnswl" is specifically a whitelist; should we also register "dnsbl"?  Or
do we really need two distinct entries for the same mechanism?
* I think "policy.txt" is under-specified.  A downstream agent shouldn't be
expected to know how to decode this, and it can change from one
implementation to the next.
* Why repeat "policy.ip" for multiple replies, rather than comma-separating
the various replies?

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 19 Mar 2018 18:29:36 +0100

On Sun 18/Mar/2018 13:43:56 +0100 Murray S. Kucherawy wrote:
> On Sun, Mar 18, 2018 at 11:25 AM, Alessandro Vesely <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

A-R's spec has been a medley of methods since its first appearance.  I deem
that's very practical, especially compared to an unreferenced, obscure
document.  Not to mention the cost of issuing an extra RFC just for that
method.  I posted the xml so as to minimize editorial work on your side, in
case you change your mind.

>         Authentication-Results: wmail.tana.it <http://wmail.tana.it>;
>             dnswl=pass dns.zone=list.dnswl.org <http://list.dnswl.org>
>             policy.ip=127.0.9.2
> * "dnswl" is specifically a whitelist; should we also register "dnsbl"?  Or do
> we really need two distinct entries for the same mechanism?

My feeling is that dnsbl is not an authentication of any kind.  For lists like,
for example, Spamhaus SBL, a positive lookup does not identify a sender domain.
 In addition, MTAs are already plenty of options about whether and how to drop
relevant messages.  What would be a use case for dnsbl?

> expected to know how to decode this, and it can change from one implementation
> to the next.

Rfc5782 doesn't say much on TXT records from white lists.  FWIW, Courier-MTA
implementation needs an additional setting to query ANY or TXT rather than just
A[*].  I set that because the specific dnswl I use often conveys the domain
name in the TXT record, which is consistent with other A-R methods.

Should the spec recommend that all lists do so?  I added Section 3 in an
attempt to accomplish that:
https://tools.ietf.org/rfcdiff?url2=draft-vesely-authmethod-dnswl-07.txt

> * Why repeat "policy.ip" for multiple replies, rather than comma-separating the
> various replies?

No reason, easily changed.

Best
Ale
-- 

[*] http://www.courier-mta.org/couriertcpd.html#idm140519311889024
Section DNS ACCESS LISTS explains the settings and mentions what will be
exported in environment variables.  A-R header fields are not documented.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 20 Mar 2018 01:11:50 +0000

> case you change your mind.

There are some that have been part of the base A-R specs (DKIM, SPF) but
some that have not (VBR, SMIME, RRVS).  I think this one warrants a
separate specification.

You already have the draft.

> relevant messages.  What would be a use case for dnsbl?

I don't see a difference.  If you don't do a flat accept on a dnswl hit and
instead want to provide the information to some inner agent that can
evaluate it, then you have to accept the idea that someone might want to do
the same thing on a dnsbl hit (or a DKIM failure, or an SPF failure, etc.).

> name in the TXT record, which is consistent with other A-R methods.

One of the purposes of A-R since the beginning is to spare downstream
agents from having to do any more parsing.   Passing a raw TXT reply is
antithetical to that purpose.  What would you do with this downstream?

> No reason, easily changed.

You added "Multiple entries MAY be arranged in a comma-separated list", but
I don't think that contributes to interoperability.  You should be
normative here.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 20 Mar 2018 12:47:37 +0100

> You already have the draft.

In that case, I'll wait for rfc7601bis to be published and then try and see how
individual submission works.

This WG ought to be unburdened of further OT discussion, so I reply privately
to the rest of your message.

Ale