Don't support shortened versions of your domain names in email addresses

July 14, 2015

I'll start with the basic background: the university here is divided up into a lot of departments and divisions and groups and so on. Most of them have subdomains under our top level domain, for instance cs.utoronto.ca (and then hosts under their subdomain), and many of them run (or ran) their own email systems, creating email addresses like <user>@cs.toronto.edu.

We have been providing email to people for what is now quite a long time. Way back at the beginning of that time, so long ago that DNS itself was very shiny and new, we decided to let people send email using shortened versions of all of the university's subdomains. Rather than having to send email to '<user>@ece.toronto.edu', you could send it to just '<user>@ece' and the mail system would work out where it should really go. This saved a bunch of people a bunch of typing back in the days when you had to type all of the email addresses out and was much appreciated.

Of course people got used to using these short domain names. Of course people put them everywhere, because they were generally supported; you could put them in .forward files, you could put them in simple mailing lists, and so on. And as a result of this, of course we've never depreciated this feature.

If you guessed that supporting this feature in modern MTAs is a slowly increasing amount of work, you're correct; it absolutely is. If you guessed that it kind of goes wrong sometimes, you're also correct (I discovered a case today). So I have a simple suggestion: if you're tempted to do this because it sounds like a neat convenience feature, don't. Forcing everyone to use fully canonicalized domain names will make your life much simpler and will avoid a certain amount of pain.

(It's probably going to get worse, since DNS keeps growing more and more weird top level domains. Sooner or later we're going to have a serious collision between a new one and one of our own subdomains.)

The hard thing about this is that I don't think we were wrong to support shortened versions of the university domains way back when, and depreciating them at any time since then would undoubtedly have been a lot of work and not have been appreciated at all. But I still think that in the modern world it would be better if we weren't supporting them any more. In a world with MUAs that have address autocompletion and so on, I think they're not necessary and they do cause problems.

(When I say that 'we' did this way back when, I mean the people who were sysadmins here in those days, not me personally.)

Sidebar: one way to have a collision heartburn

Suppose that you have a university subdomain, let's call it aa for illustration; this subdomain has a wildcard A record for its own reasons. There's also a aa TLD (here it would be a country), and one of your users tries to send email to '<user>@misspelled.aa'. With the best of intentions, your MTA is almost certainly going to wind up trying to deliver this email to the aa subdomain wildcard A record instead of rejecting it as 'no such domain exists'.

(If the target of the A record doesn't respond to SMTP connections, your MTA will be retrying it for some time (especially if you've configured high timeouts for in-university addresses).)


Comments on this page:

By Dan.Astoorian at 2015-07-15 11:47:41:

I already started tripping over this a while ago, and not just in the context of e-mail.

Around the beginning of December, I started getting "remote host identification has changed" warnings when trying to ssh to "[redacted].engineering" (rather than "[redacted].engineering.utoronto.ca"); someone had created a top-level .engineering domain, with an A-record of 127.0.53.53 and an MX record pointing at "your-dns-needs-immediate-attention.[redacted].engineering". This placeholder seems to be gone now, probably because the .engineering TLD has gone into service.

Unfortunately, the only practical approach I could take to address this was to blacklist the TLD in our caching DNS servers, since it is unacceptable for our local users to potentially be directed to an arbitrary third party if they forget that they can't use the shortened domain anymore. So if any of our users want to visit the global www.engineering website, too bad for them.

Of course, this doesn't help if users in other departments try to use the shortened names....

--Dan

By Miksa at 2015-07-15 16:38:19:

In hindsight it turns out that choosing the subdomain .it.university.tld for the IT department's computers and servers wasn't the right choice. I learned this myself while trying to ssh into my brand new virtual server using the short name, but my password just would not work.

We should probably block the .it TLD from our DNS, why would anyone need to visit italian sites from a european university anyway.

Written on 14 July 2015.
« My personal view of OpenBSD
Mdb is so close to being a great tool for introspecting the kernel »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Jul 14 00:15:46 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.