Implementing long form email addresses ====================================== Names within the 'cam.ac.uk' DNS domain are allocated by the Information Technology Syndicate. Each university institution is usually allocated a single sub-domain name within 'cam.ac.uk'. The Syndicate will, under some circumstances, allow an institution which has been allocated a heavily abbreviated subdomain to use a longer, 'more descriptive' sub-domain alias in email addresses (and World Wide Web URLs, though that is not addressed here) while maintaining the existing short name for day-to-day use. For example if St Botolph's College had been allocated the mail domain @sbc.cam.ac.uk then it might additionally be allowed to use use email addresses such as @botolph.cam.ac.uk This document describes the Computing Service's implementation of how such 'long form aliases' will be implemented in email. General principles ------------------ One of the requirements for email domains in Cambridge is that a reasonable attempt should be made to ensure that all users in an institution have addresses at the institution's email domain. The reason for this is to make it likely that those attempting to send email to people in the institution will find the intended recipient there. This recommendation is extended to both the long and short forms of the domain, which effectively means that both domains should support the same set of local parts (before the @). This is similar to the recommendation that long and short form web site URLs should present the same content. At present it's common for personal email addresses to have both short form (CRSID) and long form (friendly name) local parts at the institution's domain. In particular, the managed mail domain system encourages this setup. With the introduction of long form domains, a person will typically end up with four departmental or college email addresses, for example, spqr1@sbc.cam.ac.uk, Sam.Reman@sbc.cam.ac.uk, spqr1@botolph.cam.ac.uk, Sam.Reman@botolph.cam.ac.uk. In the web context there are technical reasons related to caches and search engines that make it preferable to have a single canonical site name, with aliases that cause an externally visible redirection to the canonical name. In email there are no similar technical pressures, so all the addresses can operate on an equal footing to each other. Furthermore, there is no technical mechanism (similar to HTTP redirects) for us to inform the sender of a message that they have used a non-canonical form of address. Although rewriting addresses in the message header (particularly the From: field) might seem like a good way of enforcing the use of a canonical form, it causes serious difficulties for email security technologies (such as PGP). This kind of rewriting also depends on assumptions about where email is sent from and how it is routed which are not correct in all cases. One way of routing all the addresses in one domain to another domain is by using aliasing or forwarding in the MTA, similar to the way managed mail domains work. This causes the replacement of the recipient address in the message envelope. Unlike the rewriting described in the previous paragraph it is mostly invisible to users and therefore much less problematic. It is also simpler to implement than teaching all the MTAs along the delivery path about both domains. Recommendations --------------- Therefore we recommend that: 1) For each long form email domain, a corresponding short form name should be maintained indefinitely. 2) All the local-parts that are valid in one form of the domain should also be valid in the other, and should deliver to the same destination. 3) Routing and delivery of long form addresses can be implemented by causing them to be forwarded to the corresponding short form, or vice versa. 4) An institution that has a preferred form of address should encourage its use by appropriately configuring MUAs rather than by rewriting message headers. The next few sections describe how long form addresses can be implemented in various situations. In many cases these use the general-purpose mechanism that the Computing Service has implemented on ppswitch (the central email relay), which forwards email sent to a long form address to its corresponding short form. Managed mail domains -------------------- An institution which has a short form managed mail domain may request a long form. For the purposes of email routing and delivery the short form and long form will be exactly equivalent. Domain managers will continue to edit the domain under its short form name, and any changes will apply to both forms. Hubbed domains -------------- Institutions which run their own email systems and receive their email via ppswitch are said to be "hubbed". They have two options for handling long form domains. 1) They can use the forwarding mechanism on ppswitch. The advantage is that the departmental server needs no configuration changes: ppswitch handles the long form addresses and delivers the messages to the departmental server using short form addresses. The disadvantage is that long form email within the department will take an extra hop via ppswitch, acusing extra load as each message is handled twice. 2) The departmental server can be configured to handle email for both long form and short form addresses. Both forms will be routed to the departmental server unchanged by ppswitch. This is more efficient but requires more configuration work. In both cases the MX records for the short form and the long form domains will point to mx.cam.ac.uk. Independent domains ------------------- This section covers institutions which run their own email systems and receive their email directly from the Internet. They have two options for handling long form domains, corresponding to the options for hubbed domains above. 1) They can use the forwarding mechanism on ppswitch. In this case the MX record for the short form will point to the departmental server, and the long form will point to mx.cam.ac.uk. As well as the disadvantages described in the previous section, this means that the domains will have different anti-spam and anti-virus policies, which is probably not desirable. 2) The departmental server can be configured to handle email for both long form and short form addresses. The MX records for the short form and the long form domains will point to the departmental server. $Cambridge: hermes/doc/misc/longform.txt,v 1.3 2005/03/14 16:46:43 fanf2 Exp $