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

[Alessandro Vesely <[e-mail]>]

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.


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

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

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.