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
smime.p7s
Description: S/MIME Cryptographic Signature