How doing relative name DNS lookups can shoot you in the foot
DNS-based host name lookups can be what I'll call 'relative', which look for the host name inside some domain, or 'absolute', which assumes that the host name is fully qualified and starts right from the root DNS. (For clarity, absolute names are often written with a trailing '.'; this can often be used to make resolver libraries treat them as absolute.)
Once upon a time, we had an interesting mail explosion. The campus wide mail servers started sending our server bouce mail addressed to various users at 'mail.com.cn'; our server accepted it (we're willing to relay mail for on-campus people), and it promptly sat around doing very odd things. In addition to the problems, this struck us as very odd; the campus wide mail servers do not normally smarthost outgoing mail through us.
What had happened was a DNS problem combined with relative name lookups:
- various spammers sent mail to nonexistent user names on the campus-wide mail system, using various forged mail.com.cn usernames as the origin address. Bounces ensued, and the mail servers tried to route them back to mail.com.cn.
- mail.com.cn's MX was just 'www.' (they probably intended 'www.mail.com.cn.').
- the campus-wide mail servers are utcc.utoronto.ca machines.
- 'www.utcc.utoronto.ca' is one of our server's aliases.
So the absolute 'www' of the MX wound up being looked up as a relative hostname in the mail server's domain, resulting in our server. Dutifully the mailer called us up and passed us the hot potato, whereupon very odd things happened because to our mailer it looked sort of like we ought to be handling mail for this domain, except it wasn't on our list of local domains.
(You might question the sanity of mailers trying relative name lookups in general. However, users usually like being able to write addresses as 'spamtrap1@utcc' instead of 'email@example.com'.)