D. J. Bernstein
Internet mail
Internet mail infrastructure

CNAME records in mail

RFC 821 prohibited all use of ``nicknames or aliases'' in domain names in SMTP requests. RFC 1123 specifically prohibited DNS aliases (domains with CNAME records) in MAIL and RCPT requests.

sendmail accepts a domain with a CNAME record. It replaces the domain with the CNAME value before using it in RCPT, unless it is acting as a dumb client. Similar comments apply to qmail and other mailers.

This translation effectively offers the following feature to system administrators: ``If you set up www.your.site with a CNAME for your.site, mail to www.your.site will automatically be accepted by your.site's mailer.'' Many sites rely on this feature. Note that this does not work unless CNAME translation is supported by all clients; a message to www.your.site will bounce if the client fails to replace www.your.site with your.site.

Most implementors agree that this feature is not worth the implementation costs. I recommend that, before January 2001, sites stop relying on client-side CNAME translation, so that implementors can safely remove the feature at that time. (Klensin, ignoring the transition problems, allows immediate use of DNS aliases in RCPT requests.)

Lame CNAMEs

sendmail and qmail check for CNAME records as follows: do a * query and search the results for CNAME records.

In theory one could do a CNAME query instead. However, any version of BIND before 4.9.4 will fail if it attempts to make a CNAME query to a lame server. This means that, for many domains, a CNAME query always produces a ``temporary'' error, while any other query, including a * query, works fine.

Other CNAME effects

sendmail rewrites DNS aliases in sender and recipient fields in message headers. This is usually not what anyone wants. sendmail also rewrites DNS aliases in MAIL requests.