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
email@example.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
firstname.lastname@example.org 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
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 = email@example.com
CN = localhost.localdomain
OU = IT
O = MyCompany
L = Seattle
ST = WA
C = USinstead of the older self-signed certificate
E = firstname.lastname@example.org
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