macro.mxps (2444B)
1 2 # The NightmareMail Pictures » The Macro Picture » Mail eXchanger Protocol Switch 3 4 (This document is prefaced with a newline so that it might be rendered correctly as Headered Markdown. It is regular Markdown, and further, any drawings within are conformed to a 70 character terminal, so that they might be rendered correctly doing `less` on an 80 character terminal.) 5 6 "so, hang on... if you take MXPS in hex, the slice no. is the last digit (4 bits), and the preference level is the second to last digit (4 bits)?" ~ Melanie Bjornsdottir, to her friend who knows nothing about mail exchangers 7 8 They say those that the gods would destroy, they first drive insane. (With apologies to the judge in 2013 ONCJ 160) With ready access to a Tcl interpreter with `[format]`, on this subject, it appears the gods are kind. We explore the specific implications of the distance numbers Daniel has chosen for the MXPS, which, by the way, is absolutely obsolete. In NightmareMail, we will support it, but on systems configured to use what we call SRVMAIL, we will try it only after failing _qmtp-relay._tcp and _smtp-relay._tcp. 9 10 ## Background 11 12 The [**Mail Exchanger Protocol Switch**](http://cr.yp.to/im/mxps.html) is an Internet protocol proposal by Daniel Bernstein. In [the original version](http://cr.yp.to/im/mxps-old.txt), he elaborates on the slice design. There are sixteen slices counting from the distance of 12800 (decimal), numbered 0 through 15 (decimal). These slices appear to be based in a number starting zero to fifteen, and go up in strides of 16. When we enter the numbers into tclsh thus: 13 <code> 14 % puts stdout [format "%x %x %x %x" 12800 12816 12817 12834] 15 3200 3210 3211 3222 16 </code> 17 (prio 0 slice 0, prio 1 slice 0, prio 1 slice 1, prio 2 slice 2) we see that this is effectively a bitmask. 18 19 In the original proposal, 16 slices are defined, but only 2 are proposed to be used for a protocol. Slice 0 (dist & 000f = 0) is proposed to be used for classic SMTP, and slice 1 is proposed to be used for classic QMTP. In the new DJB proposal, the meaning of slice 1 is changed to classic QMTP, followed by classic SMTP. In this document, we propose that both slices should be changed to mean their secure-preferred versions, and slice 1 should be changed back to QMTPS-only, and we further propose that the MX record should be made obsolete in favour of SRV records, to be tried in the order of sending-side administrator preference. 20