Internet DRAFT - draft-laber-smtp-impt
draft-laber-smtp-impt
Network Working Group M. Laber
Internet-Draft 1&1
Intended status: Experimental September 8, 2014
Expires: March 12, 2015
Inter Mail Provider Trust (IMPT):
Mandatory use of Transport Layer Security (TLS)
with Simple Mail Transfer Protocol (SMTP)
draft-laber-smtp-impt-00
Abstract
This memo describes the protocol called Inter Mail Provider Trust
(IMPT) which ensures that a cryptographically secured communication
channel is always established with Transport Layer Security (TLS)
when delivering messages via Simple Mail Transfer Protocol (SMTP)
between Mail Transfer Agents (MTAs) of pre-registered participants.
Mainly the participants exchange SMTP routing information about their
MTA infrastructure for this purpose.
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 March 12, 2015.
Copyright Notice
Copyright (c) 2014 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
Laber Expires March 12, 2015 [Page 1]
Internet-Draft IMPT September 2014
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Transfer messages . . . . . . . . . . . . . . . . . . . . . . 4
3. List formats . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Participants list . . . . . . . . . . . . . . . . . . . . 5
3.2. MX infrastructure list . . . . . . . . . . . . . . . . . 6
3.3. Value Syntaxes . . . . . . . . . . . . . . . . . . . . . 8
3.3.1. Domain Names . . . . . . . . . . . . . . . . . . . . 8
3.3.2. IP Address Literals . . . . . . . . . . . . . . . . . 8
3.3.3. Timestamps . . . . . . . . . . . . . . . . . . . . . 8
3.3.4. Digital signatures . . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12
A.1. Participants list . . . . . . . . . . . . . . . . . . . . 12
A.2. MX infrastructure list single participant . . . . . . . . 13
A.3. Aggregated MX infrastructure list . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
Most times Transport Layer Security (TLS) is used with Simple Mail
Transfer Protocol (SMTP) in a opportunistic manner which is subject
to possible down-grade attacks as described in [RFC3207], section 6.
This memo describes an approach to strictly mandate that an Mail
Transfer Agent (MTA) of a IMPT participant must use the SMTP
extension STARTTLS [RFC3207] to establish an encrypted connection
channel with TLS 1.2 [RFC5246] when transferring a message via SMTP
to another participant's MTA.
In opposite to other approaches IMPT also ensures that the receiving
MTA knows whether the sender must use TLS or not.
Out-of-band information is exchanged between pre-registered
participants for that purpose which is provided in the form of
optionally digitally signed JSON-based lists via HTTP over TLS
(HTTPS) (see Section 3).
Laber Expires March 12, 2015 [Page 2]
Internet-Draft IMPT September 2014
1.1. Terminology
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 [RFC2119].
The terms Internet Mail, Recipient, Message Transfer Agent (MTA) are
to be interpreted as described in [RFC5598].
Furthermore the following terms are used in this document:
Recipient domain:
Domain part of the [RFC5321] RCPT TO command forward path.
MX record:
DNS resource record which is used to locate the MTA for a
recipient domain as described in [RFC1035], section 3.3.9.
MX hostname:
DNS hostname of the inbound MTA for a recipient domain determined
by rules defined in [RFC5321], section 5.
MX address:
The IP address of the MX hostname determined by looking up the
associated A or AAAA resource records in DNS.
IMPT participant (or only participant):
Organization or individual which is running mail services for own
use or on behalf of others (hosting provider) which are compliant
to the protocol described herein.
JSON object:
JSON object consisting of name/value pairs (or members) as defined
in [RFC7159], section 4.
JSON array:
JSON array as defined in [RFC7159], section 5.
JSON lists:
Different types of JSON formatted lists are defined in Section 3.
1.2. Status
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
Laber Expires March 12, 2015 [Page 3]
Internet-Draft IMPT September 2014
2. Transfer messages
When transferring an Internet Mail message an outbound MTA MUST use
STARTTLS [RFC3207] to establish an encrypted TLS connection if the MX
hostname appears as name of an MTA object in at least one participant
MX infrastructure list (see Section 3.2).
The outbound MTA (TLS client) MUST authenticate itself to the inbound
MTA (TLS server) with a TLS client certificate ([RFC5246], section-
7.4.6) published in its MTA object with <role> "outbound"
Section 3.2, Paragraph 5.
Furthermore, in case of an error occuring while establishing the TLS
connection, the outbound MTA MUST NOT fall back to clear-text
transport. Rather, TLS connection failure MUST be treated like an
temporary SMTP failure and message SHOULD be queued for retrying
transfer later ([RFC5321], section 4.5.4).
The outbound MTA (TLS client) MUST implement the TLS hostname check
as detailed in [RFC6125]. The outbound MTA MUST accept at least the
MX hostname As server identity. It MAY additionally accept the
recipient domain as server identity.
The inbound/receiving MTA (TLS server) MUST check whether the
sender's IP address is found in an MTA object. If the IP address is
found in an MTA object the sender MUST refuse to accept clear-text
(non-TLS) connections from this IP address. Futhermore the inbound/
receiving MTA MUST check whether the client certificate used by the
outbound/sending MTA matches one of the certificates referenced by
value <cert_ref> in the MTA object (Section 3.2, Paragraph 5).
3. List formats
There are three sorts of JSON lists all of which MUST be made
publicly accessible:
Participant list:
Holds contact information and a reference link to MX
infrastructure list of each trusted participant. This list MAY be
stored in a central location but each participant provides a copy
of this list for download which SHOULD be considered local
configuration. The format is specified in Section 3.1.
Participant MX infrastructure list:
Describes own MX infrastructure of a single participant including
all incoming and out-going MTAs for which use of transport
security with TLS is mandatory. It contains host names, IP
Laber Expires March 12, 2015 [Page 4]
Internet-Draft IMPT September 2014
addresses and X.509 client and server certificates actually used
(see Section 3.2).
Aggregated MX infrastructure list:
An MX infrastructure list (Section 3.2) containing the mirrored
JSON MX infrastructure objects of all participants.
The lists are provided for public download via HTTP over TLS (HTTPS)
[RFC2818] in JSON format with character encoding UTF-8 and the web
service MUST send MIME type application/json [RFC7159].
Each participant MUST publish its own participant MX infrastructure
list with path name "mxinfra.json" and an aggregated MX
infrastructure list with path name "mxinfra-all.json". The complete
HTTPS URL for downloading these MX infrastructure lists is composed
by appending the path name to the value <base_url> in the participant
object (Section 3.1, Paragraph 5).
Applications MUST accept object names and values in arrays in
arbitrary order. If an implementation sees any parsing failure or
any data within a JSON list is considered invalid or incomplete the
whole list MUST be considered invalid and MUST NOT be used at all.
The top-level value <format_version> is present in all lists
indicating the version of the list syntax. For now <format_version>
is always set to the JSON number 1.
The top-level value <timestamp> is present in all lists indicating
the creation time of either the whole list file or a nested object as
detailed in Section 3.3.3.
The following sections describe the JSON format of the list files in
detail starting with some general implementation considerations.
3.1. Participants list
This section describes the format of the central participants list.
While downloadable from a central location the participants list is
considered rather a-priori configuration.
Each participant is registered with a so-called IMPT base domain
which MUST be a valid DNS domain registered for the participant.
The IMPT base domain is used in the object <domains> as name for a
single JSON participant object following the rules in Section 3.3.1.
The values in a JSON participant object are as follows:
Laber Expires March 12, 2015 [Page 5]
Internet-Draft IMPT September 2014
contract_date
This value contains the date of the registration contract in
format YYYY-MM-DD as defined in [ISO.8601.1988].
contract_org
Legally bound name of the participant's organization.
base_url
Base URL (HTTPS) with trailing slash "/" for forming URL to
download the MX infrastructure lists from the participant's HTTPS
server.
contact_phone
Public phone number for support requests, abuse notices or similar
in international phone number format as specified in [E.123].
contact_email
Public e-mail address for support requests, abuse notices or
similar in format specified in [RFC5322].
not_before
Timestamp after which this participant is active and implements
all the provisions made in this document. Especially if
<not_before> lies in the future MX infrastructure lists from this
participant are still considered invalid and MUST NOT be used.
The format is specified in Section 3.3.3.
not_after
Timestamp after which this participant is not active anymore.
Especially if <not_after> lies in the past MX infrastructure lists
from this participant are all considered invalid and MUST NOT be
used anymore. The format is specified in Section 3.3.3.
3.2. MX infrastructure list
This section describes the format and usage of the MX infrastructure
list which describes the inbound and outbound MTAs of a participant.
Participants MUST re-new their local copy of all loaded MX
infrastructure lists at least every 15 minutes.
The IMPT base domain names of the participant who generated the list
SHALL be used in the object <domains> as name for a single JSON MX
infrastructure object following the rules in Section 3.3.1. If
<domains> contains a domain name which is not registered in the
participant list the whole MX infrastructure list MUST be rejected as
invalid.
Laber Expires March 12, 2015 [Page 6]
Internet-Draft IMPT September 2014
The values in a JSON MX infrastructure object are as follows:
timestamp
Contains a timestamp as described in Section 3.3.3.
Within the participant MX infrastructure list this is the same
timestamp like in outer value <timestamp>.
Within an aggregated MX infrastructure list this is a copy of the
value <timestamp> in the original participant MX infrastructure.
cert_list
This JSON object contains one or more arrays of certificate data.
The name can be randomly chosen by the generator of the list but
has to be unique with <cert_list> object. The binary X.509
certificates are stored as base64-encoded strings [RFC4648].
mx
This object MUST contain MTA objects for all inbound and outbound
MTAs of the participant, possibly used for different recipient
domains, referenced by the publicly visible MX hostname as object
name. This object MAY contain MTA objects with names not yet
listed in the MX RR of a domain. This allows to announce new MTAs
in the MX infrastructure list before actually using them.
The MTA object's name is the MX hostname of the MTA. The values in a
JSON MTA object are as follows:
hostname
MX hostname of MTA as fully-qualified domain name (FQDN) following
the rules in Section 3.3.1. An MX hostname MUST NOT be used more
than once for <role> "inbound".
ip_addrs
Array of IPv4 and/or IPv6 addresses as string representations
following the rules in Section 3.3.2.
cert_ref
Names of values in JSON object <cert_list>. Since the same X.509
certificate may be used by more than one MTA the same reference
name MAY be used more than once. Implementations reading a MX
infrastructure list MUST check whether the MTA object's name,
equal to the MX hostname, matches the certificate by implementing
the hostname check described in [RFC6125].
role
Role of MTA, either "inbound" or "outbound".
Laber Expires March 12, 2015 [Page 7]
Internet-Draft IMPT September 2014
Role "inbound" means that this MTA accepts connections from other
MTAs. Regarding TLS this is a TLS server and the used
certificates SHALL be treated as TLS server certificates.
Role "outbound" means that this MTA opens connections to other
MTAs. Regarding this is a TLS client and the used certificates
SHALL be treated as TLS client certificates.
3.3. Value Syntaxes
This section details some syntax rules which conforming
implementations MUST follow when generating values in the JSON lists.
3.3.1. Domain Names
All domains names MUST be stored only with US-ASCII characters
[ANSI.X3-4.1986] without a trailing dot and normalized to lower-case
characters.
Hence internationalized domain names MUST be stored using the A-label
form as defined in [RFC5890].
3.3.2. IP Address Literals
The JSON lists contain IPv4 and/or IPv6 addresses to be compared to
connection information. For secure comparison of those addresses
address literals have to be stored with a uniquely comparable string
representation.
To avoid any misinterpretation the following stricter string
representations MUST be used when generating the JSON lists:
All IPv4 addresses MUST be stored in strict IPv4 dotted-decimal form
ddd.ddd.ddd.ddd
where <ddd> is a one to three digit decimal number between 0 and 255
without non-significant leading zero digits.
All IPv6 addresses MUST be stored in a normalized text representation
as defined in [RFC5952].
3.3.3. Timestamps
All timestamps MUST be stored in format YYYYMMDDhhmmssZ. This format
is formally specified as LDAP syntax "Generalized Time" in [RFC4517],
section 3.3.13.
The time zone is always coordinated universal time (UTC), equivalent
to Greenwich Mean Time (GMT) as indicated by the trailing capital
Laber Expires March 12, 2015 [Page 8]
Internet-Draft IMPT September 2014
letter "Z". IMPT implementations MUST only use the "Z" form of <g-
time-zone> excluding fractions of seconds.
The object member <timestamp> in a JSON list MUST contain the
timestamp of the last update to that list.
A participant list or a participant MX infrastructure list SHOULD
only be generated if the list content actually has been changed.
Consumers of these lists MUST NOT solely rely on a more recent
timestamp value to detect whether there have been changes made to a
list or not. They SHOULD always compare the read JSON with a prior
locally stored version.
3.3.4. Digital signatures
The JSON lists SHOULD be digitally signed. In this case a detached
signature CMS [RFC5652] MUST be used and stored in a separate file.
The signature file name is constructed from the list file name by
appending the suffix ".p7s".
Text normalization, e.g. for line-endings or white-spaces, MUST NOT
be used when generating or validating the signature. Instead
implementations MUST treat JSON lists as single octet strings when
generating or validating the signature.
Proper handling of different line-endings and white-spacing is left
to the JSON parser implementations. Therefore digital signature
verification MUST be performed before parsing the JSON file.
4. IANA Considerations
There are no identifiers defined herein to be reserved by IANA.
5. Security Considerations
Typically a message is submitted by an e-mail sender to a mail relay
and the message is transmitted over several hops. But the mechanism
described herein only assures that an encrypted connection is
established between two IMPT-conforming MTAs. Therefore the use of
secure transport channels cannot guaranteed for the whole
transmission of the message. So the e-mail user is encouraged to use
other end-to-end encryption mechanisms as well.
Implementors SHOULD carefully consider the best practices for using
TLS as described in [I-D.ietf-uta-tls-bcp].
Laber Expires March 12, 2015 [Page 9]
Internet-Draft IMPT September 2014
For all TLS connections the TLS client MUST perform the TLS hostname
check as described in [RFC6125]. In particular when downloading the
JSON lists the HTTPS client has to verify the server identity as
described in [RFC2818], section 3.1.
All implementations MUST correctly perform:
Full X.509 certificate validation as described in [RFC5280],
section 6.
A proper revocation check against the CRL referred in the X.509v3
extension <cRLDistributionPoints> of the certificate to be
validated.
Participants SHOULD carefully monitor the MX infrastructure lists by
comparing whether all own MTA objects correctly and timely appear in
the aggregated MX infrastructure lists mirroring all the MTA objects.
Abnormal deviations SHOULD be properly alerted.
Implementations MAY use certificate pinning for off-loading
revocation checks to an external process.
Implementations SHOULD be aware of all the subtle issues when
comparing string representations of various identifiers such as
hostnames or addresses for security related decisions, specifically
when creating and interpreting the JSON lists defined herein. See
[RFC6943] for a more detailed problem description.
6. References
6.1. Normative References
[ANSI.X3-4.1986]
American National Standards Institute, "Coded Character
Set - 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986.
[E.123] International Telecommunication Union (ITU), "ITU-T Rec.
E.123: Notation for national and international telephone
numbers", November 1988.
[ISO.8601.1988]
International Organization for Standardization, "Data
elements and interchange formats - Information interchange
- Representation of dates and times", ISO Standard 8601,
June 1988.
Laber Expires March 12, 2015 [Page 10]
Internet-Draft IMPT September 2014
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002.
[RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP):
Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, September 2009.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011.
Laber Expires March 12, 2015 [Page 11]
Internet-Draft IMPT September 2014
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014.
6.2. Informative References
[I-D.ietf-uta-tls-bcp]
Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of TLS and DTLS", draft-
ietf-uta-tls-bcp-01 (work in progress), June 2014.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849, July 2004.
[RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide
to the IETF Trust", BCP 78, RFC 5378, November 2008.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July
2009.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
Reserved for Documentation", RFC 5737, January 2010.
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
RFC 6761, February 2013.
[RFC6943] Thaler, D., "Issues in Identifier Comparison for Security
Purposes", RFC 6943, May 2013.
Appendix A. Examples
This section contains example JSON lists. Domain names and IPv4/IPv6
addresses are taken from reserved documentation name/address space as
detailed in [RFC6761] [RFC3849] [RFC5737].
A.1. Participants list
This is a example participants list containing two base domains
example.com and example.net:
Laber Expires March 12, 2015 [Page 12]
Internet-Draft IMPT September 2014
{
"format_version": 1,
"timestamp": "20140305151906Z"
"domains": {
"example.com": {
"contract_date": "2013-08-09",
"contract_org": "ACME Org.",
"base_url": "https://impt.example.com/impt/",
"contact_phone": "+49 6151 672637623",
"contact_email": "impt@example.com",
"not_before": "20130809000000Z"
},
"example.net": {
"contract_date": "2014-02-11",
"contract_org": "ACME Agency",
"base_url": "https://foo.example.net/bar/",
"contact_phone": "+1 673 78274872224",
"contact_email": "impt-admins@example.net",
"not_before": "20140221000000Z"
"not_after": "20160809000000Z",
},
},
}
A.2. MX infrastructure list single participant
This example shows an MX infrastructure list of a single participant
with two base domains "example.com" and "example.net".
Example download URL:
https://impt.example.com/impt/mxinfra.json
Example signature URL:
https://impt.example.com/impt/mxinfra.json.p7s
Note that all <timestamp> values are equal in this case. For
simplicity certificate values are shortened.
Laber Expires March 12, 2015 [Page 13]
Internet-Draft IMPT September 2014
{
"format_version": 1,
"timestamp": "20140305134955Z"
"domains": {
"example.com": {
"timestamp": "20140305134955Z"
"cert_list" : {
"mx00" : ["MII..","MII..",],
"mx01" : ["MII..","MII..",]
},
"mx": [
{
"hostname": "mx00.foo.example.com",
"ip_addrs": [ "128.66.134.8" ],
"cert_ref": "mx00",
"role": "inbound"
},
{
"hostname": "mx01.bar.example.com",
"ip_addrs": [ "128.66.134.72", "2001:DB8:20a:42:2323::1" ],
"cert_ref": "mx01",
"role": "inbound"
},
}
"example.net": {
"timestamp": "20140305134955Z"
"cert_list" : {
"foo" : ["MII..","MII..",],
"bar" : ["MII..","MII..",]
},
"mx": [
{
"hostname": "foo23.example.net",
"ip_addrs": [ "42.23.134.8", "2001:db8::2:1" ],
"cert_ref": "foo",
"role": "inbound"
},
{
"hostname": "bar42.example.net",
"ip_addrs": [ "42.23.134.72", "2001:db8::2:2" ],
"cert_ref": "bar",
"role": "inbound"
},
}
},
}
Laber Expires March 12, 2015 [Page 14]
Internet-Draft IMPT September 2014
A.3. Aggregated MX infrastructure list
This example shows an aggregated MX infrastructure list of with two
base domains "example.com" and "example.net" of different
participants.
Example download URL:
https://impt.example.com/impt/mxinfra-all.json
Example signature URL:
https://impt.example.com/impt/mxinfra-all.json.p7s
Note that in this case all <timestamp> values are different because
the inner values were copied from the source participant MX
infrastructure list. For simplicity certificate values are
shortened.
Laber Expires March 12, 2015 [Page 15]
Internet-Draft IMPT September 2014
{
"format_version": 1,
"timestamp": "20140305134955Z"
"domains": {
"example.com": {
"timestamp": "20140303112227Z"
"cert_list" : {
"mx00" : ["MII..","MII..",],
"mx01" : ["MII..","MII..",]
},
"mx": [
{
"hostname": "mx00.foo.example.com",
"ip_addrs": [ "149.53.134.8" ],
"cert_ref": "mx00",
"role": "inbound"
},
{
"hostname": "mx01.bar.example.com",
"ip_addrs": [ "128.66.134.72", "2001:DB8:20a:42:2323::1" ],
"cert_ref": "mx01",
"role": "inbound"
},
}
"example.net": {
"timestamp": "20140301124257Z"
"cert_list" : {
"foo" : ["MII..","MII..",],
"bar" : ["MII..","MII..",]
},
"mx": [
{
"hostname": "foo23.example.net",
"ip_addrs": [ "42.23.134.8", "2001:db8::2:1" ],
"cert_ref": "foo",
"role": "inbound"
},
{
"hostname": "bar42.example.net",
"ip_addrs": [ "42.23.134.72", "2001:db8::2:2" ],
"cert_ref": "bar",
"role": "inbound"
},
}
},
}
Laber Expires March 12, 2015 [Page 16]
Internet-Draft IMPT September 2014
Author's Address
Markus Laber
1&1 Internet AG
Brauerstr. 48
Karlsruhe 76137
DE
Email: markus.laber@1und1.de
URI: http://www.1und1.de
Laber Expires March 12, 2015 [Page 17]
