Rakuten, Inc.

takehito.akagiri@mail.rakuten.com

Lepidum Co. Ltd.

maeda@lepidum.co.jp

Lepidum Co. Ltd.

okd@lepidum.co.jp

Lepidum Co. Ltd.

hayashi@lepidum.co.jp

NIFTY Corporation

kase.masaki@nifty.co.jp

Application and Real Time Internet-Draft Mail Divide Framework (MDF) is a recipient driven partitioning framework for E-Mail delivery. A protocol to divide mail delivery at the source of the message is defined in this draft. A mechanism called Reputation Service Provider is also introduced so that a third-party authority can assure senders’ trust. With MDF, subdomaining is used for category-specific MTA designation. Senders decide which category the outgoing mail belongs. It then looks up DNS TXT record to find whether the recipient advertises a specific server for that category. The specified server puts the received mail into a corresponding per-category inbox for the user.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described .

A recipient driven partitioning framework for E-Mail delivery. Receivers advertise that it prepares a separate delivery path, or receiving MTA, for a specific category of mail messages. MDF provides a mechanism to advertise and lookup category specific settings, and evaluate conformance of senders via RSPs.

The intended purpose of each mail message, such as communication, notification, etc. MDF requires that the definition of a Mail Category is agreed upon among senders, receivers, and RSPs.

Reputation Service Provider keeps track of a white list of MDF-conforming senders. Receiving party can perform a query to see how a specific sender is conforming to MDF.

A DNS TXT resource record that advertises receiver’s trust policy. DIVIDE record specifies that a mail message under a category is received by a specific subdomain.

ABNF (Augmented Backus-Naur Form) ABNF is defined in , as are the tokens “ALPHA”, “DIGIT”, and “SP” (space). The tokens “Local-part”, “Domain”, “address-literal” and “Mailbox” are defined in . “dot-atom”, “quoted-string”, “comment”, “CFWS” (comment folded white space), “FWS” (folded white space), and “CRLF” (carriage-return/ line-feed) are defined in .

This document is concerned with message delivery and handling. The following agents are defined in : Message Submission Agent (MSA) Message Transfer Agent (MTA) Message User Agent (MUA) Message Delivery Agent (MDA) receives messages and put them into users’ mailbox. (non-normative reference )

Current E-Mail traffic is flooded with Unsolicited Bulk E-Mail (UBE, aka spam). Traditional approaches against them were detecting and filtering them out from the network and user inboxes. In this document, another approach is presented. Instead of removing SPAM from the mail delivery network, we introduce a new partitioned delivery network for messages that are not SPAM. It is possible to categorize E-Mail messages by their purposes. For example, communication messages usually expect replies. Typical communication messages thus show bi-directional exchange between peers. On the other hand, notification messages such as order confirmations or development activity updates are uni-directional. E-Mail traffic in each categories may show different characteristics. For example, communication messages have problems like outbound bulk messages from a compromised account. Notification messages have risks of sender spoofing and phishing. Therefore, E-Mail abuse can be efficiently detected and filtered out if we have a different message delivery path per category. This document defines a protocol by which domain owners may assign separate MTAs for each category of mail. This is done by subdomaining the receiving domain, while keeping the Local-part of the recipient. Subdomaining have an advantage that the separation can happen in transport layer. This effectively separates mail delivery paths at the source of the messages, as if a drainage divide does for water. Compliant domain holders publish DIVIDE records that specify a subdomain for each mail category that it is willing to receive. DIVIDE records are defined as DNS TXT Resource Records similar to SPF records. Compliant mail senders use the published DIVIDE records to find the destination MTA according to the category of the mail being sent. Receiver also specifies which method is used to authenticate the sender: DMARC , DKIM , SenderID , PRF , or SPF . To make this framework effective, senders must label outgoing messages with correct categories. Senders that abusively categorize messages should be detected and removed from the network. A mechanism called Reputation Service Provider is also introduced so that a third-party authority can assure senders’ trust. This enables per-category white-listing at the receivers’ desired level of strictness. MDF provides the following advantages: a separate message delivery network per message category a separate message inbox per message category trust-based messaging receivers may advertise preferred sender authentication mechanism per category reputation based sender white-listing senders pay for trust, not receivers

Figure 1 shows the overview of a mail transmission with Mail Divide Framework. In this figure, solid lines indicate the flow of a message. Double lines indicate communications other than message deliveries (DNS queries, reputation queries over HTTPS).

Receiver side . beta.example.com . alpha.example.org . . c.beta.example.com . +-------+ (4) Reputation rsp.example.org (3) Add subdomain . | | Query +------------+ and transmit +-------> MTA +=================> Reputation | RCPT: bob@c.beta.example.com | +------+ | Service | | . +-------+ | | Provider | | . | +------------+ | . | (5) Add Authentication- | . | Results Header (1) | . beta.example.com | Submit +-------+ | . +-------+ | +-------+ +----+ | MSA/ | | . | | | | | |User+----> MTA +--+ . | MTA | +--> MDA | +----+ | | . | | | | +---++--+ . +--++---+ +---+---+ || . || | (2) Lookup || . || | (7) Read MDF || . || (0) Advertise | +-----+ +----+ || . || Receiver | |Inbox| +->User| || . +--vv---+ Policy | +-----+ | +----+ || . | | | | +==============> DNS | | +-----+ | . | | +-->Comm +--+ . +-------+ +-----+ _divide.beta.example.com (6) Store in category specific inbox ]]>

Step (0): the receiver advertises its divide path per category with a DIVIDE record. Administrator of the mail-receiving domain designs per-category path partition. For example, “beta.example.com” separates communication and notification to “c.beta.example.com” and “n.beta.example.com”, respectively. All other categories should go to “beta.example.com”. “beta.example.com” builds a DNS TXT Resource Record to express these, as described in . It puts the record in its DNS under “_divide.beta.example.com”.

The “rsp=” part specifies an RSP associated for each category. Sender’s reputation should be managed by this RSP so that the receiver can decide whether it trusts the sender.

Step (1): a user submits a mail message. MUA/MSA assigns a category to the message according to the context. If the user is a notification sender system, assign “notification”. If the user is a human and the message is a reply, assign “communication”. For example, when “alice@alpha.example.org” sends a communication message to “bob@beta.example.com”, the MSA of “alice@alpha.example.org” assigns “communication” to the message.

Step (2): Sender’s MTA looks up MDF policy of the recipient domain. The final MTA in “alpha.example.org” is going to transmit the message to “beta.example.com”. It first looks up DNS under “_divide.beta.example.com” and finds a DNS TXT Resource Record with “v=DIVIDE1”. It now knows that beta.example.com uses Mail Divide Framework.

Step (3): Set destination to the divided mail server. The record has entries for “p=comm:c” and “p=notif:n”. This specifies messages in category “communication” should be sent to recipient’s subdomain “c”, namely, “c.beta.example.com”; similarly category “notification” to “n.beta.example.com”. Since the message from alice to bob has the category “communication”, sender’s MTA SHOULD choose “c” as target subdomain. It creates a new envelope RCPT address (as defined in ) “bob@c.beta.example.com”. Note that the header To: (as defined in ) MUST stay intact.

Now the mail is sent from “alpha.example.org” to “c.beta.example.com”. This is done with ordinary mail transfer protocol, SMTP . The sender’s MTA authenticates itself with DMARC, in this example, according to the DIVIDE record specifies.

When “c.beta.example.com” receives the mail, it verifies the sender’s identity and reputation. The result of the verification is added to the message as Authentication-Results header.

Sender’s identity is verified by DMARC, DKIM, SPF, etc. according to the authentication method specified in the DIVIDE record.

Step (4): Reputation Lookup The recipient MTA “c.beta.example.com” is specifically configured to receive messages that are categorized as “communication” according to MDF. It should verify whether the sender complies with MDF, i.e. not sending spam mail under a category label “communication”. The recipient MTA makes a query to a reputation server as defined in Repute protocol . New assertion-types are introduced to specify MDF mail categories. If the obtained reputation rate is acceptable, the recipient MTA continue processing the message. Otherwise it should reject the message and return a 5xx status.

Step (5): Add Headers and revert RCPT At this point, the receiver MTA has verified that the sender conforms to MDF. The mail message is transmitted to the MDA with an Authentication-Results header, which is defined in . MDF specific parameters are added to the Authentication-Results header.

Upon forwarding the mail message to the MDA, the receiver MTA MAY remove the category subdomain from the envelope RCPT. This reverts the final recipient to “bob@beta.example.com”.

Step (6): Put the message into a specific inbox for the category MDA looks at Authentication-Results header of the mail message and will find “divide=pass” field that indicates this mail has been transported via MDF-conformed partitioned delivery path. The MDA puts the message into a separate inbox for the user. In this example, it is “Comm” folder in the user bob’s IMAP server.

Step (7): Find the mail as partitioned The user reads the newly received mail in the “Comm” folder. The MUA looks at the Authentication-Results header to know this is a partitioned mail. It displays a prominent sign to the user that the sender is trusted.

For the purpose of MDF, mail messages are categorized into the following types: Category Label Description communication comm A message intended to become a part of a bidirectional conversation. transaction trans A message regarding money transaction/purchase confirmation. notification notif An one-way message to report an event. No reply is usually expected. promotion promo An advertisement message. mailing-list ml A message delivered from a mailing-list server to the members of that list. multi-hop mh A message is delivered through multi-hop path. default default Fallback category when none of the above is applicable, or specified. In MDF, the definition of a category SHOULD be agreed upon among senders, receivers, and RSPs so that the reputation feedback works well. DIVIDE records express the receiver’s view what categories of message it is willing to receive by separate servers. Each category is advertised in the DIVIDE record with corresponding label. The sender decides whether the mail message to be sent falls into any of the receiver-designated categories. If a category is found suitable to describe the message, it is used for subdomaining the recipient address. “default” category is used as a fallback. When the message category is “communication” and the sender does not advertise “p=comm” in the DIVIDE record, the sender looks for “p=default”. If an entry corresponding “default” is found, it is used. Otherwise, the message is sent without MDF. Mail Category for a message MAY be decided by user-interaction, by MSA’s context analysis, or by other means. For example, when an outgoing MTA is configured specifically for notification, it can use “notification” for all messages. “mailing-list” and “multi-hop” do not describe the contents of a message. These instead correspond to delivery mechanisms. See sections and for details.

Domain administrators declare DIVIDE specific DNS TXT records to specify DIVIDE configurations similar to SPF and DMARC. Henceforward, we call this TXT records as “DIVIDE records” in this document. We will show the details of the DIVIDE record in this section.

A DIVIDE record is a DNS record that declares separated receiving servers for each Mail Categories, together with sender authentication policy and RSPs. A DIVIDE record is declared to the “_divide” subdomain of target domains. The MSAs in the mail source domains query the TXT records for the mail destination domains to obtain the appropriate subdomains to deliver the mail messages. For example, if the destination domain of a mail message is “example.com”, the MSA located inside the source domain of the message make a query to find the TXT record for “_divide.example.com”. The generic formats of DIVIDE records are:

Multiple parts separated with semicolons compose the “divide specific text”. These parts are called “Entry” in this document. Each Entry has several tags detailed in the following part of this section. Amongst each Entry in a DIVIDE record, the first Entry MUST be the one containing only a v (Version) tag. Currently, the only available value for the v tags is DIVIDE1. The table below shows tag parameters of a DIVIDE Entry. Every tag in this table is mandatory for each DIVIDE Entry. Tag Format Value Notes a a=XXX SPF, PRA, SenderID, DKIM, DMARC to declare the authentication method p p=XXX:YYY XXX=comm, trans, notif, promo, ml, mh, default bind DIVIDE category and mail destination subdomains.     YYY=”subdomain name to be added”, or “none” “none” to specify no subdomaining. rsp rsp=XXX FQDN or IP address of an RSP specify an RSP for this DIVIDE entry. Note that a DIVIDE record does not cover subdomains under the declared domain. For example, when an operator desires to add a DIVIDE record for “_divide.a.example.com.” in addition to the one for “_divide.example.com.”, the operator MUST add a new record for “_divide.a.example.com.”.

Operators MUST NOT declare more than one DIVIDE record for each (sub) domain.

As discussed in section 3.4 of , a DIVIDE record size SHOULD be small enough to fit in a single UDP packet of a DNS answer. When a DNS answer data size becomes greater than 512 octets, old DNS server implementations might fallback to TCP. The fallbacks may cause the performance degradations to the DNS answer procedures. In , it is recommended to adjust the length of the DNS name and the TXT record bound to it SHOULD be under 450 octets. The DIVIDE records SHOULD follow this guideline.

Reputation Service Provider keeps track of a white list of MDF-conforming senders. Receiving party can perform a query to see how a specific sender is conforming to MDF. Reputation reporting architecture is adopted in MDF.

MDF’s effectiveness depends on whether the senders correctly label mail messages for the purpose of DIVIDE record lookup and selecting the receiving servers. If an abusive server sends SPAM messages to “c.beta.example.com”, the advantage of the traffic separation is diluted. When a sender labels a message as “communication”, the degree of how this labeling is correct is evaluated and accumulated as a reputation of this sender for the category “communication”. An RSP maintain reputation for sending domains associated with a set of Mail Categories. When a sending party is not known to the RSP that the recipient trusts, the sender SHOULD NOT be treated as MDF-conforming in the message handling. This is to prevent abusive senders from sending messages to MDF specific inboxes, by always using a new name and expect that a bad reputation would not be built in the RSP. After looking up the DIVIDE record, the sending MTA SHOULD check whether it has already registered itself to the RSP specified by the recipient. If it has not, it SHOULD fall back to non-MDF mail delivery. In the meantime it registers itself to the specified RSP. Once it is recognized as MDF-conforming by the RSP, it can use MDF for the message delivery. Methods to register a sender to an RSP are beyond the scope of this document. Note that a receiver MAY specify itself as the RSP. In that case, MDF is applied only by an explicit consent between the sender and the receiver.

Receiving MTA can make a reputation query for the sender domain for the category of the received message, to the RSP that it trust. The query can be performed as defined in . defines a URL template for a query as follows:

For the purpose of MDF, the application context “email-divide” is used. Mail Category is used for assertion. The query result can be cached according to “expires” field in the response, as described in Section 5 in . An “https” URL with an HTTP over TLS transport SHOULD be used for privacy reasons. See .

Abuse or improper categorization of received message SHOULD be reported to RSPs. ARF format can be used for this purpose. Methods of evaluating how the received message is correctly labeled for the Mail Category are beyond the scope of this document.

When the receiver MTA verified the sender is MDF-conforming, it generates an Authentication-Results header . The header is added as the message is transmitted to the MDA. MDA looks at Authentication-Results header of the mail message and see whether the message is delivered via MDF partitioned delivery network. The MDA puts the message into a separate inbox for the user. The MUA identify the Authentication-Results header and make prominent sign on the display that the mail is delivered via MDF and verified its trust. For example, it MAY display a green icon to show that the mail message is verified in MDF.

Mailing-list servers reformat the posted message and deliver it to list members. SPF can be used to authenticate the resending sender. Mail Category “ml” is reserved for this purpose, to accommodate a specifically configured authentication policy. Receiving server can advertise a separate RSP that is used for mailing-list senders than for communication. For example the following DIVIDE Entry declares the mailing-list servers MUST authenticate itself with SPF and the trust is managed by “ml.repute.example.org”.

Mail Category “multi_hop” is reserved so that the recipient can express a policy for multi-hop messages. For example, “a=spf p=multi_hop:mh” expresses that the receiving server rejects multi-hop messages. “a=dkim p=multi_hop:mh” expresses it accepts multi-hop messages only if DKIM authentication is used.

[TBD] Use DNSSEC if necessary.

Sender MTA looks up a DIVIDE record under the subdomain “_divide” of the recipient domain. Watching for DNS queries can reveal that the sender is going to use MDF for the following outgoing mail. However, a “_divide” query does not reveal which category is in question. After a successful DIVIDE lookup, the sender looks up the recipient subdomain’s MX records. When MDF is in use, the domain depends on the category of the mail. This indicates that watching on MX queries can reveal the category of the mail that the sender is going to transmit. This is inevitable unless DNS queries are encrypted. A BoF on this topic was held in IETF-89, Encryption of DNS requests for confidentiality (dnse). Future works from that group can mitigate this risk.

Queries for reputation server is performed according to . defines HTTP based query and optionally HTTPS can be used. When a recipient MTA receives a mail for a category subdomain, it does a query to the corresponding reputation server. The query indicates the category of the mail in question in the “{assertion}” part of the URL. Thus there is a risk that the category can be observed by watching the traffic between sender and the receiver, combined with reputation queries. To mitigate this risk, reputation query SHOULD be performed over HTTPS (HTTP over TLS), for the purpose of MDF.

Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. Internet mail suffers from the fact that much unwanted mail is sent using spoofed addresses -- "spoofed" in this case means that the address is used without the permission of the domain owner. This document describes a family of tests by which SMTP servers can determine whether an e-mail address in a received message was used with the permission of the owner of the domain contained in that e-mail address. This memo defines an Experimental Protocol for the Internet community. This document defines an algorithm by which, given an e-mail message, one can extract the identity of the party that appears to have most proximately caused that message to be delivered. This identity is called the Purported Responsible Address (PRA).This memo defines an Experimental Protocol for the Internet community. Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization.</t><t> This document obsoletes RFC 4408. This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.</t><t> Message relay is unaffected, and continues to use SMTP over port 25.</t><t> When conforming to this document, message submission uses the protocol specified here, normally over port 587.</t><t> This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. [STANDARDS-TRACK] Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK] Qualcomm Incorporated

5775 Morehouse Drive San Diego CA 92121-1714 US +1 858 651 4478 presnick@qualcomm.com http://www.qualcomm.com/~presnick/

This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. This document updates RFC 7001 by creating a registry for property types in the Authentication-Results header field, used in email authentication work, rather than limiting participants to using the original, small set of fixed values. Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling.</t><t> Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse.</t><t> DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection. This document describes a general architecture for a reputation-based service, allowing one to request reputation-related data over the Internet, where "reputation" refers to predictions or expectations about an entity or an identifier such as a domain name. The document roughly follows the recommendations of RFC 4101 for describing a protocol model. This document defines the format of reputation response data ("reputons"), the media type for packaging it, and definition of a registry for the names of reputation applications and response sets. This document defines a mechanism to conduct queries for reputation information over the HyperText Transfer Protocol (HTTP) using JavaScript Object Notation (JSON) as the payload meta-format. DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature.</t><t> This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. This memo provides information for the Internet community. This document defines a response set for describing assertions a reputation service provider can make about email identifiers, for use in generating reputons. RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This applicability statement describes common methods for utilizing this format for reporting both abuse and authentication failure events. Mailbox Providers of any size, mail-sending entities, and end users can use these methods as a basis to create procedures that best suit them. Some related optional mechanisms are also discussed. [STANDARDS-TRACK]

The following syntax specification of the DIVIDE record uses ABNF . Terms not defined here are taken from .

[TBD]

[TBD]

[TBD]

[TBD]