On 03/15/2019 06:03 AM, Gary wrote:
Is there some reason to use a mail.domain.com cert for mail rarher than just using domain.com for everything?
Historically the subdomain were used because they were on different hardware. That is www was on one machine and mail was on another.
Actually *THE* original approach was a) to make ftp.mydom.ain a CNAME to machine4711.mydom.ain or similar, b) attaching that latter (usually by A and PTR RRs) to the physical hardware for its lifetime, and c) use the naked mydom.ain for e-mail addresses and thus, since MX RRs did not yet exist back then, have its A or CNAME RR point to your incoming SMTP server.
When it became apparent that using the domain name - typically representing your organization as a whole - for a specific service wasn't *that* bright an idea, the e-mail aspect was repaired by the introduction of MX RRs. During the time that took to get implemented everywhere, other services still used ftp.*, gopher.*, what have you, even the early www.* .
Then came the day when Eric Allman decided that the new version of sendmail shall replace CNAMEs in e-mail addresses, local admin's opinion on the matter and existing working setups be damned. As far as I can tell, *that's* what ended the era of the "functional names shall be CNAMEs" paradigm.
*Today* web designers opine that an organization's website is *so* important that it merits repeating the old error of putting it under mydom.ain instead of www.mydom.ain, even if it's hosted someplace that's not under *your* control in the first place. I'm fighting that wherever I can (and unlike many of those "professionals", I *do* have the technology at hand to have something respond to HTTP(S) at mydom.ain and throw back a HTTP redirect to www.mydom.ain).
Regards,
Jochen Bern Systemingenieur
www.binect.de www.facebook.de/binect