At 10:51 AM +0900 4/11/07, Stephen J. Turnbull wrote:
> If you look at RFC 2821, you will discover that in section 2.3.5, it
> specifically allows CNAME aliases in the "domain name" part of a
> mailbox.
RFC 2821 covers only the SMTP transport protocol, not the message
format. That would be RFC 2822. And I found a reference in section
3.4.1 of RFC 2822 which implies that CNAME aliases are *not* allowed
in mailbox names. I'll quote the whole section here, and then go
back and highlight the reference:
| 3.4.1. Addr-spec specification
|
| An addr-spec is a specific Internet identifier that contains a
| locally interpreted string followed by the at-sign character ("@",
| ASCII value 64) followed by an Internet domain. The locally
| interpreted string is either a quoted-string or a dot-atom. If the
| string can be represented as a dot-atom (that is, it contains no
| characters other than atext characters or "." surrounded by atext
| characters), then the dot-atom form SHOULD be used and the
| quoted-string form SHOULD NOT be used. Comments and folding white
| space SHOULD NOT be used around the "@" in the addr-spec.
|
| addr-spec = local-part "@" domain
|
| local-part = dot-atom / quoted-string / obs-local-part
|
| domain = dot-atom / domain-literal / obs-domain
|
| domain-literal = [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS]
|
| dcontent = dtext / quoted-pair
|
| dtext = NO-WS-CTL / ; Non white space controls
| %d33-90 / ; The rest of the US-ASCII
| %d94-126 ; characters not including "[",
| ; "]", or "\"
|
| The domain portion identifies the point to which the mail is
| delivered. 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 the domain-literal form, the
| domain is interpreted as the literal Internet address of the
| particular host. In both cases, how addressing is used and how
| messages are transported to a particular host is covered in the mail
| transport document [RFC2821]. These mechanisms are outside of the
| scope of this document.
|
| The local-part portion is a domain dependent string. In addresses,
| it is simply interpreted on the particular host as a name of a
| particular mailbox.
The important sentence here is:
| 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.
> I conclude that only the EHLO (HELO) command (and possibly
> the server's greeting messages) has the restriction.
It does have this restriction, but it is not the only part that does.
> The rationale is
> that it is an error-reporting mechanism, which needs to be more
> carefully specified since the system is known to be in a problem
> state. See section 4.1.1, which specifies that the host specified by
> a domain in EHLO should have a reverse mapping. Since a CNAME can't
> have a corresponding PTR, the restriction in STD 3 follows.
>
> "MX names" are also allowed, for what it is worth.
See above. I believe that the CNAME re-writing behaviour, as
originally described, is required by the RFCs.
--
Brad Knowles <[EMAIL PROTECTED]>, Consultant & Author
LinkedIn Profile: <http://tinyurl.com/y8kpxu>
Slides from Invited Talks: <http://tinyurl.com/tj6q4>
------------------------------------------------------
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
