Subject: [dmarc-ietf] updating draft-akagiri-dmarc-virtual-verification

From: Kouji Okada <[email-masked]>
Date: Fri, 24 Mar 2017 18:19:09 +0900

Folks

We are now working on revising draft-akagiri-dmarc-virtual-verification.
https://datatracker.ietf.org/doc/html/draft-akagiri-dmarc-virtual-verification

We are going to submit new version in early April.
Authors are recognizing there are some open issues for the draft.

1. The authentication code.

In the draft, we suggest to mark “dmarc=pass” in the authentication result
when the virtual dmarc verifications have passed.
We are going to keep it as it is.

In 02, we are going to mention that e-mail operators can add comments to
the authentication result field to indicate the “pass” is marked by the virtual verification.
We are not going to define the format of the comments,
but the example comment would be like below.

ex) dmarc=pass(vdmarc=true)

2. vdmarc=fail problem

When submitting 00 version of the draft,
some people gave us the comments that
it is harmful to mark “dmarc=fail” without explicit declaration of policy records.
Our intention is to utilize the authentication results of “dmarc=pass”
for the e-mails potentially can be treated as so.

As Takehito posted to this ML,
our evaluation on Japanese ISPs showed
more than 20% of received email traffic can be treated as "dmarc=pass" with our verification.
Thus our proposal helps to increase the number of legitimate e-mails on the receiver side.

“Statistics about effects of “Virtual DMARC””:
  https://www.vdmarc.dmarc.jp/?p=122

We are going to emphasize the point in 02.

3. rua, ruf

We do not define any default report destinations for the virtual verification.

4. Draft tile

Currently our draft title is “DMARC verification without record definitions(dmarc-virtual-verification)”.
Would you have any suggestions for the title?

Any comments will be appreciated.

Thank you,
Kouji Okada

---

From: Terry Zink <[email-masked]>
Date: Fri, 24 Mar 2017 16:55:42 +0000

Microsoft already does what is in the spec in Office 365 (which they specifically call out in the draft), so eventually Hotmail/Outlook.com will inherit it. But there are two differences:

1. Office 365 stamps "dmarc=bestguesspass", not "dmarc=pass". That makes it easier to distinguish in the logs
2. We do relaxed alignment, not strict alignment like it says in the spec

Seems to work just fine.

Also, not sure why there would be a discussion of rua and ruf. It's straightforward to interpolate the virtual DMARC record but how can you interpolate where to send a failure report?

--Terry

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Kouji Okada
Sent: Friday, March 24, 2017 2:19 AM
To: dmarc <[email-masked]>
Cc: Kouji Okada <[email-masked]>
Subject: [dmarc-ietf] updating draft-akagiri-dmarc-virtual-verification

Folks

We are now working on revising draft-akagiri-dmarc-virtual-verification.
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-akagiri-dmarc-virtual-verification&data=02%7C01%7Ctzink%40microsoft.com%7C75cd5739368a40ce682208d47296da95%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636259439620932357&sdata=lDAi6TjldCXogGZlQI1VpLfYOya3fjaJPRn8mtBgo1U%3D&reserved=0

In the draft, we suggest to mark “dmarc=pass” in the authentication result when the virtual dmarc verifications have passed.
We are going to keep it as it is.

In 02, we are going to mention that e-mail operators can add comments to the authentication result field to indicate the “pass” is marked by the virtual verification.
We are not going to define the format of the comments, but the example comment would be like below.

2. vdmarc=fail problem

When submitting 00 version of the draft, some people gave us the comments that it is harmful to mark “dmarc=fail” without explicit declaration of policy records.
Our intention is to utilize the authentication results of “dmarc=pass”
for the e-mails potentially can be treated as so.

“Statistics about effects of “Virtual DMARC””:
  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.vdmarc.dmarc.jp%2F%3Fp%3D122&data=02%7C01%7Ctzink%40microsoft.com%7C75cd5739368a40ce682208d47296da95%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636259439620942364&sdata=mVyeZ5EMI6cj1pvUXVYinZZi64JLqjE9v90iCUwiJ4M%3D&reserved=0

3. rua, ruf

4. Draft tile

Thank you,
Kouji Okada

_______________________________________________
dmarc mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmarc&data=02%7C01%7Ctzink%40microsoft.com%7C75cd5739368a40ce682208d47296da95%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636259439620942364&sdata=AeIU1ls97f%2FktoX0ZuTufv1xDE0Q8%2FTAq%2BGpK8g9MvE%3D&reserved=0

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 25 Mar 2017 00:45:54 -0400

For SPF, we had "best guess" [1], which we chose not to standardize at all 
because we didn't think it appropriate to break the opt-in nature of SPF.  
This concerns me a bit here, but I'm mostly writing to support the idea of 
distinguishing between some kind of guess and an actual DMARC result.

I think "dmarc=bestguesspass" is far superior to "dmarc=pass", since this is 
not a DMARC pass.  I think "dmarcguess=pass" would be better since this isn't 
properly a DMARC check at all.

Scott k

[1] http://www.openspf.org/FAQ/Best_guess_record

On Friday, March 24, 2017 04:55:42 PM Terry Zink wrote:
> Microsoft already does what is in the spec in Office 365 (which they
> specifically call out in the draft), so eventually Hotmail/Outlook.com will
> inherit it. But there are two differences:
 
> easier to distinguish in the logs
 2. We do relaxed alignment, not strict
> alignment like it says in the spec 
> Seems to work just fine.
> 
> Also, not sure why there would be a discussion of rua and ruf. It's
> straightforward to interpolate the virtual DMARC record but how can you
> interpolate where to send a failure report?
 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker
> .ietf.org%2Fdoc%2Fhtml%2Fdraft-akagiri-dmarc-virtual-verification&data=02%7C
> 01%7Ctzink%40microsoft.com%7C75cd5739368a40ce682208d47296da95%7C72f988bf86f1
> 41af91ab2d7cd011db47%7C1%7C0%7C636259439620932357&sdata=lDAi6TjldCXogGZlQI1V
> pLfYOya3fjaJPRn8mtBgo1U%3D&reserved=0
 
> when the virtual dmarc verifications have passed.
 We are going to keep it
> as it is.
> 
> In 02, we are going to mention that e-mail operators can add comments to the
> authentication result field to indicate the “pass” is marked by the virtual
> verification.
 We are not going to define the format of the comments, but
> the example comment would be like below. 
> When submitting 00 version of the draft, some people gave us the comments
> that it is harmful to mark “dmarc=fail” without explicit declaration of
> policy records.
 Our intention is to utilize the authentication results of
> “dmarc=pass” for the e-mails potentially can be treated as so.
> 
 Thus our proposal helps to increase the number of
> legitimate e-mails on the receiver side. 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.vdmarc
> .dmarc.jp%2F%3Fp%3D122&data=02%7C01%7Ctzink%40microsoft.com%7C75cd5739368a40
> ce682208d47296da95%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636259439620
> 942364&sdata=mVyeZ5EMI6cj1pvUXVYinZZi64JLqjE9v90iCUwiJ4M%3D&reserved=0

> 4. Draft tile
> 
> Currently our draft title is “DMARC verification without record
> definitions(dmarc-virtual-verification)”.
 Would you have any suggestions
> for the title?
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.or
> g%2Fmailman%2Flistinfo%2Fdmarc&data=02%7C01%7Ctzink%40microsoft.com%7C75cd57
> 39368a40ce682208d47296da95%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6362
> 59439620942364&sdata=AeIU1ls97f%2FktoX0ZuTufv1xDE0Q8%2FTAq%2BGpK8g9MvE%3D&re
> served=0
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: Kouji Okada <[email-masked]>
Date: Tue, 28 Mar 2017 07:45:38 +0900

Terry and Scott

Thank you for you feedback.
I’m sorry for my late reply.

We don’t stick around utilizing “dmarc=pass”.
The authors will discuss the authentication-results again and update the 
draft.

 >> interpolate where to send a failure report?

When submitting 00 draft,
there were some responses that
without reporting, it cannot be called DMARC.
We could utilize whois records or some other operational information,
but that kind of guess is too rude.
So, just to clarify, we kept the discussion.

Best regards,
Kouji Okada

On 2017/03/25 13:45, Scott Kitterman wrote:>

 >> 1. Office 365 stamps "dmarc=bestguesspass", not "dmarc=pass". That 
makes it
 >> easier to distinguish in the logs
 >> more than 20% of received email traffic can be treated as 
"dmarc=pass" with
 >> our verification.

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 28 Mar 2017 09:26:37 -0400

> properly a DMARC check at all.

I absolutely agree with Scott on this. "bestguesspass" is NOT DMARC. It 
is local policy applied in a DMARC like manner.

This is also why there is no legitimate place to send reports. The 
sender did not publish a DMARC record and did not ask for reports. 
Trying to guess where to send (unasked for) reports is guaranteed to end 
with poor outcomes.

Mike

---

From: Kouji Okada <[email-masked]>
Date: Sat, 1 Apr 2017 02:08:33 +0900

Mark

Thank you for your comment.

The authors are now discussing which
authentication-method or authentication-code is suitable
to be marked in the authentication-results.

> Trying to guess where to send (unasked for) reports is guaranteed to end with poor outcomes.

I totally agree.

Best regards,
Kouji Okada

> 2017/03/28 22:26、[email-masked]:
> 
> I absolutely agree with Scott on this. "bestguesspass" is NOT DMARC. It is local policy applied in a DMARC like manner.
> 
> This is also why there is no legitimate place to send reports. The sender did not publish a DMARC record and did not ask for reports. Trying to guess where to send (unasked for) reports is guaranteed to end with poor outcomes.
> 
> Mike
> 
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 31 Mar 2017 15:16:53 -0500

Please be sure to read RFC7601 while deciding, as it sets out the rules for
the registries related to Authentication-Results and what's appropriate to
put in them.

On Fri, Mar 31, 2017 at 12:08 PM, Kouji Okada <[email-masked]> wrote:

> sender did not publish a DMARC record and did not ask for reports. Trying
> to guess where to send (unasked for) reports is guaranteed to end with poor
> outcomes.
> >
> > Mike
> >
> >

---

From: Brandon Long <[email-masked]>
Date: Fri, 31 Mar 2017 14:29:51 -0700

It's unclear to me why this needs to be an RFC.  Is the point to register
specific Authentication-Results header values in IANA?

Otherwise, this seems like nothing more than some local special anti-spam
sauce.  Like Scott says, this sounds like SPF bestguess, perhaps he can
point out any discussion that was had about bestguess and why it was left
out of the SPF RFC.

Brandon

On Fri, Mar 31, 2017 at 1:16 PM, Murray S. Kucherawy <[email-masked]>
wrote:

> Please be sure to read RFC7601 while deciding, as it sets out the rules
> for the registries related to Authentication-Results and what's appropriate
> to put in them.
>