Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've discovered that a remote site is rewriting email intended for our machines to use the CName of the machine that the mail was addressed to (e.g. mail@virtual.virtualdomain.com becomes mail@cname.maindomain.com). Is this correct behavior?

If so, can this be avoided by also adding an MX record or something else?

share|improve this question
    
Can you clarify the current behavior? When emails are addressed, people send them to an alias and then they are redirected to the real address? –  tacos_tacos_tacos Jun 18 '12 at 23:16
    
Mail is addressed to user@virtualmachine.virtualdomain.com. This is a CName for realmachine.realdomain.com. Most mailers do not muck with the address, but instead hand off the mail to realmachine with the virtualmachine.virtualdomain.com address intact. Our local machine then correctly sorts things out. However I've discovered one remote machine that rewrites the internal address of the mail from user@virtualmachine.virtualdomain.com to user@realmachine.realdomain.com before handing it to realmachine. Trying to find out if I should be accounting for this sort of thing or if it's wrong. –  Shannon A. Jun 18 '12 at 23:51
    
Which header does it modify? –  David Schwartz Jun 19 '12 at 1:03
    
I see the change in the Received: headers. The Received: header for the user's machine says that it's delivery for <user@virtualmachine.virtualdomain.com> and then when the user's ISP hands it off to my realmachine, that Received header says that its For <user@realmachine.realdomain.com>. The "To:" address still seems to be virtualmachine by the time I see it, but "Delivered-To:" and (oddly) "X-Original-To:" both reflect realmachine. My own maillogs also exclusively show the realmachine address (and the mail is clearly delivered as if it were addressed to realmachine). –  Shannon A. Jun 19 '12 at 1:16
    
It sounds like the only headers affected are headers whose semantics aren't well-defined anyway. –  David Schwartz Jun 19 '12 at 1:51

1 Answer 1

up vote 4 down vote accepted

Yeah, this behavior is wrong.. but enforcing RFC standards in SMTP is hopeless. To quote RFC 5321:

The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found, the resulting name is processed as if it were the initial name.

But, the sendmail MTA rewrites the recipient address by default, in violation of the RFC. The nocanonify feature, or the DontExpandCnames option, fix this.. but when you don't have control over the server that's messing with things, all you can do is work around it.

The RFC's phrasing was originally in RFC 2821, from 2001, but hilariously, the current sendmail documentation on DontExpandCnames to this day says, quote:

If set, $[ ... $] lookups that do DNS based lookups do not expand CNAME records. This currently violates the published standards, but the IETF seems to be moving toward legalizing this.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.