Applications Area Working Group T. Akagiri
Internet-Draft
Intended status: Informational G. Yasutaka
Expires: September 15, 2016 Rakuten, Inc.
M. Kase
NIFTY Corporation
K. Okada
K. Maeda
Lepidum Co. Ltd.
March 14, 2016
DMARC verification without record definitions
draft-akagiri-dmarc-virtual-verification-00.txt
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.
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 September 15, 2016.
Copyright Notice
Copyright (c) 2016 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
Akagiri, et al. Expires September 15, 2016 [Page 1]
Internet-Draft DMARC virtual verification March 2016
carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . 2
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
3.2. DMARC verification without DMARC records. . . . . . . . . 3
4. The Virtual DMARC Record . . . . . . . . . . . . . . . . . . 4
5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Security consideration . . . . . . . . . . . . . . . . . . . 5
8. Privacy consideration . . . . . . . . . . . . . . . . . . . . 5
9. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 6
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
11.1. Normative References . . . . . . . . . . . . . . . . . . 6
11.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Although DMARC is an effective technology to protect email users from
malicious activities such as phishings or malwares, at this moment
its deployment seems to require more time. A survey[ReturnPath]
indicates that less than 30% of global top companies have published
DMARC records by the end of 2015. To validate incoming emails
properly on the mail receiving domains, it is desirable for more
domains to declare DMARC records.
In this draft, we propose a default DMARC verification for the
domains that do not declare DMARC records. With this verification,
receivers are able to validate the emails from the domains not
publishing DMARC records. This approach allows MTAs on the mail
receiving domains to validate mail senders utilizing virtual DMARC
records filled with default values, and notify mail end receivers of
the validity of mail senders in the compatible manner with DMARC.
2. Terminology and Definitions
o virtual DMARC record: DMARC records virtually created to verify
domains that do not publish DMARC records
Akagiri, et al. Expires September 15, 2016 [Page 2]
Internet-Draft DMARC virtual verification March 2016
o regular verification: DMARC RFC7489 verification
o virtual verification: verification leveraging virtual DMARC
records
3. Overview
3.1. Problem Statement
As described in Section 1, currently the adoption rate of DMARC
remains low in the mail sender sides. This means that operators of
receiver MTAs are not encouraged to introduce DMARC verifiers to
their MTAs. DMARC needs operations both on sender sides and receiver
sides, that is, mail senders have to publish DMARC TXT records on
their DNS servers, and MTAs on the receiver domains have to enable
the DMARC verification. Thus the deployment of DMARC is a "Chicken-
and-Egg" question between senders and receivers.
We propose a receiver-driven incremental deployment procedure in this
document.
3.2. DMARC verification without DMARC records.
Figure 1 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 1: State Diagram
Akagiri, et al. Expires September 15, 2016 [Page 3]
Internet-Draft DMARC virtual verification March 2016
The Mail receiver SHOULD verify the Mail sender with a virtual DMARC
record when the receiver could not find the DMARC record published by
the Mail sender. The regular DMARC verifier just sets the
Authentication-Results to "none" when the receiving MTA could not
find the DMARC policy records for the sender. In contrast, when the
verification of SPF or DKIM have passed, the virtual verification
validates the sender against the virtual DMARC record, that is filled
with the _default_ values. The content of the virtual DMARC record
is explained in detail in Section 4.
The virtual DMARC verification processes received emails in the same
way the regular DMARC verifier does with those default values. As to
the Authentication-Results field of verified email, "pass" is set to
verified email and "none" to unverified one.
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.
4. The Virtual DMARC Record
When the mail sender does not publish their DMARC record, the virtual
DMARC verification validates the sender against an imaginary DMARC
record that are filled with pre-determined values. This record is
referred to as "virtual DMARC record" in this document.
The values in the virtual DMARC record are listed below(Table 1).
+----------+----------------------------+
| Tag Name | Virtual DMARC Record Value |
+----------+----------------------------+
| p | none |
| | |
| adkim | s(strict) |
| | |
| aspf | s(strict) |
+----------+----------------------------+
Table 1: Values for Virtual DMARC records
These values are determined so that the reasonable verification can
be performed when the sender is not interested in publish their own
DMARC record.
o policy(p): none
Akagiri, et al. Expires September 15, 2016 [Page 4]
Internet-Draft DMARC virtual verification March 2016
* The received emails have to be delivered to mail destinations
unless the mail sender domains publish DMARC records and set
the policy in the records to "quarantine" or "reject". So the
default policy(p) is set to "none".
o adkim, aspf: s(strict)
* The default alignment modes for DKIM and SPF are "s(strict)".
When a hosting provider("example.com"), for instance, enables
DKIM and publish a DKIM resource record for a
customer("aaa.example.com"). In this situation, if the DKIM
alignment mode(adkim) in the virtual record is "r(relaxed)",
another customer("bbb.example.com") can pretend to be
"aaa.example.com". This is not the will of the
"aaa.example.com". To prevent this situation, the alignment
modes (adkim and aspf) are "s(strict)" in the virtual DMARC
record, as opposed to the default value for the regular DMARC
record.
5. Use cases
TBD
6. Roadmap
By promoting DMARC, our final goal is to reject emails from domains
that do not publish DMARC records. To achieve this goal, we propose
a three step deployment.
o Step1: As proposed in this draft, the policy(p) for the virtual
DMARC record is set to "none".
o Step2: The policy(p) is set to "quarantine". A new
Authentication-Result "SoftFail" may be needed to indicate that
the failure is due to the virtual verification.
o Step3: The policy(p) is set to "reject".
7. Security consideration
TBD
8. Privacy consideration
TBD
Akagiri, et al. Expires September 15, 2016 [Page 5]
Internet-Draft DMARC virtual verification March 2016
9. Discussions
o Currently the virtual verification set the Authentication-Result
to "pass" when the verification passes. Is it better to define
"SoftPass" so that it indicates the "pass" is based on the virtual
verification?
o Values "ruf" and "rua" for the virtual record.
10. Acknowledgements
TBD
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>.
[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>.
Akagiri, et al. Expires September 15, 2016 [Page 6]
Internet-Draft DMARC virtual verification March 2016
11.2. Informative References
[ReturnPath]
Return Path, ., "DMARC Intelligence Report", February
2016.
Authors' Addresses
Takehito Akagiri
Email: takehito@akagiri.com
Genki Yasutaka
Rakuten, Inc.
Email: genki.yasutaka@rakuten.com
Masaki Kase
NIFTY Corporation
Email: kase.masaki@nifty.co.jp
Kouji Okada
Lepidum Co. Ltd.
Email: okd@lepidum.co.jp
Kaoru Maeda
Lepidum Co. Ltd.
Email: maeda@lepidum.co.jp
Akagiri, et al. Expires September 15, 2016 [Page 7]