Subject: [dmarc-ietf] Fwd: I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt

From: Kouji Okada <[email-masked]>
Date: Tue, 15 Mar 2016 15:28:23 +0900

We have submitted a draft about DMARC default verification
for domains not publishing DMARC records.
Any comments will be appreciated.

Best wishes

Kouji Okada

> 転送されたメッセージ：
> 
> 差出人: [email-masked]
> 件名: I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt
> 日付: 2016年3月14日 13:30:43 JST
> 宛先: <[email-masked]>
> 返信先: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>        Title           : DMARC verification without record definitions
>        Authors         : Takehito Akagiri
>                          Genki Yasutaka
>                          Masaki Kase
>                          Kouji Okada
>                          Kaoru Maeda
> 	Filename        : draft-akagiri-dmarc-virtual-verification-00.txt
> 	Pages           : 7
> 	Date            : 2016-03-13
> 
> Abstract:
>   DMARC is a powerful architecture to defend mail end users from
>   malicious mail activities, but its deployment is still under process.
>   To encourage the installations of DMARC, we propose an incremental
>   deployment procedure in this document.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-akagiri-dmarc-virtual-verification/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-akagiri-dmarc-virtual-verification-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Steve Atkins <[email-masked]>
Date: Tue, 15 Mar 2016 05:32:56 -0700

> On Mar 14, 2016, at 11:28 PM, Kouji Okada <[email-masked]> wrote:
> 

Summary: If a domain does not opt-in to using DMARC, treat the domain
as though it had opted-in to using DMARC with "p=none adkim=s aspf=s".
Once that's deployed, change it to "p=reject adkim=s aspf=s". Possibly
do "p=quarantine" between the two.

There are multiple problems with this suggestion.

Firstly, DMARC is an opt-in protocol for good reason. It's a lot of work to
clean up all the mail streams for a domain such that all email is authenticated.
In many cases it is impossible to do so. Those domains that have not done
so should not publish a DMARC record.

Requiring DMARC-esque authentication (let alone strict alignment) from domains
that are not ready to use DMARC will cause a lot of wanted email to be treated as
having failed that test.

In your first phase, p=none, this will have no effect. The value of using p=none
in DMARC is so that domains can take advantage of DMARC reporting without
loss of legitimate email. You have no reporting, so this provides no value.

In your middle phase, p=quarantine, this will cause massive loss of wanted email while
still providing no feedback to senders.

In your final phase, p=reject, there will continue to be massive loss of wanted email.

In none of those phases does your draft add any value. If a receiver wants to pay attention to
whether mail is authenticated or not it can already do so, and it can do so much
more effectively than any approach that requires strict DMARC style alignment.

Cheers,
  Steve

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 15 Mar 2016 14:43:07 +0100 (CET)

> more effectively than any approach that requires strict DMARC style alignment.

Well said, +1.

/rolf

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 15 Mar 2016 16:47:04 +0100

> Any comments will be appreciated.

Maybe it's me, but I'm unable to make sense of the last paragraph of Section 3:

   When a DKIM verification passes, the virtual DMARC verification for
   the same email always passes.  DMARC verification compares the
   RFC5322.from and domains described in the d tags of DKIM-Signature
   field of the received email.  To pass the DKIM verification those two
   fields must be identical.  Therefore, when the DKIM verification
   passes, the virtual verification of DMARC also passes.

The mail message I'm replying to has dkim=pass (header.i=@ietf.org), but
wouldn't have passed a virtual DMARC verification.  Hence the first sentence is
false.  The second and third sentences express lepidum.co.jp != ietf.org
correctly, but the fourth sentence infers the thesis wrongly.  What am I missing?

Ale

---

From: Franck Martin <[email-masked]>
Date: Tue, 15 Mar 2016 13:13:54 -0500 (CDT)

----- Original Message -----
> From: "Kouji Okada" <[email-masked]>
> To: [email-masked]
> Cc: "Kouji Okada" <[email-masked]>, [email-masked]
> Sent: Monday, March 14, 2016 11:28:23 PM
> Subject: [dmarc-ietf] Fwd: I-D Action:	draft-akagiri-dmarc-virtual-verification-00.txt
> 

I have used to some form of success where all is considered in relaxed mode and with p=none. 

If I get a dmarc "pass" then I know the email is really coming from the domain it claims to be coming from, so for specific use cases the higher layers don't need to challenge the sender to prove who it is.

Some of this code can be found at: https://github.com/linkedin/dmarc-msys/

This is mainly for internal use.

---

From: Terry Zink <[email-masked]>
Date: Tue, 15 Mar 2016 20:04:52 +0000

+1 to virtual DMARC, -1 to the arguments against it.

Office 365 already supports something like this for our customers to cut down on Business Email Compromise. Maybe 5% of our customers have DMARC records, yet we treat all inbound email destined to them as having p=quarantine and then we figure out roughly who is allowed to send email as them even when (especially when) they don't authenticate. I talk about this here: http://aka.ms/AntispoofingInOffice365.

We've been doing DMARC lookups on the header.from and stamping the result for a while now, and if it doesn't publish DMARC but would have passed if it did, we stamp the result and call it "Best Guess Pass". However, we use relaxed alignment, not strict. I talk about this here: http://blogs.msdn.com/b/tzink/archive/2015/05/06/what-is-dmarc-bestguesspass-in-office-365.aspx

Figuring out implicit/virtual DMARC for everyone else is a much bigger body of water to boil, but is roughly the same problem. As a large receiver we have overrides for DMARC failures anyway, so implicit/virtual DMARC would have those same overrides.

> Firstly, DMARC is an opt-in protocol for good reason.

I'm saying this tongue-in-cheek, but that "good reason" is "very limited deployment in practice." If we would have waited for customers to publish DMARC records we'd be at 6% adoption rate.

> In your first phase, p=none, this will have no effect. In your middle phase, 
> p=quarantine, this will cause massive loss of wanted email ...  In your
> final phase, p=reject, there will continue to be massive loss of wanted email.

If large email receivers start junking messages because of implicit/virtual DMARC failures, senders figure it out eventually even without DMARC reporting. There's more tools in our toolbox than just junking. For example, we can add visual warnings to the message. We can choose not to extract/promote content if the header.from doesn't align with the SPF/DKIM domain (i.e., an airline sends a flight confirmation and that info is not shown to the user in a rich manner). We can add throttling limits. And so forth.

-- Terry

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Steve Atkins
Sent: Tuesday, March 15, 2016 5:33 AM
To: dmarc
Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt

Cheers,
  Steve

_______________________________________________
dmarc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmarc

---

From: Franck Martin <[email-masked]>
Date: Tue, 15 Mar 2016 16:06:42 -0500 (CDT)

----- Original Message -----
> From: "Terry Zink" <[email-masked]>
> To: "dmarc" <[email-masked]>
> Sent: Tuesday, March 15, 2016 1:04:52 PM
> Office 365 already supports something like this for our customers to cut down
> on Business Email Compromise. Maybe 5% of our customers have DMARC records,
> yet we treat all inbound email destined to them as having p=quarantine and
> then we figure out roughly who is allowed to send email as them even when
> (especially when) they don't authenticate. I talk about this here:
> http://aka.ms/AntispoofingInOffice365.
> 
> We've been doing DMARC lookups on the header.from and stamping the result for
> a while now, and if it doesn't publish DMARC but would have passed if it
> did, we stamp the result and call it "Best Guess Pass". However, we use
> relaxed alignment, not strict. I talk about this here:
> http://blogs.msdn.com/b/tzink/archive/2015/05/06/what-is-dmarc-bestguesspass-in-office-365.aspx
> 
> Figuring out implicit/virtual DMARC for everyone else is a much bigger body
> of water to boil, but is roughly the same problem. As a large receiver we
> have overrides for DMARC failures anyway, so implicit/virtual DMARC would
> have those same overrides.
> 
> I'm saying this tongue-in-cheek, but that "good reason" is "very limited
> deployment in practice." If we would have waited for customers to publish
> DMARC records we'd be at 6% adoption rate.
> 
> If large email receivers start junking messages because of implicit/virtual
> DMARC failures, senders figure it out eventually even without DMARC
> reporting. There's more tools in our toolbox than just junking. For example,
> we can add visual warnings to the message. We can choose not to
> extract/promote content if the header.from doesn't align with the SPF/DKIM
> domain (i.e., an airline sends a flight confirmation and that info is not
> shown to the user in a rich manner). We can add throttling limits. And so
> forth.
> 

Yes, it may not be cool to call it Virtual DMARC, but basically it is applying the DMARC logic, to pass information to other layers.

Google has been doing virtual SPF (aka best guess SPF) for a while. The name is confusing, and mixing the results of two systems may produce non-comparable metrics.

I think the point, is that several of us have been doing this for quite a while and this has been useful in our own internal networks, I'm not sure it needs to be formalized to the rest of Internet, except may be under informational status or under a (B)CP.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 15 Mar 2016 23:10:36 +0100

> I think the point, is that several of us have been doing this for quite a while and this has been useful in our own internal networks, I'm not sure it needs to be formalized to the rest of Internet…

the fact that a number of big receivers already deploy similar 
techniques doesn't mean this draft is a good idea:

  * big receivers do have the resources to maintain and extend a rich
    toolbox to 'balance' the results of a DMARC analysis. There are
    however huge numbers of small to medium receivers who do not have
    this tooling and for whom a virtual/best guess DMARC 'mechanism'
    might remove the nuances there can be in the outcome of a spam
    analysis of real world mail;
  * suppose this draft would evolve into a BCP or Informational RFC, who
    will decide when to move from p=none to p=quarantine and from
    p=quarantine to p=reject, and on what criteria would such a decision
    be based?
  * like Kurt already said, associating this with the name of 'DMARC'
    doesn't sound the right thing to do.

/rolf

---

From: Franck Martin <[email-masked]>
Date: Tue, 15 Mar 2016 18:09:32 -0500 (CDT)

----- Original Message -----

> From: "Rolf E. Sonneveld" <[email-masked]>
> To: "Franck Martin" <[email-masked]>, "Terry Zink"
> <[email-masked]>
> Cc: "dmarc" <[email-masked]>
> Sent: Tuesday, March 15, 2016 3:10:36 PM
> Subject: Re: [dmarc-ietf] I-D Action:
> draft-akagiri-dmarc-virtual-verification-00.txt

> the fact that a number of big receivers already deploy similar techniques
> doesn't mean this draft is a good idea:

> * big receivers do have the resources to maintain and extend a rich toolbox
> to 'balance' the results of a DMARC analysis. There are however huge numbers
> of small to medium receivers who do not have this tooling and for whom a
> virtual/best guess DMARC 'mechanism' might remove the nuances there can be
> in the outcome of a spam analysis of real world mail;
> * suppose this draft would evolve into a BCP or Informational RFC, who will
> decide when to move from p=none to p=quarantine and from p=quarantine to
> p=reject, and on what criteria would such a decision be based?
> * like Kurt already said, associating this with the name of 'DMARC' doesn't
> sound the right thing to do.

1) Small receivers use community toolboxes, like spamassassin, I don't see where is the problem. Even, often, big receivers contribute to community toolboxes... 
2) you are confusing applying a policy and getting an authentication flag for other layers 
3) yes, I'm not keen either to call it DMARCX to avoid confusion, but DMARC is just a block and anyone can add other blocks to this construction.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 15 Mar 2016 19:46:35 -0400

On Tuesday, March 15, 2016 04:06:42 PM Franck Martin wrote:
> > Office 365 already supports something like this for our customers to cut
> > down on Business Email Compromise. Maybe 5% of our customers have DMARC
> > records, yet we treat all inbound email destined to them as having
> > p=quarantine and then we figure out roughly who is allowed to send email
> > as them even when (especially when) they don't authenticate. I talk about
> > this here: http://aka.ms/AntispoofingInOffice365.
> > 
> > We've been doing DMARC lookups on the header.from and stamping the result
> > for a while now, and if it doesn't publish DMARC but would have passed if
> > it did, we stamp the result and call it "Best Guess Pass". However, we
> > use relaxed alignment, not strict. I talk about this here:
> > reporting. There's more tools in our toolbox than just junking. For
> > example, we can add visual warnings to the message. We can choose not to
> Yes, it may not be cool to call it Virtual DMARC, but basically it is
> applying the DMARC logic, to pass information to other layers.
> 
> Google has been doing virtual SPF (aka best guess SPF) for a while. The name
> is confusing, and mixing the results of two systems may produce
> non-comparable metrics.
> 
> I think the point, is that several of us have been doing this for quite a
> while and this has been useful in our own internal networks, I'm not sure
> it needs to be formalized to the rest of Internet, except may be under
> informational status or under a (B)CP.

SPF Best Guess is a horrible idea that should never have been invented and 
should die as soon as possible.

http://www.openspf.org/FAQ/Best_guess_record

SPF (and DMARC) are opt-in protocols.  Trying to infer DMARC like things about 
non-participants in DMARC is just wrong.  It is not an accident that SPF Best 
Guess apperas nowhere in RFC 4408 nor RFC 7208.  It shouldn't be a model for 
anything.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 15 Mar 2016 20:18:49 -0400

It also cuts down on legitimate mail that users get sent.  Probably 90% of the 
email I send fails DMARC even though I have SPF set up and DKIM sign 
everything because it tends to go via lists that have not adapted to the world 
of DMARC.

I did publish a p=None DMARC record, so presumably I don't personally need to 
care about this, but typically small senders don't pay a huge amount of 
attention to things like new email authentication technologies.

Based on your blog post, I see you're only using this for positive assertions.  
That's something which, as a receiver, I think you are certainly free to do, 
but it's not something that should be standardized.  Since it's strictly an 
internal processing issue, there's no need to put this in an RFC and lots of 
reason not to.

Scott K

On Tuesday, March 15, 2016 08:04:52 PM Terry Zink wrote:
> p=quarantine and then we figure out roughly who is allowed to send email as
> them even when (especially when) they don't authenticate. I talk about this
> here: http://aka.ms/AntispoofingInOffice365.
> 
> it did, we stamp the result and call it "Best Guess Pass". However, we use
> > In your first phase, p=none, this will have no effect. In your middle
> > phase, p=quarantine, this will cause massive loss of wanted email ...  In
> > your final phase, p=reject, there will continue to be massive loss of
> > wanted email.
> clean up all the mail streams for a domain such that all email is
> authenticated. In many cases it is impossible to do so. Those domains that
> have not done so should not publish a DMARC record.
> 
> Requiring DMARC-esque authentication (let alone strict alignment) from
> domains that are not ready to use DMARC will cause a lot of wanted email to
> be treated as having failed that test.
> 
> In your first phase, p=none, this will have no effect. The value of using
> p=none in DMARC is so that domains can take advantage of DMARC reporting
> without loss of legitimate email. You have no reporting, so this provides
> no value.
> 
> In your middle phase, p=quarantine, this will cause massive loss of wanted
> email while still providing no feedback to senders.
> 
> In none of those phases does your draft add any value. If a receiver wants
> to pay attention to whether mail is authenticated or not it can already do
> so, and it can do so much more effectively than any approach that requires
> strict DMARC style alignment.
> 
> Cheers,
>   Steve
>

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 17 Mar 2016 17:50:07 +0900

> +1 to virtual DMARC, -1 to the arguments against it.

How quickly we forget!

 > Figuring out implicit/virtual DMARC

Semantically, it's only partly "implicit" and hardly virtual at all.
A more accurate description is "mandatory/punitive".

 > for everyone else is a much bigger body of water to boil,

Sure it's big, but Yahoo! and AOL are big too, and they already boiled
the pot right down to the residual salt in April 2014.  This I-D just
mandates the same disaster again.

 > There's more tools in our toolbox than just junking.

But a mandatory implicit p=reject means all those tools become non-
conforming if this I-D is standardized.  That's a bad thing.  You can
already "opt in" to using From alignment in your site's filtering and
reputational systems.  *You* don't need more than that.  So the only
value in this I-D is punishing non-participants in DMARC.

"Mailing Lists object strenuously."

On the other hand, the cool freemail services were *already* treating
"p=reject" as advisory *before* April 2014 (at least according to some
Google posters).  AFAICS, this would *force* much of the world to do
the same thing, despite the earlier experience.  Google's behavior is
justifiable in view of the "unexpected" use of p=reject by AOL and
Yahoo! to combat spam based on leaked personal information, but now we
know better.  Embedding mandatory implicit p=reject in a new RFC is
just saying "non-conformance is conformance".  I certainly don't plan
to *ever* administer a site that doesn't implement exceptions for AOL
and Yahoo!'s p=reject policies, and I'll happily extend those
exceptions to any p=reject sites that are sources of non-transactional
mail flows to my users.

I cannot see that as a good thing, but without an eventual mandatory
p=reject, the whole I-D is pointless.

A big fat -1.

Steve