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

["Murray S. Kucherawy" <[e-mail]>]

On Mon, Mar 19, 2018 at 5:29 PM, Alessandro Vesely <[e-mail]> wrote:

> On Sun 18/Mar/2018 13:43:56 +0100 Murray S. Kucherawy wrote:
> > On Sun, Mar 18, 2018 at 11:25 AM, Alessandro Vesely <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     Would it be possible to insert a dnswl method in the new spec?
> >     [...]
> >
> >
> > 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.
>
> 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.
>

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.

> 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?
>
> 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?
>

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.).


> > * 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.
>
> 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.
>

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?

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.
>

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