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 u...@foo.example.net is valid. The intent, which I hope is clear, is that the RCPT command transmitted to smtp1.example.com have <u...@foo.example.net> as its [primary] parameter and not anything involving "bar". That is important because it is SMTP-valid to treat the putative mailbox u...@foo.example.net as different from u...@bar.example.net. If there were an additional DNS record fuzz.example.net. CNAME bar.example.net. mail to u...@fuzz.example.net 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-us...@dukhovni.org> wrote: > On Wed, Jul 27, 2016 at 11:16:21PM +1000, Richard James Salts > wrote: > >> > When I send a probe to <postmas...@help.uber.com>, I get: >> > >> > Reporting-MTA: dns; mournblade.imrryr.org >> > X-Postfix-Queue-ID: 23C8D284F25 >> > X-Postfix-Sender: rfc822; exim-us...@dukhovni.org >> > Arrival-Date: Wed, 27 Jul 2016 12:46:05 +0000 (UTC) >> > >> > Final-Recipient: rfc822; postmas...@help.uber.com >> > Original-Recipient: rfc822;postmas...@help.uber.com >> > 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 <test...@frontends.uber.com>: 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. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/