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

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 17 Mar 2016 09:52:39 -0700

On Tue, Mar 15, 2016 at 1:04 PM, Terry Zink <[email-masked]>
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.

Having special policies to prevent self-spoofing is, IMO, entirely
different from using domain authentication mechanisms to protect mail
streams from non-self entities. For instance, I've always wondered why
people (try to) use public SPF records as a mechanism to figure out which
mail servers they, themselves, send mail from.

Anti-self-spoofing mechanisms to protect against BEC are important for
hosted email solutions like Office365, but I still question whether general
domain authentication mechanisms like SPF, DKIM, DMARC are the right tools
to use for such purpose.

I also don't see that as a justification for something like this I-D.

--Kurt Andersen

---

From: Franck Martin <[email-masked]>
Date: Thu, 17 Mar 2016 11:58:51 -0500 (CDT)

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

> From: "Kurt Andersen (b)" <[email-masked]>
> To: "Terry Zink" <[email-masked]>
> Cc: "dmarc" <[email-masked]>
> Sent: Thursday, March 17, 2016 9:52:39 AM
> Subject: Re: [dmarc-ietf] I-D Action:
> draft-akagiri-dmarc-virtual-verification-00.txt

> On Tue, Mar 15, 2016 at 1:04 PM, Terry Zink < [email-masked] >
> wrote:

> > 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 .
> 
> Having special policies to prevent self-spoofing is, IMO, entirely different
> from using domain authentication mechanisms to protect mail streams from
> non-self entities. For instance, I've always wondered why people (try to)
> use public SPF records as a mechanism to figure out which mail servers they,
> themselves, send mail from.

> Anti-self-spoofing mechanisms to protect against BEC are important for hosted
> email solutions like Office365, but I still question whether general domain
> authentication mechanisms like SPF, DKIM, DMARC are the right tools to use
> for such purpose.

> I also don't see that as a justification for something like this I-D.

Yes, it should not be normative, documented is fine. I prefer documented than part of the secret sauce... 

I'm more concerned that the implementation at Microsoft does not reject the message when p=reject but move the email to the spam folder (with all payloads disabled, etc...) treating p=nil (no policy) may seem for someone outside about the same than for p=none|quarantine|reject.

---

From: Terry Zink <[email-masked]>
Date: Thu, 17 Mar 2016 22:23:20 +0000

> I'm more concerned that the implementation at Microsoft does not
> reject the message when p=reject but move the email to the spam
> folder (with all payloads disabled, etc...)

It’s done this way because it works better for our overall user base than flat-out rejecting the message in SMTP.

---

From: Kouji Okada <[email-masked]>
Date: Fri, 18 Mar 2016 12:17:40 +0900

Thank you very much for your comments.
Here I summarize and answer to the comments.

First of all, I understand there are 3 topics we are discussing on the ML so far.

1. Virtual verification for "p=none" (step 1 on Roadmap)
2. Virtual verification for "p=quarantine and reject" (step 2, 3 on Roadmap)
3. Needs for documentation

----------------------------------------------------------
1. Virtual verification for "p=none" (step 1 on Roadmap)
----------------------------------------------------------
[Points]
- Discussion about step 1 on Roadmap
- We can use PASS without DMARC record
  - If there are no DMARC records for a domain, we can use PASS status.
- Except for “PASS”, we don't need to any changes to DMARC.
  - In case of no DMARC record, the Authentication-results code should be "none". (RFC7489 11.2)

[Comments and Answers]

-
C.1-1 We should not verify the domains not ready for DMARC.
“p=none” has no effect.

A.1-1
Even in the case of “p=none”, we can use the authentication-result of “PASS”.
For example, visual notifications to display the reliabilities of received mails,
or white lists.

Senders not ready for DMARC are not ready for
1. receiving reports
2. negative verification results for the mails they send  ※ except none

I think they are ready to be verified as “PASS”.

Additionally, if DMARC must be opt-in, why does RFC 7489 define the authentication-results code in case of no DMARC record? (See 11.2 of RFC 7489)

About SPF best guess, virtual DMARC verification does not “guess” anything
while SPF Best Guess guesses originated IP addresses.

-----------------------------------------------------------------------------
2. Virtual verification for "p=quarantine and reject" (step 2, 3 on Roadmap)
-----------------------------------------------------------------------------
[points]
- problem of step 2 and 3(p=quarantine or p=reject)
- default rua and ruf in step 2 and 3

[Comments and Answers]

-
C.2-2 In the deployment steps of 2 and 3, they cause massive loss of legitimate mails without reports.

A.2-2
This is our 00 draft and we wrote about what we aim at for the future.
I understand the deployment scenario needs to be discussed more in the DMARC communities,
and we are ready to delete the deployment steps 2 and 3 from the document for now.
Those steps might need more 10 years.

However I think we should look ahead of the deployment after 5 or 10 years.
I understand that the ultimate goal of DMARC is to defend mail users
from malicious activities such as phishing or spoofing.
Concerned with SPF, most of the operators still do not publish the SPF records with “-all”.
When deployment steps 2 or 3 are applied,
the operators who need the feedbacks just have to publish the DMARC records with “ruf” and “rua”.
We could define the default value for those parameters (ruf, rua).

Because security technologies always have difficulties in their deployments,
I think we should make plans for the future deployment.

---------------------------
3. Needs for documentation (and editorial issues)
---------------------------
[Points]
- Do we need standard document?

[Comments and Answers]
C.3-1 It’s an internal processing issue and should not be standardized.

A.3-1
I think we need some informational document
about the procedure to add “DMARC=pass“ in the Authentication-Results
without explicitly published DMARC records.
The document may help operators who are trying to introduce DMARC capability to their MTAs as a current practice.

-
C.3-2 In the last paragraph of Section 3, something may be missed.

A.3-2
I should have written this in the beginning of the paragraph.
This was somehow lost in the editing.

“When a DKIM verification passes utilizing the author domain signatures,”

With this description, does the paragraph make sense?

-
C.3-3 Name.

A.3-3
What would you think is suitable for the name of this verification?
Any suggestions are welcome.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 18 Mar 2016 00:21:31 -0400

On Friday, March 18, 2016 12:17:40 PM Kouji Okada wrote:
> Even in the case of “p=none”, we can use the authentication-result of
> “PASS”. For example, visual notifications to display the reliabilities of
> received mails, or white lists.
> 
> Additionally, if DMARC must be opt-in, why does RFC 7489 define the
> authentication-results code in case of no DMARC record? (See 11.2 of RFC
> 7489)

Because that is how non-participant results are recorded.

> while SPF Best Guess guesses originated IP addresses.

You are guessing that things like identifier alignment that are required to get 
a DMARC like pass are consistently available for a domain that has not opted 
into DMARC.  
> 
> ----------------------------------------------------------------------------
> - 2. Virtual verification for "p=quarantine and reject" (step 2, 3 on
> Roadmap)
> ---------------------------------------------------------------------------
> -- [points]
> I understand the deployment scenario needs to be discussed more in the DMARC
> communities, and we are ready to delete the deployment steps 2 and 3 from
> the document for now. Those steps might need more 10 years.
> 
> Concerned with SPF, most of the operators still do not publish the SPF
> records with “-all”. When deployment steps 2 or 3 are applied,
> the operators who need the feedbacks just have to publish the DMARC records
> with “ruf” and “rua”. We could define the default value for those
> parameters (ruf, rua).

The mail flows associated with feedback reporting can be non-trivial.  It would 
not be appropriate to start providing feedback that is not requested.  A 
default report address would not be appropriate.

If DMARC turns out to be a good idea in the long run, people will adopt it, I 
don't think your steps 2 and 3 will be needed.  If in 5 - 10 years it turns 
out to be needed, then write another draft then.  There's no need to worry 
about it now.  The future is not that predictable.

> I think we should make plans for the future deployment.

What you are proposing is not DMARC since the correct DMARC result for these 
domains is none.  What might be appropriate to standardize, is a name for this 
kind of check so that it can be distinguished between actual DMARC and the 
results associated with your proposal, although I don't particularly see the 
advantage to do so over just including the appropriate SPF or DKIM results.

> Any suggestions are welcome.

I don't have any good ideas about a name, but I do think it's important that 
it be something other than DMARC since it's not done in accordance with the 
DMARC processing.

Scott K

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 18 Mar 2016 16:32:07 +0900

Terry Zink writes:
 > Franck Martin writes:

 > It’s done this way because it works better for our overall user
 > base than flat-out rejecting the message in SMTP.

This has been obvious to mailing lists from the very beginning.  I
understand the rationale for reject in the case of transactional mail
flows, but for that, the p values should have been "unauthorized"
[please reject], "suspicious" [do not deliver normally], and "none"
[no inference or action needed], with the bracketed text being glossed
in the text.  And there should have been language in the RFC making
clear that originating systems are really refusing to authorize mail
flows that fail From alignment, including prospectively (eg, mailing
lists whose processing invalidates DKIM signatures should reject).

@Franck: I'm sorry, I understand why your use case wants "reject" to
mean reject, but it wasn't in the cards given use cases like Yahoo!/
AOL.  Receivers simply were not going to throw away large quantities
of "good" mail their users actually requested, and Mediators weren't
going to stop providing their value-added processing or violate RFCs
for you.  I don't recall you pushing hard for a clear "use only for
transaction flows" clause in the RFC, nobody really did.  Without
that, such mechanisms always find other uses, which make a hard-line
policy untenable for other communities.  Please accept that, and think
instead about the next step.

For example, GNU Mailman is currently working[1] on implementing
Authenticated Received Chain, an I-D with some promise for alleviating
the pain of mailing lists receiving posts from p=reject sites.

Footnotes: 
[1]  Yes, we recognize that this kind of processing is much better
done in the MTA.  However, many mom-and-pop lists don't have control
over their MTA, but do have control over Mailman.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 18 Mar 2016 16:35:07 +0900

Kouji Okada writes:

 > [Comments and Answers]
 > 
 > - C.2-2 In the deployment steps of 2 and 3, they cause massive loss
 > of legitimate mails without reports.
 > 
 > A.2-2

But you seem to ignore what has happened in the past.  To many
receivers (including some of the largest freemail providers as well
some enterprise providers) "p=reject" already means "be careful", not
"reject".[1]  For at least one 800-lb gorilla in the field, since
*before* April 2014.  If you try to make quarantine or reject
mandatory for non-participants, many sites will simply ignore your
protocol, and many others will weaken it as is already done for
explicit policies.

Why do you think they would do otherwise?

 > I understand that the ultimate goal of DMARC is to defend mail
 > users from malicious activities such as phishing or spoofing.

It is.  That doesn't mean it's possible to do so perfectly, and we've
had ample demonstration that the DMARC p=reject protocol is imperfect.
(That doesn't mean it is inherently flawed; it just means that it is
insufficient for perfect protection.)

Earlier in this thread, Franck Martin (who represents the original
DMARC use case of "transactional" mail flows such as banks) wrote "I'm
worried that a large mail provider doesn't reject when the apparent
originator says reject", and Terry Zink (who represents a general
provider of mail services, whose users receive indirect flows
putatively from p=reject sites) replied "that would harm our users,
so we do something different to keep them safe."  Most sites that
don't publish DMARC records just plain don't need them, and would
publish "none" anyway if forced to.  Receivers won't wait for them to
catch up, so Franck will be displeased by the proliferation of sites
that disregard reject in favor of alternative disposition, and Terry
will continue to provide users with exactly those alternatives.

This is already an unpleasant situation, your proposal can't make it
better (unless you can get rid of "p=none", too!), and arguably will
make it worse.

 > The document may help operators who are trying to introduce DMARC
 > capability to their MTAs as a current practice.

If there is no published DMARC record, you're just guessing.  A DMARC
record might be published at any level of para.subsub.sub.domain.tld.
I don't see how you can say that [email-masked] would necessarily
exhibit DMARC From alignment or not, because "Administrative Domain"
is poorly defined.  In DMARC practice it's an heuristic for guessing
where to query for a DMARC record.  This cannot be deduced from the
DKIM signature.

On the other hand, some efforts are being made to come up with an
effective protocol for determining the responsible administrative
domain.  What if they succeed, and disagree with your procedure?  That
would be a mess, and hardly helpful.

Nevertheless, for a receiver with good records of historical mail
flows, appropriate analytical capability, and mail admins who know
what they're doing, "implicit From alignment" might be a useful
variable for their filtering and reputation systems.  Similarly, it
might be a useful factor for spam filtering applications and services
to consider.  Nobody denies that.  The problem is that your I-D trying
to impose behavior on receivers that is not beneficial to their users:
they will Just Say No.

Footnotes: 
[1]  Of course "be careful" is parametrized by domain: for these
receivers, for mail from bankofamerica.com "be careful" means
"reject", while for mail from stanford.edu it means "quarantine" (at
worst).

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 18 Mar 2016 14:17:03 +0000

> -----Original Message-----
> From: dmarc [mailto:[email-masked]] On Behalf Of Stephen J.
> Turnbull
> Sent: Friday, March 18, 2016 3:32 AM
> To: DMARC discussion
> Subject: [!!Mass Mail]Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-
> verification-00.txt
> 
> Terry Zink writes:
>  > Franck Martin writes:
> 
>  > > I'm more concerned that the implementation at Microsoft does not  > >
> reject the message when p=reject but move the email to the spam  > >
> folder (with all payloads disabled, etc...)  >  > It’s done this way because it
> works better for our overall user  > base than flat-out rejecting the message
> in SMTP.
> 
> This has been obvious to mailing lists from the very beginning.  I understand
> the rationale for reject in the case of transactional mail flows, but for that,
> the p values should have been "unauthorized"
> [no inference or action needed], with the bracketed text being glossed in the
> text.  And there should have been language in the RFC making clear that
> originating systems are really refusing to authorize mail flows that fail From
> alignment, including prospectively (eg, mailing lists whose processing
> invalidates DKIM signatures should reject).
> 
> @Franck: I'm sorry, I understand why your use case wants "reject" to mean
> reject, but it wasn't in the cards given use cases like Yahoo!/ AOL.  Receivers
> simply were not going to throw away large quantities of "good" mail their
> users actually requested, and Mediators weren't going to stop providing their
> value-added processing or violate RFCs for you.  I don't recall you pushing
> hard for a clear "use only for transaction flows" clause in the RFC, nobody
> really did.  

My use case are primarily transactional emails but that doesn't mean I object to mailbox providers implementing p=reject on their outbound mail flows. It really comes down to decisions on their part. By the same token, what mailbox providers/validators do on the inbound side falls under local policy. Hopefully ARC will mitigate the issue for intermediaries such as mailing lists (Stay tuned).

>Without that, such mechanisms always find other uses, which
> make a hard-line policy untenable for other communities.  Please accept
> that, and think instead about the next step.
> 

I would suggest that this (overall) be taken as a learning experience  by all of the various constituencies. Collectively we need to find better ways to evolve (for some definition of evolve) and deal with (Abuse) problems. Speaking as someone who is part of the dmarc.org team, I sure learned a lot.

Having said all the above, I am firmly against draft-akagiri-dmarc-virtual-verification-00.txt as from the start, DMARC was intended to be opt-in. Yes there was "collateral damage" from some implementations but that is different than trying to force all senders to implement. If organizations wish to implement this approach as local policy, that is their prerogative. It should not be endorsed  by IETF.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 19 Mar 2016 12:51:38 -0700

On Thu, Mar 17, 2016 at 9:58 AM, Franck Martin <[email-masked]>
wrote:

> ------------------------------
>

Is it important that it be documented in the RFC series?  Best Guess SPF
isn't documented in an RFC as far as I can recall, but you can find it
described on plenty of web pages that turn up in a web search.

-MSK

---

From: Franck Martin <[email-masked]>
Date: Sat, 19 Mar 2016 20:36:51 -0500 (CDT)

Toute connaissance est une réponse à une question.

> On Mar 19, 2016, at 12:51, Murray S. Kucherawy <[email-masked]> wrote:
> 
>> On Thu, Mar 17, 2016 at 9:58 AM, Franck Martin <[email-masked]> wrote:
>> 
> Is it important that it be documented in the RFC series?  Best Guess SPF isn't documented in an RFC as far as I can recall, but you can find it described on plenty of web pages that turn up in a web search.
> 
True and the destruction of earth was clearly advertised in the basement pass the 'beware of the tiger' sign ;)

It all depends if RFC documents all the bits or only the important ones. I don't care either way.

People have been using DMARC authentication as a low security authorization mechanism. Is it worth documenting? I don't know, that may be lot of effort.