Internet DRAFT - draft-akagiri-dmarc-virtual-verification
draft-akagiri-dmarc-virtual-verification
Applications Area Working Group G. Yasutaka
Internet-Draft Rakuten, Inc.
Intended status: Informational T. Akagiri
Expires: January 29, 2018 Regumi, Inc.
D. Kodama
BIGLOBE Inc.
K. Okada
Lepidum Co. Ltd.
July 28, 2017
DMARC verification without record definitions
draft-akagiri-dmarc-virtual-verification-02.txt
Abstract
While DMARC is a powerful architecture to protect email users from
malicious email activities, its deployment is still a work in
progress. To encourage further adoption of DMARC, in this draft we
propose an incremental deployment procedure.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 29, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Yasutaka, et al. Expires January 29, 2018 [Page 1]
Internet-Draft DMARC virtual verification July 2017
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
3.2. DMARC verification without DMARC records. . . . . . . . . 5
4. The Virtual DMARC Record . . . . . . . . . . . . . . . . . . 6
5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security consideration . . . . . . . . . . . . . . . . . . . 7
7. Privacy consideration . . . . . . . . . . . . . . . . . . . . 7
8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. 01 revision . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Currently, there are several email sender validation technologies
such as SPF and DKIM, which are independent from each other. There
is also a need for email verification frameworks to handle the email
authentication results provided by those validation technologies in a
unified manner. DMARC is one of the technologies that provides such
a capability.
Although DMARC is an effective technology to protect email users from
malicious activities such as phishing or malware, at this moment its
deployment is a work in progress. A survey[ReturnPath] indicates
that by the end of 2015, less than 30% of top global companies have
published DMARC records. To validate incoming emails properly on the
receiving MTA side, it is desirable that more domains publish DMARC
records.
At the same time, the adoption of SPF and DKIM is widespread, and,
especially for email receivers, it is valuable to utilize the
validation results of those technologies. From the view point of
email receivers, the main goals of adopting an email verification
framework are:
Yasutaka, et al. Expires January 29, 2018 [Page 2]
Internet-Draft DMARC virtual verification July 2017
1. To identify malicious emails and apply policies
2. To verify non-malicious emails as authorized
This draft focuses on the second goal.
In this draft, we propose a default verification for domains that do
not declare DMARC resource records. This default verification is
called "virtual verification(s)" in this draft. With virtual
verifications, receivers are able to validate emails from domains not
publishing DMARC records. This approach allows receiving MTAs to
validate email senders by utilizing virtual DNS resource records
populated with default values, and notify email users of the
authenticity of email senders in a manner compatible with DMARC.
2. Terminology and Definitions
o virtual DMARC record: DMARC record virtually created to verify
domains that do not publish DMARC records
o regular verification: DMARC RFC7489 verification
o virtual verification: verification leveraging virtual DMARC
records to verify emails which would potentially be "dmarc=pass"
3. Overview
3.1. Problem Statement
As described in Section 1, currently the adoption rate of DMARC
remains low on the email sender side. This means that operators of
receiver MTAs have little incentive to introduce DMARC verifiers into
their MTAs. DMARC needs implementation on both sender and receiver
sides, i.e. email senders have to publish DMARC TXT records on their
DNS servers, while email receivers have to enable DMARC verification
on their MTAs. Thus, the deployment of DMARC is a chicken-and-egg
problem between email senders and receivers.
There are situations where emails from domains that do not have DMARC
records can be treated as "dmarc=pass". In [RFC7489], the conditions
for adding "dmarc=none" to Authentication-Results are:
1. No DMARC records are defined for email sender domains.
2. DMARC records are defined with "p=none" and DMARC verification
did not pass.
Yasutaka, et al. Expires January 29, 2018 [Page 3]
Internet-Draft DMARC virtual verification July 2017
Out of the conditions above, on the first condition there should be
plenty of emails which would potentially be marked as "dmarc=pass".
Those emails are from domains that have valid SPF records or DKIM
signatures and validated as authorized with SPF or DKIM, while
RFC5322.From fields of the emails are aligned with SPF or DKIM
identifiers.
| | SPF or DKIM |
+----------+--------+---------+
| | Align |Not-Align|
+------+---+--------+---------+
| | | | |
| |Yes| Pass | None(1) |
|DMARC | | |(p=none) |
|Record| | | |
| +---+--------+---------+
| |No |None(2) | None(3) |
+------+---+--------+---------+
Figure 1: DMARC Authentication-Results
Figure 1 illustrates the relationship between verification conditions
and Authentication-Results. There are three conditions where the
Authentication-Results are marked as None via DMARC regular
verification. The first one is the condition where there is a DMARC
record with p tag set to 'none' on a sender domain and the domain is
not aligned with the email RFC5322.From field (None(1) in Figure 1).
The other two conditions are where the sender domains do not declare
DMARC records on their DNS servers. In the first case, None is set
when DKIM or SPF passes and the identifier aligns but no DMARC
records are defined on the sender domain (None(2)). In the second
case, even if valid DMARC records are declared for the sender
domains, regular DMARC verification will fail (None(3)). Regular
DMARC verification treats None(2) and None(3) in Figure 1 as the same
"None", but the authenticity of received emails is different in each
case.
According to an analysis performed by Re:gumi with a Japanese
ISP([RegumiDmarcAnalysys]), the proportion of domains which can be
verified as legitimate by DMARC rises to 41.9% after including the
domains which potentially can be treated as legitimate (None(2)).
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". This approach is
current practice in some email receiver MTAs.
Yasutaka, et al. Expires January 29, 2018 [Page 4]
Internet-Draft DMARC virtual verification July 2017
3.2. DMARC verification without DMARC records.
Figure 2 is the state diagram of the DMARC virtual verification.
+----------+ +-----------+
| SPF Pass | | DKIM Pass |
+----+-----+ +-----+-----+
| |
v v
+----+--------------------+-----+
| DMARC Record exists? |
+-----+-------------------+-----+
Yes v v No
+------+-----+ +-----+------+
| regular | | virtual |
+-----+verification| /|verification|
| +------+-----+ / +-----+------+
v | / |
+----+-----+ v / v
| results | +--+---+ / +---+--+
|other than| | pass +<--+ | none |
| pass | +------+ +------+
+----------+
Figure 2: State Diagram
Email receivers SHOULD verify email senders using virtual DMARC
records when receivers cannot find DMARC records published by the
email senders. The regular DMARC verifier just sets Authentication-
Results to "none" when the receiving MTA cannot find DMARC policy
records for the sender domain. In contrast, when verifications of
SPF or DKIM have passed, the virtual verification validates senders
against virtual DMARC records populated with _default_ values. The
_default_ values of virtual DMARC records are detailed in Section 4.
Virtual DMARC verification processes received emails in the same
manner as the regular DMARC verifier does using those default values.
The Authentication-Result field is set to "dmarc=pass" for email that
passes virtual DMARC verification and to "dmarc=none" for email that
does not.
Inserting "dmarc=pass" into Authentication-Results may cause
controversy. From the point of view of email operators, it is
desirable to differentiate between emails that pass virtual DMARC
verifications and those that pass regular DMARC verification.
However, for end users without enough expertise, simply utilizing
"dmarc=pass" makes it easier to leverage the field.
Yasutaka, et al. Expires January 29, 2018 [Page 5]
Internet-Draft DMARC virtual verification July 2017
4. The Virtual DMARC Record
When a email sender does not publish their DMARC record, the virtual
DMARC verification validates the sender against a virtual DMARC
record populated with pre-determined values. This record is referred
to as "virtual DMARC record" in this draft.
The values in the virtual DMARC record are listed below (Table 1).
+----------+----------------------------+
| Tag Name | Virtual DMARC Record Value |
+----------+----------------------------+
| v | DMARC1 |
| | |
| p | none |
| | |
| adkim | s(strict) |
| | |
| aspf | s(strict) |
+----------+----------------------------+
Table 1: Values for Virtual DMARC records
These values are determined so that reasonable verifications can be
performed when the sender has not published their own DMARC records.
o version(v): DMARC1
* To allow the DMARC verifier to process virtual DMARC records
properly, the version tag must be set as 'DMARC1'.
o policy(p): none
* Received emails must be delivered to email destinations unless
the email sender has published a DMARC record and has set the
policy in the record to "quarantine" or "reject" explicitly.
Therefore, the policy(p) must be set to "none".
o adkim, aspf: s(strict)
* The default alignment modes for DKIM and SPF are "s(strict)".
An example would be when a hosting provider ("example.com")
enables DKIM and publishes a DKIM resource record for a
customer ("aaa.example.com"). In this case, if the DKIM
alignment mode (adkim) in the virtual record is "r(relaxed)",
another customer of the hosting provider ("bbb.example.com")
can pretend to be the owner of "aaa.example.com". To prevent
this, we propose the default alignment modes (adkim and aspf)
Yasutaka, et al. Expires January 29, 2018 [Page 6]
Internet-Draft DMARC virtual verification July 2017
to be "s(strict)" in the virtual DMARC record, as opposed to
the default value for the regular DMARC record.
5. Use cases
Figuring out whether an email is potentially "dmarc=pass" or not
allows email system operators to evaluate the authenticity of the
email sender domain. DMARC evaluates the RFC5322.From, while SPF
evaluates the RFC5321.Mailfrom and DKIM verifies the signature of
email senders. By combining this information, DMARC verification
helps to establish domain authenticity which can be used as domain
reputation or whitelisting of email senders.
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.
6. Security consideration
TBD
7. Privacy consideration
TBD
8. Discussion
o In this draft, we propose to verify the incoming email messages
with the virtual records only in the strict mode. The Office365
verifier, however, verify in the relax mode. Are there any
demands for the interface to configure the verification alignment
modes and the authentication codes marked in the Authentication-
Results?
o Values "ruf" and "rua" for virtual records need to be decided.
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.
o Name of the verification
Yasutaka, et al. Expires January 29, 2018 [Page 7]
Internet-Draft DMARC virtual verification July 2017
9. Acknowledgements
The authors would like to thank engineers at the Japanese ISPs So-
net, NIFTY, Biglobe and CNCI especially Mr. Koichi Abe, Mr. Daisuke
Kodama and Mr. Nickolay Boyadjiev, for their technical advice and
data analysis.
10. Change Log
10.1. 01 revision
o Removed Roadmap section
o Added focus of this document to Introduction and Problem Statement
o Added Use cases section
11. References
11.1. Normative References
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<http://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<http://www.rfc-editor.org/info/rfc5322>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
DOI 10.17487/RFC5598, July 2009,
<http://www.rfc-editor.org/info/rfc5598>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<http://www.rfc-editor.org/info/rfc6376>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<http://www.rfc-editor.org/info/rfc7208>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<http://www.rfc-editor.org/info/rfc7489>.
Yasutaka, et al. Expires January 29, 2018 [Page 8]
Internet-Draft DMARC virtual verification July 2017
[RFC7601] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 7601,
DOI 10.17487/RFC7601, August 2015,
<http://www.rfc-editor.org/info/rfc7601>.
11.2. Informative References
[BestGuessPass]
Zink, T., "What is DMARC BestGuessPass in Office 365?",
n.d., <https://blogs.msdn.microsoft.com/tzink/2015/05/06/
what-is-dmarc-bestguesspass-in-office-365/>.
[RegumiDmarcAnalysys]
"Re:gumi Dmarc Analysis", n.d., <Under Construction>.
[ReturnPath]
Return Path, "DMARC Intelligence Report", February 2016,
<https://returnpath.com/downloads/dmarc-intelligence-
report/>.
Authors' Addresses
Genki Yasutaka
Rakuten, Inc.
Email: genki.yasutaka@rakuten.com
Takehito Akagiri
Regumi, Inc.
Email: akagiri@regumi.net
Daisuke Kodama
BIGLOBE Inc.
Email: d-kodama@biglobe.co.jp
Kouji Okada
Lepidum Co. Ltd.
Email: okd@lepidum.co.jp
Yasutaka, et al. Expires January 29, 2018 [Page 9]