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

2018-04-26 Thread Takehito Akagiri 
Hi, 

> DKIM has opt-in nature.

If opt-in means that DMARC record exists, our proposal is to change this opt-in 
nature because, as Shoko mentioned, virtual DMARC only focuses on the case 
which is obviously determined PASS.

No one will not be in troubled, so I think we can modify about that.
If not, I would like to know the specific situation. 


> Receivers can work this kind of operations using logs as they like.

Yes, receivers can do by themselves if they do not care about the compliance 
with RFC7489.
It specifies that the receiver adds dmarc=none in case there is no DMARC record,
while dmarc=pass will be added if DMARC record exists.
So I think we should discuss this contradiction.

---From RFC7489--
11.2.  Authentication-Results Result Registry Update
   IANA has added the following in the "Email Authentication Result
   Names" registry:
   Code:  none
   Existing/New Code:  existing
   Defined:  [AUTH-RESULTS]
   Auth Method:  dmarc (added)

   Meaning:  No DMARC policy record was published for the aligned
  identifier, or no aligned identifier could be extracted.



> DMARC is composed by policy and reporting, but Virtual DMARC does not have 
> reporting.

Is it acceptable to introduce the new AR code, such as dmarc=SoftPass,
and add it if no reporting policy is published ?
With this new code, one can distinguish DMARC with reporting from DMARC without 
reporting.
# In the current I-D, it specifies as PASS.


To summarize, 
1. Whether DMARC always requires opt-in
2. Whether dmarc=none is appropriate for the case where there is no DMARC record
3. Whether reporting is mandatory for DMARC



Best regards,
--Takehito Akagiri




- 元のメッセージ -
差出人: "Yasutaka, Genki | Dkim | OPS" <genki.yasut...@rakuten.com>
宛先: "Shoko YONEZAWA" <yonez...@lepidum.co.jp>, dmarc@ietf.org
Cc: "Yasutaka, Genki | Dkim | OPS" <genki.yasut...@rakuten.com>
送信済み: 2018年4月26日, 木曜日 午後 6:49:46
件名: Re: [dmarc-ietf] [Request] Presentation in IETF101

My understanding is that we have received some comments so far against Virtual 
DMARC.

The main comments are as follows:
- DKIM has opt-in nature.
- DMARC is composed by policy and reporting, but Virtual DMARC does not have 
reporting.
- Receivers can work this kind of operations using logs as they like.

Regards,
Genki

---
Genki YASUTAKA
Rakuten, Inc.
Mail: genki.yasut...@rakuten.com

-Original Message-
From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Shoko YONEZAWA
Sent: Thursday, April 26, 2018 4:38 PM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] [Request] Presentation in IETF101

My opinion is that there seems no trouble in the case that the receiver issues 
dmarc=pass to the mail, whose domain has no DMARC record, and which is 
determined dmarc=pass even if DMARC record exists.

In such case, dmarc=pass will be issued for any DMARC record where "strict" 
decision policy is set.

Shoko

On 2018/04/18 0:59, Dave Crocker wrote:
> +1, for all of the below.
> 
> 
> d/
> 
> On 4/17/2018 8:41 AM, Steve Atkins wrote:
>>
>>> On Apr 16, 2018, at 11:07 PM, Kazunori ANDO <a...@bbsec.co.jp> wrote:
>>>
>>> I think "virtual DMARC" is out of DMARC scope, because it's a purely 
>>> internal policy decision.
>>
>> +1 for the (not entirely unreasonable, but entirely internal)
>> algorithm used, -1 for the terminology.
>>
>> Where it's in scope is that it's using the term DMARC for something 
>> that is really not DMARC and as part of that it seems to suggest 
>> squatting on the dmarc= namespace in Authentication-Results.
>>
>> On 2018/03/20 6:17, Scott Kitterman wrote:
>>> Fundamentally, both SPF "Best Guess" and "Virtual DMARC" destroy the 
>>> opt-in nature of SPF and DMARC and should be considered harmful.
>>
>> +1
>>
>> Again, please don't do this.
>>
>> Cheers,
>>    Steve
>>
>> ___
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
> 
> 

--
Shoko YONEZAWA
Lepidum Co. Ltd.
yonez...@lepidum.co.jp
TEL: +81-3-6276-5103

___
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

2018-04-26 Thread Yasutaka, Genki | Dkim | OPS 
My understanding is that we have received some comments so far against Virtual 
DMARC.

The main comments are as follows:
- DKIM has opt-in nature.
- DMARC is composed by policy and reporting, but Virtual DMARC does not have 
reporting.
- Receivers can work this kind of operations using logs as they like.

Regards,
Genki

---
Genki YASUTAKA
Rakuten, Inc.
Mail: genki.yasut...@rakuten.com

-Original Message-
From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Shoko YONEZAWA
Sent: Thursday, April 26, 2018 4:38 PM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] [Request] Presentation in IETF101

My opinion is that there seems no trouble in the case that the receiver issues 
dmarc=pass to the mail, whose domain has no DMARC record, and which is 
determined dmarc=pass even if DMARC record exists.

In such case, dmarc=pass will be issued for any DMARC record where "strict" 
decision policy is set.

Shoko

On 2018/04/18 0:59, Dave Crocker wrote:
> +1, for all of the below.
> 
> 
> d/
> 
> On 4/17/2018 8:41 AM, Steve Atkins wrote:
>>
>>> On Apr 16, 2018, at 11:07 PM, Kazunori ANDO <a...@bbsec.co.jp> wrote:
>>>
>>> I think "virtual DMARC" is out of DMARC scope, because it's a purely 
>>> internal policy decision.
>>
>> +1 for the (not entirely unreasonable, but entirely internal)
>> algorithm used, -1 for the terminology.
>>
>> Where it's in scope is that it's using the term DMARC for something 
>> that is really not DMARC and as part of that it seems to suggest 
>> squatting on the dmarc= namespace in Authentication-Results.
>>
>> On 2018/03/20 6:17, Scott Kitterman wrote:
>>> Fundamentally, both SPF "Best Guess" and "Virtual DMARC" destroy the 
>>> opt-in nature of SPF and DMARC and should be considered harmful.
>>
>> +1
>>
>> Again, please don't do this.
>>
>> Cheers,
>>    Steve
>>
>> ___
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
> 
> 

--
Shoko YONEZAWA
Lepidum Co. Ltd.
yonez...@lepidum.co.jp
TEL: +81-3-6276-5103

___
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

2018-04-26 Thread Shoko YONEZAWA 

My opinion is that there seems no trouble
in the case that the receiver issues dmarc=pass to the mail,
whose domain has no DMARC record,
and which is determined dmarc=pass even if DMARC record exists.

In such case, dmarc=pass will be issued for any DMARC record
where "strict" decision policy is set.

Shoko

On 2018/04/18 0:59, Dave Crocker wrote:

+1, for all of the below.


d/

On 4/17/2018 8:41 AM, Steve Atkins wrote:



On Apr 16, 2018, at 11:07 PM, Kazunori ANDO  wrote:

I think "virtual DMARC" is out of DMARC scope,
because it's a purely internal policy decision.


+1 for the (not entirely unreasonable, but entirely internal) 
algorithm used, -1 for the terminology.


Where it's in scope is that it's using the term DMARC for something 
that is really not DMARC and as part of that it seems to suggest 
squatting on the dmarc= namespace in Authentication-Results.


On 2018/03/20 6:17, Scott Kitterman wrote:
Fundamentally, both SPF "Best Guess" and "Virtual DMARC" destroy the 
opt-in

nature of SPF and DMARC and should be considered harmful.


+1

Again, please don't do this.

Cheers,
   Steve

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






--
Shoko YONEZAWA
Lepidum Co. Ltd.
yonez...@lepidum.co.jp
TEL: +81-3-6276-5103

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

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

2018-04-17 Thread Dave Crocker 

+1, for all of the below.


d/

On 4/17/2018 8:41 AM, Steve Atkins wrote:



On Apr 16, 2018, at 11:07 PM, Kazunori ANDO  wrote:

I think "virtual DMARC" is out of DMARC scope,
because it's a purely internal policy decision.


+1 for the (not entirely unreasonable, but entirely internal) algorithm used, 
-1 for the terminology.

Where it's in scope is that it's using the term DMARC for something that is 
really not DMARC and as part of that it seems to suggest squatting on the 
dmarc= namespace in Authentication-Results.

On 2018/03/20 6:17, Scott Kitterman wrote:

Fundamentally, both SPF "Best Guess" and "Virtual DMARC" destroy the opt-in
nature of SPF and DMARC and should be considered harmful.


+1

Again, please don't do this.

Cheers,
   Steve

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




--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

2018-04-17 Thread Steve Atkins 

> On Apr 16, 2018, at 11:07 PM, Kazunori ANDO  wrote:
> 
> I think "virtual DMARC" is out of DMARC scope,
> because it's a purely internal policy decision.

+1 for the (not entirely unreasonable, but entirely internal) algorithm used, 
-1 for the terminology.

Where it's in scope is that it's using the term DMARC for something that is 
really not DMARC and as part of that it seems to suggest squatting on the 
dmarc= namespace in Authentication-Results. 

On 2018/03/20 6:17, Scott Kitterman wrote:
> Fundamentally, both SPF "Best Guess" and "Virtual DMARC" destroy the opt-in
> nature of SPF and DMARC and should be considered harmful.

+1

Again, please don't do this.

Cheers,
  Steve

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

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

2018-04-17 Thread Kazunori ANDO 

+1.

I think "virtual DMARC" is out of DMARC scope,
because it's a purely internal policy decision.

On 2018/03/20 6:17, Scott Kitterman wrote:

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

Kazunori ANDO / a...@bbsec.co.jp

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

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

2018-03-20 Thread Kurt Andersen (b) 
On Mon, Mar 19, 2018 at 7:14 PM, Steven M Jones  wrote:

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


In some hallway discussion after the session yesterday, we discussed the
assertion (made during the meeting) that all of the necessary information
to evaluate alignment is already present within the headers on a message.
While that is true for the initial receiver, there are scenarios for
intermediated mail where the 5322.From may be modified (for instance, SRS
processing) and as such, the alignment of the original message may not be
able to be deduced by downstream MTAs. It may be worthwhile to consider
earmarking the 5322.From domain into ARC's AAR header to cover such a
scenario. Whether that information should also be recorded into the A-R
header is less clear.

I think it is pretty clear that this is not and can not be "DMARC" without
sender participation, but alignment of identifiers can certainly be
recorded for downstream usage.

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

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

2018-03-19 Thread 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

2018-03-19 Thread 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

2018-03-19 Thread 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

2018-03-19 Thread 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] [Request] Presentation in IETF101

2018-03-15 Thread Yasutaka, Genki | Dkim | OPS 
Hi Satan

Thank you for your comment.

The first one is that we need to consider more negative impacts, but basically 
this mechanism will be well becasue this supports only emails which would 
potentially be "dmarc=pass", I think.

The second is that

> The second option, in practice, results in bulk, unsolicited email.

I’m on the same page. We listed this in discussion points, but that may be a 
trivial solution.

Regards,
Genki



---

Genki YASUTAKA <genki.yasut...@rakuten.com>
Rakuten, Inc.

From: Stan Kalisch [mailto:s...@glyphein.mailforce.net]
Sent: Saturday, March 10, 2018 12:06 PM
To: Satoru Kanno <ka...@lepidum.co.jp>
Cc: dmarc@ietf.org; Takehito Akagiri <akag...@regumi.net>; Yasutaka, Genki | 
Dkim | OPS <genki.yasut...@rakuten.com>
Subject: Re: [dmarc-ietf] [Request] Presentation in IETF101

Hi Satoru,

On Mar 7, 2018, at 3:21 AM, Satoru Kanno 
<ka...@lepidum.co.jp<mailto:ka...@lepidum.co.jp>> wrote:
Dear DMARC WG Chairs,

I'm sending to you on behalf of Genki Yasutaka-san.

As I asked you last November, we are preparing for the next track,
with the intention of not only reviewing this draft, but also
implementing for verification of vDMARC. If possible, I'd like to
discuss this at IETF 101.

[Details]
--
- What I want to talk?
 Draft Overview and Implementation of vDMARC

- Time required
 10 minutes (*even for 5 minutes, if your schedule is too busy to adjust.)

- Internet Draft
  https://datatracker.ietf.org/doc/draft-akagiri-dmarc-virtual-verification/

I've only been able to give this draft a brief initial look, but I do have 
comments regarding two issues.


First, regarding this text:



"In this draft, we propose to explicitly mark emails which are

potentially "dmarc=pass", but are not marked as such via regular DMARC 
verification (None(2)), as "dmarc=pass"."


What could happen as the result of this behavior, in the cases of forwarding or 
mailing lists, one could end up with one Authentication-Results header which 
contains, "dmarc=pass", but another which contains, "dmarc=none".  Which 
bizarrely, in this kind of scenario, bypasses the mailing-list problem DMARC 
presently suffers from, but, well, arguably further confuses the issue, and 
calls into question the draft's assertion that "simply utilizing

"dmarc=pass" makes it easier to leverage the field...for end users without 
enough expertise..."  (I suppose you could still make that argument if the end 
user is viewing the "DMARC-ish" result via a UI like, say, GMail's, and that UI 
presents some kind of calibrated result.)


Second, regarding this text:


"There would be differing opinions regarding DMARC reports.  One is the opinion 
that reports without explicitly published DMARC records are harmful, while 
another one is that without reports, virtual DMARC verification can not be 
called DMARC.  Currently, we are siding with the first opinion in this draft."


I don't see how you have a choice.  The second option, in practice, results in 
bulk, unsolicited email.



Thanks,

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

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

2018-03-15 Thread Yasutaka, Genki | Dkim | OPS 
Hi Hector,

Thank you for your comment.

You know, we've focusing on emails which would potentially be marked as 
"dmarc=pass" in this draft, but we'd not almost aware of the opposite point so 
far. I would like to listen to your suggestions slowly.

Regards,
Genki

---
Genki YASUTAKA <genki.yasut...@rakuten.com>
Rakuten, Inc.

-Original Message-
From: Hector Santos [mailto:hsan...@isdg.net] 
Sent: Saturday, March 10, 2018 7:05 AM
To: Satoru Kanno <ka...@lepidum.co.jp>; dmarc@ietf.org
Cc: Takehito Akagiri <akag...@regumi.net>; Yasutaka, Genki | Dkim | OPS 
<genki.yasut...@rakuten.com>
Subject: Re: [dmarc-ietf] [Request] Presentation in IETF101

On 3/7/2018 3:21 AM, Satoru Kanno wrote:
> Dear DMARC WG Chairs,
>
> I'm sending to you on behalf of Genki Yasutaka-san.
>
> As I asked you last November, we are preparing for the next track, 
> with the intention of not only reviewing this draft, but also 
> implementing for verification of vDMARC. If possible, I'd like to 
> discuss this at IETF 101.
>
> [Details]
> --
> - What I want to talk?
>Draft Overview and Implementation of vDMARC
>
> - Time required
>10 minutes (*even for 5 minutes, if your schedule is too busy to 
> adjust.)
>
> - Internet Draft
> 
> https://datatracker.ietf.org/doc/draft-akagiri-dmarc-virtual-verificat
> ion/
> --
>
> Thank you for your cooperation and understanding.

+1 to discussing this the concept.  Overall, I think "default" 
protocol considerations should be included as part of a DMARC Proposed Standard 
effort.

Interesting note stated by this draft:

Microsoft Office365 employs the same technique as one mentioned in
this draft ([BestGuessPass]).  They append "dmarc=bestguesspass" to
the Authentication-Results to indicate the authenticity of received
emails to receiving MUAs.

Why can't there be a "dmarc=bestguessfail?"

If the Author Domain (5322.From) has no DMARC record, but there is a matching 
domain SPF record with a HARDFAIL policy, when a message fails due to SPF, some 
systems will reject at SMTP before or at DATA or accept and quarantine the SPF 
failed message. With the former, this concept does't apply since there is no AR 
record for this result. With the latter, the result "dmarc=bestguessfail" would 
better match what SPF exclusively produced - a failed condition.

I actually found this to be a high true condition:

If a domain has an exclusive, restricted SPF record (HARDFAIL), the odds
are very high that the same or equal spoof detections (failures) would
result if the domain only had a exclusive, restricted DKIM Policy
model (ADSP, DMARC) record and not a SPF record.


--
HLS


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

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

2018-03-09 Thread Hector Santos 

On 3/7/2018 3:21 AM, Satoru Kanno wrote:

Dear DMARC WG Chairs,

I'm sending to you on behalf of Genki Yasutaka-san.

As I asked you last November, we are preparing for the next track,
with the intention of not only reviewing this draft, but also
implementing for verification of vDMARC. If possible, I'd like to
discuss this at IETF 101.

[Details]
--
- What I want to talk?
   Draft Overview and Implementation of vDMARC

- Time required
   10 minutes (*even for 5 minutes, if your schedule is too busy to adjust.)

- Internet Draft
https://datatracker.ietf.org/doc/draft-akagiri-dmarc-virtual-verification/
--

Thank you for your cooperation and understanding.


+1 to discussing this the concept.  Overall, I think "default" 
protocol considerations should be included as part of a DMARC Proposed 
Standard effort.


Interesting note stated by this draft:

   Microsoft Office365 employs the same technique as one mentioned in
   this draft ([BestGuessPass]).  They append "dmarc=bestguesspass" to
   the Authentication-Results to indicate the authenticity of received
   emails to receiving MUAs.

Why can't there be a "dmarc=bestguessfail?"

If the Author Domain (5322.From) has no DMARC record, but there is a 
matching domain SPF record with a HARDFAIL policy, when a message 
fails due to SPF, some systems will reject at SMTP before or at DATA 
or accept and quarantine the SPF failed message. With the former, this 
concept does't apply since there is no AR record for this result. With 
the latter, the result "dmarc=bestguessfail" would better match what 
SPF exclusively produced - a failed condition.


I actually found this to be a high true condition:

   If a domain has an exclusive, restricted SPF record (HARDFAIL), 
the odds
   are very high that the same or equal spoof detections (failures) 
would

   result if the domain only had a exclusive, restricted DKIM Policy
   model (ADSP, DMARC) record and not a SPF record.


--
HLS


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

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

2018-03-07 Thread Barry Leiba 
We will add this to the agenda.

Does anyone else have specific agenda items they'd like to have added?

Barry, as chair

On Wed, Mar 7, 2018 at 3:21 AM, Satoru Kanno  wrote:
> Dear DMARC WG Chairs,
>
> I'm sending to you on behalf of Genki Yasutaka-san.
>
> As I asked you last November, we are preparing for the next track,
> with the intention of not only reviewing this draft, but also
> implementing for verification of vDMARC. If possible, I'd like to
> discuss this at IETF 101.
>
> [Details]
> --
> - What I want to talk?
>   Draft Overview and Implementation of vDMARC
>
> - Time required
>   10 minutes (*even for 5 minutes, if your schedule is too busy to adjust.)
>
> - Internet Draft
>https://datatracker.ietf.org/doc/draft-akagiri-dmarc-virtual-verification/
> --
>
> Thank you for your cooperation and understanding.
>
> Regards,
> Satoru
>
> --
> Satoru Kanno
> Lepidum Co. Ltd.
>
> E-Mail: ka...@lepidum.co.jp
>
> ___
> 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