One has to distinguish between what domain names the mailserver is to accept mail for and what DNS has for MX hostnames. There is absolutely no relation between the two, due to the MX hostname. uh oh, do I hear the footsteps of Mr. MisInformation Policeman?Our IMail server has both the mail.example.com and example.com set.
Our ISP refused to point mail toward us unless I had it set as mail.example.com.wow, change ISP's, he doesn't understand mail or DNS. Such an imposition is as unheard of as it is useless.
wildcards and CNAMEs work ok, but a lot of people screw them up, so I recommend not using them. People have enough trouble with basic DNS, without complicating their lives unnecessarily with tricky DNS.Talk about confusing.. I thought that within a DNS record one could basically just add *.example.com for whatever would bang against the TLD.
jeez, change ISP's. How does his get from his erroneous "most" do it, to "everybody in my shop MUST do it"? amazingThere reasoning was that most email servers all have the MX records set to mail.example.com.
Some of the worst things a mailserver/DNS admin can do when setting up is
1) run as open relay (do the latest versions of Imail still install as closed relay or default to open?)
2) and then don't tell their 1000's of users that they must use SMTP AUTH from day one.
3) use only one DNS hostname, mail.domain.com, for all the different mail-related services,
4) and then tell 1000's of users to put mail.domain.com in their address books and in their mail client programs for both SMTP, POP/IMAP, webmail server, so the "mail.domain.com" straightjacket is effectively written in stone and expensive to change.
So what's a better naming approach?
(List veterans can stop here, newbies should read on)
Every domain.com should elaborate a different DNS label for each mail function, and be as "self- documenting/explanatory/banal/generic/plumbing" as possible. Exotic, crytpic names are to be avoided. Users (ad your marketing person) might remember them, find them cute, but tomorrow morning they don't remember what they DO.
And mail programs don't ask users to enter the names of their Uranus server or their Aristotle server, they ask users to enter the names of the SMTP server, of the POP3 server, so align your DNS labels with that:
mx1.domain.com ; where Internet sends mail (not used/seen by users)
smtp.domain.com ; where users send their outbound mail (enter this in mail program)
pop.domain.com ; where users read their mailboxes(enter this in mail program)
imap.domain.com ; where users read their mailboxes(enter this in mail program)
webmail.domain.com ; where users do webmail (enter this in browser bookmarks)
mail.domain.com ; where confusion reigns (enter this in round file, where possible)
If you support both SMTP AUTH and pop-before-SMTP, that's two functions and so needs two labels.
smtpsend.domain.com ; it's your call, but still don't get exotic and cryptic
Another restricting misconception is that DNS MX records must be this way:
domain.com. MX 10 mx1.domain.com.
ie, that the domain.com must be in both left and right fields. Not true, eg, for a hosting service:
anydomain.com. MX 10 mx1.hostingservice.com.
The MX right-hand RDATA field can contain any FQDN and it should be canonical (not an alias, not a CNAME).
With this DNS naming scheme, the mail/dns admin person is free to define and change the ip addresses for each mail-related sub-domain to whatever he wants, whenever he wants, without ever telling the users to change anything. This is As Good As It Gets.
Sure, 6 or 7 labels is harder to enter into an MS GUI to setup in every domain than is 1 label (and even harder to change for 1000 domains), but talk to MS about why their DNS GUI is so hard to use. The above scheme is extremely simple to setup and maintain with BIND using $INCLUDE directives.
That's just the forward domain. The reverse domain is easy, if anybody's interested.
Len
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
