122 lines
5.2 KiB
Text
122 lines
5.2 KiB
Text
The Mail Exchanger Protocol Switch (MXPS)
|
|
D. J. Bernstein, djb@pobox.com
|
|
19970201
|
|
|
|
|
|
1. Introduction
|
|
|
|
Mail messages today are transferred through the Simple Mail Transfer
|
|
Protocol (SMTP). One can imagine other protocols that achieve the
|
|
same results as SMTP but that, for example, use the network more
|
|
efficiently.
|
|
|
|
The Mail Exchanger Protocol Switch (MXPS) lets other protocols
|
|
compete with SMTP. A receiver can announce its support for another
|
|
protocol while operating properly with MXPS-ignorant senders. A
|
|
sender can check for support, with no overhead, while operating
|
|
properly with MXPS-ignorant receivers.
|
|
|
|
All receivers must support SMTP, i.e., must be able to receive
|
|
messages via SMTP. Similarly, all senders must be able to send
|
|
messages via SMTP.
|
|
|
|
|
|
2. The protocol switch
|
|
|
|
MXPS abuses the preference field of MX records. A protocol is
|
|
assigned to each possible preference.
|
|
|
|
SMTP is assigned to preferences 0 through 10000.
|
|
|
|
The initial MXPS experiment will involve preferences between 12800
|
|
and 13055 inclusive. These preferences are sliced into 16 portions:
|
|
|
|
12800, 12816, 12832, 12848, 12864, ..., 13040: slice #0 (SMTP)
|
|
12801, 12817, 12833, 12849, 12865, ..., 13041: slice #1 (QMTP)
|
|
12802, 12818, 12834, 12850, 12866, ..., 13042: slice #2
|
|
...
|
|
12815, 12831, 12847, 12863, 12879, ..., 13055: slice #15
|
|
|
|
Preferences in slice #0 are assigned SMTP. Preferences in slice #1
|
|
are assigned the Quick Mail Transfer Protocol (QMTP). Preferences in
|
|
the remaining slices may be assigned protocols in the future.
|
|
|
|
A receiver must support the protocol assigned to its preference. More
|
|
precisely, if an MX record points to domain D, and the MX preference
|
|
is assigned protocol P, then every host listed as an A record for D
|
|
must support protocol P.
|
|
|
|
When a sender, following the procedure outlined in RFC 974 (and
|
|
modified by RFC 1123), attempts to deliver a mail message as
|
|
specified by that MX record, it may use protocol P instead of SMTP.
|
|
If it does not support protocol P, it may treat the attempt as a
|
|
temporary failure and go on to the next MX record. However, the
|
|
sender must not skip every MX record.
|
|
|
|
MX records must never use unassigned preferences. A sender may treat
|
|
an unassigned preference as referring to SMTP.
|
|
|
|
Example:
|
|
|
|
A.EXAMPLE.ORG IN MX 12801 A.EXAMPLE.ORG
|
|
B.EXAMPLE.ORG IN MX 12801 A.EXAMPLE.ORG
|
|
IN MX 12816 C.EXAMPLE.ORG
|
|
|
|
A sender with a message for A.EXAMPLE.ORG will try A.EXAMPLE.ORG by
|
|
QMTP. If it does not support QMTP, it will try SMTP instead. Note
|
|
that A.EXAMPLE.ORG must support both QMTP and SMTP.
|
|
|
|
A sender with a message for B.EXAMPLE.ORG will try A.EXAMPLE.ORG by
|
|
QMTP, then C.EXAMPLE.ORG by SMTP. If it does not support QMTP, it may
|
|
try SMTP instead of QMTP, or it may skip A.EXAMPLE.ORG.
|
|
|
|
Some of the above requirements might be violated if current
|
|
MXPS-ignorant domains use any preferences above 10000. Mail could be
|
|
unnecessarily rejected if any existing MXPS-ignorant domains have a
|
|
best-preference MX above 10000. I do not know any examples of such
|
|
domains.
|
|
|
|
|
|
3. Protocol requirements
|
|
|
|
MXPS operates purely at the link level. It does not change the
|
|
fundamental nature of Internet mail.
|
|
|
|
The function of a mail transfer protocol is to transmit a message, as
|
|
described below, together with an envelope sender address and one or
|
|
more envelope recipient addresses.
|
|
|
|
A recipient address is a sequence of characters---i.e., nonnegative
|
|
integers---including an ASCII @ (64). It is parsed as box@dom, where
|
|
dom does not contain an @. The interpretation of box is up to the
|
|
hosts listed as MX records for dom. A sender address may contain an
|
|
@, in which case it is also of the form box@dom; or it may be a
|
|
special address, such as the empty string.
|
|
|
|
A mail message is structured as a sequence of lines. A line is a
|
|
sequence of characters. Every mail transfer protocol must be able to
|
|
transmit all sufficiently short boring mail messages. A boring mail
|
|
message is one where (1) no line has more than 80 characters and (2)
|
|
each character is either 9 or between 32 and 127 inclusive. Note that
|
|
RFC 1341 defines a mechanism for encoding a message with characters
|
|
between 0 and 255 inclusive as a boring mail message of similar
|
|
length.
|
|
|
|
The receiver must indicate, for each recipient address, either
|
|
acceptance, permanent rejection, or temporary rejection of the
|
|
message. Acceptance means that the receiver has taken responsibility,
|
|
in the sense of RFC 1123, section 5.3.3, for delivering the message
|
|
to that recipient. Rejection means that the receiver will not deliver
|
|
the message to that recipient.
|
|
|
|
Mail transfer protocols may vary in many details, such as line
|
|
encodings, the means of expressing acceptance or rejection, the
|
|
maximum number of allowable recipients per envelope, the encoding of
|
|
envelope addresses, the nature of optional protocol extensions, etc.
|
|
|
|
|
|
4. Security considerations
|
|
|
|
MXPS does not change the following facts: An attacker who can subvert
|
|
the Domain Name System can steal or forge mail. An attacker who can
|
|
subvert TCP/IP can also steal or forge mail.
|