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

[Murray S. Kucherawy]

On Mon, Mar 19, 2018 at 5:29 PM, Alessandro Vesely  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  > > 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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] [Request] Presentation in IETF101

[Steven M Jones]

On 3/19/18 2:02 PM, Yasutaka, Genki | Dkim | OPS wrote:
>
>
> You can download from the following link.
>
> https://datatracker.ietf.org/meeting/agenda.html
>
> - Virtual DMARC: DMARC verification without record definitions
>
> I will send you directly just in case.
>

Thank you, I found it -- I had used the "download meeting materials as
PDF" link, which didn't include either slide deck, but I found the
slides under the "Show meeting materials" link.

To the list, in the (unlikely?) event I'm not the only one...

--S.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] [Request] Presentation in IETF101

[Scott Kitterman]

Since SPF "Best Guess" is mentioned ...

This was developed very, very early in the SPF project to help bootstrap the 
protocol when not very many domains published records.  When the original SPF 
RFC, RFC 4408, was developed, it was considered for standardization and the 
judgment of the community was that it was not suitable for standardization.

Fundamentally, both SPF "Best Guess" and "Virtual DMARC" destroy the opt-in 
nature of SPF and DMARC and should be considered harmful.  If an entity wants 
to apply this kind of test, it's a purely internal policy decision.  No RFC 
needed.  Authentication Results already provides for documenting policy 
results.  No need for trying to shoehorn this into DMARC results.  It's not a 
DMARC result.

This is not only not opt-in, there's no opt-out mechanism.

Please don't do this (same as last time this came up - yes, I did check the 
slides to see if anything has changed and it hasn't).

Scott K

On Monday, March 19, 2018 09:02:15 PM Yasutaka, Genki | Dkim | OPS wrote:
> Hi Steven,
> 
> Thank you for your comment.
> 
> You can download from the following link.
> 
> https://datatracker.ietf.org/meeting/agenda.html
> 
> - Virtual DMARC: DMARC verification without record definitions
> 
> I will send you directly just in case.
> 
> Regards,
> Genki
> 
> ---
> Genki YASUTAKA
> 
> Rakuten, Inc.
> Mail: genki.yasut...@rakuten.com
> 
> -Original Message-
> From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Steven M Jones
> Sent: Tuesday, March 20, 2018 4:15 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] [Request] Presentation in IETF101
> 
> I want to thank Yasutaka san for presenting the Virtual DMARC proposal.
> I believe the situation he and his colleagues are addressing would benefit
> from more attention.
> 
> The meeting materials at IETF do not seem to include Yasutaka san's slides.
> If I didn't just miss it, would it be possible to share that presentation?
> 
> Aside from changes to the "dmarc=" allowed values in
> Authentication-Results: - and I think this echos a point made during the
> session - the underlying issue seems to be the use of DMARC-style alignment
> checks in the absence of a DMARC policy record.
> 
> That practice may be useful to the receiver's evaluation of SPF and DKIM
> results. Perhaps that should be explored as a receiver/authenticator best
> practice. It may be _very_ useful to capture these statistics to make it
> clearer to domain-owners/senders that more current email traffic would pass
> DMARC checks than they may presently realize. I would definitely like to
> explore that further.
> 
> But DMARC is based on cooperation between domain-owner/sender and
> authenticator/receiver. And it depends on the explicit
> opt-in/request-for-treatment from the domain-owner, signaled by a public
> DNS record, and the reporting mechanisms so that the domain-owner/sender
> can correct errors in implementation of authentication measures.
> 
> Virtual DMARC seems to be discussing only what happens within the
> authenticator/receiver, but perhaps I have missed this part. I look forward
> to re-reading the proposal and slides with this in mind.
> 
> --Steve.
> 
> Steve Jones
> DMARC.org, LinkedIn, crash.com, etc.
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] [Request] Presentation in IETF101

[Yasutaka, Genki | Dkim | OPS]

Hi Steven,

Thank you for your comment.

You can download from the following link.

https://datatracker.ietf.org/meeting/agenda.html

- Virtual DMARC: DMARC verification without record definitions

I will send you directly just in case.

Regards,
Genki

---
Genki YASUTAKA

Rakuten, Inc.
Mail: genki.yasut...@rakuten.com

-Original Message-
From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Steven M Jones
Sent: Tuesday, March 20, 2018 4:15 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] [Request] Presentation in IETF101

I want to thank Yasutaka san for presenting the Virtual DMARC proposal. 
I believe the situation he and his colleagues are addressing would benefit from 
more attention.

The meeting materials at IETF do not seem to include Yasutaka san's slides. If 
I didn't just miss it, would it be possible to share that presentation?

Aside from changes to the "dmarc=" allowed values in
Authentication-Results: - and I think this echos a point made during the 
session - the underlying issue seems to be the use of DMARC-style alignment 
checks in the absence of a DMARC policy record.

That practice may be useful to the receiver's evaluation of SPF and DKIM 
results. Perhaps that should be explored as a receiver/authenticator best 
practice. It may be _very_ useful to capture these statistics to make it 
clearer to domain-owners/senders that more current email traffic would pass 
DMARC checks than they may presently realize. I would definitely like to 
explore that further.

But DMARC is based on cooperation between domain-owner/sender and 
authenticator/receiver. And it depends on the explicit 
opt-in/request-for-treatment from the domain-owner, signaled by a public DNS 
record, and the reporting mechanisms so that the domain-owner/sender can 
correct errors in implementation of authentication measures.

Virtual DMARC seems to be discussing only what happens within the 
authenticator/receiver, but perhaps I have missed this part. I look forward to 
re-reading the proposal and slides with this in mind.

--Steve.

Steve Jones
DMARC.org, LinkedIn, crash.com, etc.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] [Request] Presentation in IETF101

[Steven M Jones]

I want to thank Yasutaka san for presenting the Virtual DMARC proposal. 
I believe the situation he and his colleagues are addressing would 
benefit from more attention.


The meeting materials at IETF do not seem to include Yasutaka san's 
slides. If I didn't just miss it, would it be possible to share that 
presentation?


Aside from changes to the "dmarc=" allowed values in 
Authentication-Results: - and I think this echos a point made during the 
session - the underlying issue seems to be the use of DMARC-style 
alignment checks in the absence of a DMARC policy record.


That practice may be useful to the receiver's evaluation of SPF and DKIM 
results. Perhaps that should be explored as a receiver/authenticator 
best practice. It may be _very_ useful to capture these statistics to 
make it clearer to domain-owners/senders that more current email traffic 
would pass DMARC checks than they may presently realize. I would 
definitely like to explore that further.


But DMARC is based on cooperation between domain-owner/sender and 
authenticator/receiver. And it depends on the explicit 
opt-in/request-for-treatment from the domain-owner, signaled by a public 
DNS record, and the reporting mechanisms so that the domain-owner/sender 
can correct errors in implementation of authentication measures.


Virtual DMARC seems to be discussing only what happens within the 
authenticator/receiver, but perhaps I have missed this part. I look 
forward to re-reading the proposal and slides with this in mind.


--Steve.

Steve Jones
DMARC.org, LinkedIn, crash.com, etc.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Alessandro Vesely]

On Sun 18/Mar/2018 13:43:56 +0100 Murray S. Kucherawy wrote:
> On Sun, Mar 18, 2018 at 11:25 AM, Alessandro Vesely  > 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 ;
>         dnswl=pass dns.zone=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.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc