| 1 | The Mail Exchanger Protocol Switch (MXPS) |
| 2 | D. J. Bernstein, djb@pobox.com |
| 3 | 19970201 |
| 4 | |
| 5 | |
| 6 | 1. Introduction |
| 7 | |
| 8 | Mail messages today are transferred through the Simple Mail Transfer |
| 9 | Protocol (SMTP). One can imagine other protocols that achieve the |
| 10 | same results as SMTP but that, for example, use the network more |
| 11 | efficiently. |
| 12 | |
| 13 | The Mail Exchanger Protocol Switch (MXPS) lets other protocols |
| 14 | compete with SMTP. A receiver can announce its support for another |
| 15 | protocol while operating properly with MXPS-ignorant senders. A |
| 16 | sender can check for support, with no overhead, while operating |
| 17 | properly with MXPS-ignorant receivers. |
| 18 | |
| 19 | All receivers must support SMTP, i.e., must be able to receive |
| 20 | messages via SMTP. Similarly, all senders must be able to send |
| 21 | messages via SMTP. |
| 22 | |
| 23 | |
| 24 | 2. The protocol switch |
| 25 | |
| 26 | MXPS abuses the preference field of MX records. A protocol is |
| 27 | assigned to each possible preference. |
| 28 | |
| 29 | SMTP is assigned to preferences 0 through 10000. |
| 30 | |
| 31 | The initial MXPS experiment will involve preferences between 12800 |
| 32 | and 13055 inclusive. These preferences are sliced into 16 portions: |
| 33 | |
| 34 | 12800, 12816, 12832, 12848, 12864, ..., 13040: slice #0 (SMTP) |
| 35 | 12801, 12817, 12833, 12849, 12865, ..., 13041: slice #1 (QMTP) |
| 36 | 12802, 12818, 12834, 12850, 12866, ..., 13042: slice #2 |
| 37 | ... |
| 38 | 12815, 12831, 12847, 12863, 12879, ..., 13055: slice #15 |
| 39 | |
| 40 | Preferences in slice #0 are assigned SMTP. Preferences in slice #1 |
| 41 | are assigned the Quick Mail Transfer Protocol (QMTP). Preferences in |
| 42 | the remaining slices may be assigned protocols in the future. |
| 43 | |
| 44 | A receiver must support the protocol assigned to its preference. More |
| 45 | precisely, if an MX record points to domain D, and the MX preference |
| 46 | is assigned protocol P, then every host listed as an A record for D |
| 47 | must support protocol P. |
| 48 | |
| 49 | When a sender, following the procedure outlined in RFC 974 (and |
| 50 | modified by RFC 1123), attempts to deliver a mail message as |
| 51 | specified by that MX record, it may use protocol P instead of SMTP. |
| 52 | If it does not support protocol P, it may treat the attempt as a |
| 53 | temporary failure and go on to the next MX record. However, the |
| 54 | sender must not skip every MX record. |
| 55 | |
| 56 | MX records must never use unassigned preferences. A sender may treat |
| 57 | an unassigned preference as referring to SMTP. |
| 58 | |
| 59 | Example: |
| 60 | |
| 61 | A.EXAMPLE.ORG IN MX 12801 A.EXAMPLE.ORG |
| 62 | B.EXAMPLE.ORG IN MX 12801 A.EXAMPLE.ORG |
| 63 | IN MX 12816 C.EXAMPLE.ORG |
| 64 | |
| 65 | A sender with a message for A.EXAMPLE.ORG will try A.EXAMPLE.ORG by |
| 66 | QMTP. If it does not support QMTP, it will try SMTP instead. Note |
| 67 | that A.EXAMPLE.ORG must support both QMTP and SMTP. |
| 68 | |
| 69 | A sender with a message for B.EXAMPLE.ORG will try A.EXAMPLE.ORG by |
| 70 | QMTP, then C.EXAMPLE.ORG by SMTP. If it does not support QMTP, it may |
| 71 | try SMTP instead of QMTP, or it may skip A.EXAMPLE.ORG. |
| 72 | |
| 73 | Some of the above requirements might be violated if current |
| 74 | MXPS-ignorant domains use any preferences above 10000. Mail could be |
| 75 | unnecessarily rejected if any existing MXPS-ignorant domains have a |
| 76 | best-preference MX above 10000. I do not know any examples of such |
| 77 | domains. |
| 78 | |
| 79 | |
| 80 | 3. Protocol requirements |
| 81 | |
| 82 | MXPS operates purely at the link level. It does not change the |
| 83 | fundamental nature of Internet mail. |
| 84 | |
| 85 | The function of a mail transfer protocol is to transmit a message, as |
| 86 | described below, together with an envelope sender address and one or |
| 87 | more envelope recipient addresses. |
| 88 | |
| 89 | A recipient address is a sequence of characters---i.e., nonnegative |
| 90 | integers---including an ASCII @ (64). It is parsed as box@dom, where |
| 91 | dom does not contain an @. The interpretation of box is up to the |
| 92 | hosts listed as MX records for dom. A sender address may contain an |
| 93 | @, in which case it is also of the form box@dom; or it may be a |
| 94 | special address, such as the empty string. |
| 95 | |
| 96 | A mail message is structured as a sequence of lines. A line is a |
| 97 | sequence of characters. Every mail transfer protocol must be able to |
| 98 | transmit all sufficiently short boring mail messages. A boring mail |
| 99 | message is one where (1) no line has more than 80 characters and (2) |
| 100 | each character is either 9 or between 32 and 127 inclusive. Note that |
| 101 | RFC 1341 defines a mechanism for encoding a message with characters |
| 102 | between 0 and 255 inclusive as a boring mail message of similar |
| 103 | length. |
| 104 | |
| 105 | The receiver must indicate, for each recipient address, either |
| 106 | acceptance, permanent rejection, or temporary rejection of the |
| 107 | message. Acceptance means that the receiver has taken responsibility, |
| 108 | in the sense of RFC 1123, section 5.3.3, for delivering the message |
| 109 | to that recipient. Rejection means that the receiver will not deliver |
| 110 | the message to that recipient. |
| 111 | |
| 112 | Mail transfer protocols may vary in many details, such as line |
| 113 | encodings, the means of expressing acceptance or rejection, the |
| 114 | maximum number of allowable recipients per envelope, the encoding of |
| 115 | envelope addresses, the nature of optional protocol extensions, etc. |
| 116 | |
| 117 | |
| 118 | 4. Security considerations |
| 119 | |
| 120 | MXPS does not change the following facts: An attacker who can subvert |
| 121 | the Domain Name System can steal or forge mail. An attacker who can |
| 122 | subvert TCP/IP can also steal or forge mail. |