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.
>> 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?
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:>
>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:
>
>> 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 protected]] On Behalf Of Kouji Okada
>> Sent: Friday, March 24, 2017 2:19 AM
>> To: dmarc <[email protected]>
>> Cc: Kouji Okada <[email protected]>
>> 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%7C
>>
01%7Ctzink%40microsoft.com%7C75cd5739368a40ce682208d47296da95%7C72f988bf86f1
>>
41af91ab2d7cd011db47%7C1%7C0%7C636259439620932357&sdata=lDAi6TjldCXogGZlQI1V
>> pLfYOya3fjaJPRn8mtBgo1U%3D&reserved=0
>
>> 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://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
>
>> 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
>>
>>
>> _______________________________________________
>> dmarc mailing list
>> [email protected]
>>
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 protected]
>> https://www.ietf.org/mailman/listinfo/dmarc
>
>_______________________________________________
>dmarc mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/dmarc
>
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
