Subject: [ietf-smtp] Domain names in the presence of CNAME records

From: "Peter J. Holzer" <[email-masked]>
Date: Mon, 6 May 2013 10:56:18 +0200

Hello everybody,

this is a somewhat theoretical topic, but it seems to come up every few
years in usenet discussions, so I'll ask for clarification/opinions.

Consider this DNS configuration:

A.example.com. CNAME M.example.com.
M.example.com. MX    10 S.example.com.
S.example.com. A     192.0.2.1

Now an MTA receives a message addressed to <[email-masked]>. This
MTA is a relay system and has no special configuration with regard to
A.example.com.

RFC 5321, section 5.1 specifies how to resolve "A.example.com", so by
following the chain A.example.com -> M.example.com -> 192.0.2.1 the MTA
will end up connecting to 192.0.2.1. We now have an SMTP connection and
I will call this MTA the client and 192.0.2.1 the server.

Which address should the client use in the RCPT TO command?

1) <[email-masked]>, because a relay must pass on the message
   unmodified.
2) <[email-masked]>, because M.example.com is the canonical name 
   of the recipient domain.
3) Undefined behaviour. The MTA could even have rejected the message.
4) Other.

If the client sends "RCPT TO:<[email-masked]>", how should the
server treat this?

1) Exactly the same as "RCPT TO:<[email-masked]>", because
   A.example.com is an alias for M.example.com, so both must behave the
   same.
2) <[email-masked]> and <[email-masked]> may designate different 
   mail boxes (and only one of them may exist).
3) Other.

I do have an opinion and I think I can back it up with quotes from the
RFC, but I've tried to state the question neutrally. 

	hp

-- 
   _  | Peter J. Holzer    | Der eigene Verstand bleibt gefühlt messer-
|_|_) | Sysadmin WSR       | scharf. Aber die restliche Welt blickt's
| |   | [email-masked]         | immer weniger.
__/   | http://www.hjp.at/ |   -- Matthias Kohrs in desd

---

From: Bart Schaefer <[email-masked]>
Date: Mon, 6 May 2013 06:43:41 -0700

The relay should not rewrite the address.

The receiving server can treat the address any way it wants to.

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Mon, 06 May 2013 14:54:20 +0100

http://cr.yp.to/im/cname.html

He is wrong in his interpretation of the spec, but correct in the conclusion.  All features of "Canonicalisation" can be handled more effectively with current MX records, and by having the receiving server correctly recognise all of the names for which it's responsible.

Cheers,
Sabahattin

---

From: Steve Atkins <[email-masked]>
Date: Mon, 6 May 2013 15:01:25 +0100

> The receiving server can treat the address any way it wants to.

+1.

CNAMEs (or NSes) at the DNS level shouldn't affect anything
at the SMTP level other than by the MX and address records
returned by the resolver. (Though some software used to -
and likely still does - rewrite addresses in this way.)

Cheers,
 Steve

---

From: "John Levine" <[email-masked]>
Date: 6 May 2013 14:25:48 -0000

>RFC, but I've tried to state the question neutrally. 

Back in 1987 when the DNS was young, CNAMEs were invented to describe
short nicknames for long host names, or as a transition aid when a
host's name was changing.  The rule for SMTP was that if you saw a
CNAME you should rewrite it to the CNAME's target, since the CNAME was
just a nickname for the host's real name.

These days, perhaps 1% of CNAMEs are used that way, and the other 99%
are used to do long term DNS management, by allowing a name in one
part of the DNS tree to alias to a name somewhere else to outsource
the management of the first name to the second.  In this usage,
rewriting CNAMEs is obviously not a good idea.

While you will still find people who insist that you should rewrite a
CNAME in a mail transaction (do not ever, EVER, ask this questionon
the dnsext list) they are wrong.

RFC 5321 still says that the HELO/EHLO name has to resolve directly to
an A or AAAA, not a CNAME.  I don't know if anyone pays any attention
to that.

R's,
John

---

From: "Peter J. Holzer" <[email-masked]>
Date: Tue, 7 May 2013 14:56:35 +0200

> years in usenet discussions, so I'll ask for clarification/opinions.

Well, that was pretty unanimous.

Thanks to everybody who answered!

	hp

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 07 May 2013 22:05:48 +0200

> The relay should not rewrite the address.

+1

> The receiving server can treat the address any way it wants to.

Agreed, with only one remark: the receiving server that rewrites the 
domainpart of RFC5321.MailFrom and/or RFC5322.From before performing SPF 
and/or DKIM verification, loses the ability to _reliably_ perform SPF 
and/or DKIM verification after rewriting.

/rolf

---

From: John C Klensin <[email-masked]>
Date: Wed, 08 May 2013 08:39:17 -0400

--On Tuesday, May 07, 2013 22:05 +0200 "Rolf E. Sonneveld"
<[email-masked]> wrote:

>...
> Agreed, with only one remark: the receiving server that
> rewrites the domainpart of RFC5321.MailFrom and/or
> RFC5322.From before performing SPF and/or DKIM verification,
> loses the ability to _reliably_ perform SPF and/or DKIM
> verification after rewriting.

Let me say what may be the same thing a little differently.

The delivery MTA ("receiving server") pretty much has to know
all of the domains under which it will receive mail.  Certainly
that is a necessity for any sort of rewriting.  If that server
rewrites things incorrectly, or fails to account for the
side-effects of rewriting, various bad things will happen.  The
effects on signed headers or fancy attempts to match header
information with additional (non-address, non-MX) information in
the DNS (including, but not limited to SPF and DKIM) are just
some of those bad things.

    john