Viktor,
Please be careful when you interpret 2821 or 5321 as prohibiting
/ deprecating some action. First, the relevant WG ("DRUMS")
made a very explicit decision to not include sentences like "if
so-and-so that we don't like happens, you MUST do the following
thing". Instead, the tone and content of the spec are much more
like "So-and-so is outside the spec. If you do it,
interoperability is not guaranteed, the behavior needed for
interoperability is not specified, and you should not be
surprised if some system in the path does something you won't
like".
Now, the text you quote from 2821 (and the slight more detailed
but essentially equivalent text in Section 2.3.5 of RFC 5321)
fairly explicitly say that
foo.example.net. CNAME bar.example.net.
bar.example.net. MX 0 smtp1.example.com.
and hence an address of user@??? is valid. The
intent, which I hope is clear, is that the RCPT command
transmitted to smtp1.example.com have <user@???> as
its [primary] parameter and not anything involving "bar". That
is important because it is SMTP-valid to treat the putative
mailbox user@??? as different from
user@???. If there were an additional DNS record
fuzz.example.net. CNAME bar.example.net.
mail to user@??? could legitimately be given yet
different treatment.
None of that prevents using CNAMEs that way from being a bad
idea, as I and others have commented.
However, when the name chain is rather more like
foo.example.net. CNAME bong.example.net.
bong.example.net. CNAME bar.example.net.
bar.example.net. MX 0 smtp1.example.com.
(similar to the example Mike gave), the clause "...as are CNAME
RRs whose targets can be resolved, in turn, to MX or address
RRs" because 5321 doesn't say "CNAME RRs that can be eventually
resolved by following an arbitrary long alias chain". CNAME
chains, i.e., a CNAME pointing to another alias rather than to
an RR with MX or address records, are not clearly prohibited,
but anyone using them is on thin ice, thin enough that a
submission server or relay would be entirely justified,
especially in the presence of the "operational necessity"
provisions of 5321, to resolve foo, find the CNAME RR, resolve
bong, find a CNAME RR, and then refuse to have anything more to
do with the message (note that case doesn't require rewriting
any labels that own CNAMEs to their targets or anything else).
It would certainly not be required to do that -- it could use a
more flexible reading of the 5321 text, apply the robustness
principle, and follow the alias chain another step or two. But
there is no guarantee it will do so, which is another thing that
makes long CNAME chains a bad idea.
Combine that with the unfortunate relationship between CNAME
records and DNSSEC, and the best practice advice is to avoid
them if possible, using MX records on the domain name that is
the public face of the email system. If that is infeasible for
some reason, then it would be wise to do only what 2821/5321
explicitly allow, which is a chain with no more than one alias
in it.
best,
john
p.s. anyone who believes that 5321 should have explicitly
permitted or prohibited CNAME chains of either unlimited length
or of longer than one alias is welcome to file an erratum and or
complain on the SMTP list. I cannot promise, or even predict,
that you will find it a satisfying experience however.
--On Wednesday, July 27, 2016 13:46 +0000 Viktor Dukhovni
<exim-users@???> wrote:
> On Wed, Jul 27, 2016 at 11:16:21PM +1000, Richard James Salts
> wrote:
>
>> > When I send a probe to <postmaster@???>, I get:
>> >
>> > Reporting-MTA: dns; mournblade.imrryr.org
>> > X-Postfix-Queue-ID: 23C8D284F25
>> > X-Postfix-Sender: rfc822; exim-users@???
>> > Arrival-Date: Wed, 27 Jul 2016 12:46:05 +0000 (UTC)
>> >
>> > Final-Recipient: rfc822; postmaster@???
>> > Original-Recipient: rfc822;postmaster@???
>> > Action: deliverable
>> > Status: 2.1.5
>> > Remote-MTA: dns; mx.sendgrid.net
>> > Diagnostic-Code: smtp; 250 2.1.5 Ok
>> >
>> > So the issue sure looks like sendgrid is blocking the
>> > sending host, envelope sender domain, or specific recipient
>> > address.
>>
>> This is because postfix and exim differ on where the mail
>> should be sent.
>
> Indeed. However, Canonicalization of the recipient domain via
> CNAME records was deprecated quite some time back in RFC 2821
> (published in April 2001). If the OP's Exim is still doing
> that, it is out-of-date, misconfigured or both[1].
>
> Postfix changed its treatment of CNAME domains in December of
> 2002:
>
> 20021207
>
> Performance: RFC 2821 blesses the use of CNAME domain
> names in MAIL FROM and RCPT TO.
>
> At the time this was classified as a performance improvement,
> but it is, by now if not then, a matter of correctness. Such
> rewriting is no longer correct.
>
> It is also odd that the domain name used was taken from the
> "middle" of the CNAME chain:
>
> help.uber.com. 60 IN CNAME frontends.uber.com.
> frontends.uber.com. 60 IN CNAME frontends-sjc1.uber.com.
>
> 454 4.7.1 <test123@???>: Relay access denied
>
> If canonicalization were to be done, it should have been done
> "right", resulting in "frontends-sjc1.uber.com" as the
> recipient domain, (which likely would still have been
> rejected).
>
> --
> Viktor.
>
> [1] https://tools.ietf.org/html/rfc2821#section-3.6
>
> Only resolvable, fully-qualified, domain names (FQDNs) are
> permitted when domain names are used in SMTP. In other
> words, names that can be resolved to MX RRs or A RRs (as
> discussed in section 5) are permitted, as are CNAME RRs
> whose targets can be resolved, in turn, to MX or A RRs.
