DH mail servers' security borked?


I have two existing email addresses defined for my domain hosted on DH (let’s call it mydomain.com); I access them via secure IMAP (SSL, port 995) on the usual address mail.mydomain.com, and send mail via secure SMTP (TLS, port 25), both using password authentication. Both work nicely.

I had also created a few months ago an unused backup mail account (no shell accesss) for a family member family@mydomain.com (with the usual Dreamhost mXXXXXX mailbox ID). I tested it back then and it worked. This morning (EST) I needed to use it, but I had not noted the original password: no problem, I just gave it a new one in panel.dreamhost.com. A little while later I was able to log onto that account at mailboxes.mydomain.com, changed some of the Inbox message retention parameters. Two hours later I tried family@mydomain.com with the Thunderbird email client, using the settings listed on mailboxes.mydomain.com. Neither IMAP nor SMTP connections would authenticate, no matter what flavour I tried. Nor could I log on to webmail.mydomain.com using family@mydomain.com.

Thinking that the old standby mail account might have been silently borked, I deleted it, waited until I could no longer log into mailboxes.mydomain.com under that email ID, and then created it anew (of course the mXXXXX mail account ID changed) with the same password as the old one. Again I was able to log into mailboxes.mydomain.com, but not connect via IMAP, SMTP or webmail. What on earth is going on? What mistakes have I made?

Furthermore, suddenly the Dreamhost secure servers were using a new self-signed server certificate with these absolutely confidence inspiring generic details:

E = root@localhost.localdomain CN = localhost.localdomain OU = IT O = MyCompany L = Seattle ST = WA C = USinstead of the older self-signed certificate

E = support@dreamhost.com CN = mail.dreamhost.com OU = DreamHost Security O = DreamHost Web Hosting L = Los Angeles ST = CA C = USwhich at least had the merit of identifying who the server might possibly belong to.

As it stands now, I feel inclined to suspect that some amateur on the DH support team is fiddling around with production mail servers, rather than testing certificate changes on a test server and verifying that the new certificates are correctly signed and issued.

Also, these kind of security certificate changes should be a category 5 announcement to DH customers listing the certificate thumbprint and the Issuer details, so that there are no reasons to suspect security breaches. Even better, why not list the details of current server certificates issued by DH on your support website (not the Wiki, since anybody can change that).

And finally: DH has automated so many aspects of its provisioning, isn’t there some way to automatically generate and install an email server SSL certificate for each domain that a customer defines in the Panel (i.e. a certificate for mail.mydomain.com). It would only need to depend (in the trust hierarchy) on a self-signed “root” DH certificate, but it would avoid those “domain name mismatch” messages from browsers and email clients.

Anyway, despite these problems, I also have to say that DH email service is usually quite reliable, if at times rather slow.

Insert Real Name
insertrealname AT DELETEyahoo.ca