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

From: Satoru Kanno <[email-masked]>
Date: Wed, 7 Mar 2018 17:21:08 +0900

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: [email-masked]

---

From: Barry Leiba <[email-masked]>
Date: Wed, 7 Mar 2018 10:56:10 -0500

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 <[email-masked]> wrote:
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: Hector Santos <[email-masked]>
Date: Fri, 09 Mar 2018 17:04:53 -0500

> discuss this at IETF 101.

+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

---

From: Stan Kalisch <[email-masked]>
Date: Fri, 9 Mar 2018 22:06:28 -0500

Hi Satoru,

> On Mar 7, 2018, at 3:21 AM, Satoru Kanno <[email-masked]> wrote:
> 
> Dear DMARC WG Chairs,
> 

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

---

From: "Yasutaka, Genki | Dkim | OPS" <[email-masked]>
Date: Thu, 15 Mar 2018 17:39:47 +0000

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 <[email-masked]>
Rakuten, Inc.

-----Original Message-----
From: Hector Santos [mailto:[email-masked]] 
Sent: Saturday, March 10, 2018 7:05 AM
To: Satoru Kanno <[email-masked]>; [email-masked]
Cc: Takehito Akagiri <[email-masked]>; Yasutaka, Genki | Dkim | OPS <[email-masked]>
Subject: Re: [dmarc-ietf] [Request] Presentation in IETF101

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

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.

    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

---

From: "Yasutaka, Genki | Dkim | OPS" <[email-masked]>
Date: Thu, 15 Mar 2018 17:40:15 +0000

Hi Satan

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

---

From: Stan Kalisch [mailto:[email-masked]]
Sent: Saturday, March 10, 2018 12:06 PM
To: Satoru Kanno <[email-masked]>
Cc: [email-masked]; Takehito Akagiri <[email-masked]>; Yasutaka, Genki | Dkim | OPS <[email-masked]>
Subject: Re: [dmarc-ietf] [Request] Presentation in IETF101

Hi Satoru,

On Mar 7, 2018, at 3:21 AM, Satoru Kanno <[email-masked]<mailto:[email-masked]>> wrote:
Dear DMARC WG Chairs,

[Details]
----------------------
- What I want to talk?

- Time required

- Internet Draft

Thanks,

Stan

---

From: Steven M Jones <[email-masked]>
Date: Mon, 19 Mar 2018 12:14:30 -0700

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.

---

From: "Yasutaka, Genki | Dkim | OPS" <[email-masked]>
Date: Mon, 19 Mar 2018 21:02:15 +0000

Hi Steven,

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: [email-masked]

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Steven M Jones
Sent: Tuesday, March 20, 2018 4:15 AM
To: [email-masked]
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

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 19 Mar 2018 17:17:40 -0400

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:
> 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?
> 
> session - the underlying issue seems to be the use of DMARC-style alignment
> checks in the absence of a DMARC policy record.
> 
> 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.
> 
> 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

---

From: Steven M Jones <[email-masked]>
Date: Mon, 19 Mar 2018 14:35:27 -0700

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

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 20 Mar 2018 09:35:45 +0000

On Mon, Mar 19, 2018 at 7:14 PM, Steven M Jones <[email-masked]> 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.
>

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