+++ /dev/null
-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.
~mdw / qmail / blobdiff