[Mailman-Users] Virtual hosts

[Stephen J. Turnbull]

Brad Knowles writes:

 > |              In the dot-atom form, this is interpreted as an Internet
 > |   domain name (either a host name or a mail exchanger name) as
 > |   described in [STD3, STD13, STD14].
 > 
 > In particular, note that it says "host name" or "mail exchanger 
 > name", and specifically omits "CNAME alias", and refers you to STD3 
 > (RFCs 1122 and 1123) and STD13 (RFC 1034) for definitions of these 
 > terms.

"Host name" is not defined in STD 3 or STD 13, unfortunately, and IMO
usage throughout both clearly includes CNAMEs in most cases, in
particular in sections describing handling of CNAMEs.  RFC 2821
section 3.6 does define "primary host name" as one corresponding to an
A RR in the DNS, by omission allowing a host name to be a CNAME.

 > 
 > >            I conclude that only the EHLO (HELO) command (and possibly
 > >  the server's greeting messages) has the restriction.

This is an egregious error on my part; RFC 1123 (STD 3) is absolutely
clear on this point.  Section 5.2.2 states that in the MAIL FROM and
RCPT TO commands the address must be a *primary* host name (ie, not a
CNAME, but this includes domain literals) or an MX name.  Section
5.2.5 states that the HELO (or ELHO) command must contain a valid
principal host name (including a domain literal).  ("Principal host
name" is apparently intended to be a synonym for "primary host name.")

However, RFC 2821 section 3.6 is emphatic that the only exceptions to
the requirement that the domain part of an address be an FQDN which is
an A, MX, or CNAME are (a) the reserved mailbox "postmaster" and (b)
the address in EHLO.  Then, RFC 2821 section 5 clearly mandates that
CNAME processing MUST be done at connection time (emphasis in the
RFC).

I would conclude (conservatively) that implementations based on RFC
1123 are quite possibly common, and therefore host addresses in EHLO,
MAIL, and RCPT should be primary host names (and of course MX
addresses are allowed in MAIL and RCPT).  However, RFC 2821 allows
CNAMEs IMHO.

I think it's odd that RFC 2821 section 3.6 fails to mention that it
contradicts RFC 1123 section 5.2.2.  Nor does RFC 2821 claim to
supersede or update RFC 1123 or STD 3.  The fact that in both 3.6 and
throughout section 5 it implausibly restricts primary names to A RRs
(omitting IPv6 AAAA RRs) suggests to me that there was a long
political battle, and everybody was too tired to even kick the tires
to make sure there was air in them before publishing the RFC.  :-/

Late-breaking news:  somebody who I suspect knows what they're doing
agrees with me that RFC 2821 should say it updates RFC 1123:

http://mirror.switch.ch/ftp/mirror/internet-drafts/draft-klensin-rfc2821bis-01.txt

specifically, section 1.4 of that draft says it replaces the entire
mail section of RFC 1123.  Granted, it's just a draft ... it's time
for me to go to bed, so I'll use that as an excuse not to read it just
yet.<wink>

 > See above.  I believe that the CNAME re-writing behaviour, as 
 > originally described, is required by the RFCs.

Well, it is required by RFC 1123, but RFC 2821 clearly envisions a
world where CNAMEs are always resolved by the client at the time of
contacting the server, with the exception of the ELHO command, which
must already be a primary host name.

I believe that the restrictions on address fields in messages in RFC
2822 format are much weaker, ie, purely syntactic.  There's no reason
to suppose that the MUA will have an Internet connection or be
available to revise addresses if the MTA doesn't like them; on the
other hand, the MTA should not rewrite headers.