[qmail] / RFCMXPS

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.
Commit	Line	Data
2117e02e MW	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.