Andrew Sutherland [:asuth] (he/him) Reporter
	Description • 10 years ago

Dreamhost keeps coming up as a deficiency in our autoconfig mechanism.  Dreamhost used to use their own certificate authority but has since cleaned up their act and now has a wildcard for *.mail.dreamhost.com.  (As a result, many people may be confused and think that dreamhost still uses their own certificate authority.)

Unfortunately, dreamhost runs an awkward server configuration with multiple mail clusters at the domains:
- sub3.mail.dreamhost.com
- sub4.mail.dreamhost.com
- sub5.mail.dreamhost.com
- homie.mail.dreamhost.com

Inbound mail per my vanity domain's MX goes through fltr-in2.mail.dreamhost.com and fltr-in1.mail.dreamhost.com.

This needs more investigation, and there are a variety of things we could do to try and make this work:
- Work with dreamhost to address the problem with us doing no new development:
  - Have dreamhost stand up an autoconfig server which maps the vanity domains to the appropriate server.  They do already provide this information in their dreamhost panel, so the info is available somewhere.
  - Have dreamhost use dovecot's proxying capabilities to expose a single imap.mail.dreamhost.com domain that does the mapping transparently under the hood.  (Dreamhost already uses dovecot.)
  - Have dreamhost change their MX entries so that we can map to per-cluster autoconfig entries we build into the app or host on the ISPDB.
- Work with dreamhost while also getting fancier ourselves:
  - Have dreamhost create SRV appropriate entries.  This requires the ISPDB or our platform to be capable of looking up SRV entries.  Since Apple clients and others may consume these SRV entries and they are nominally a standard, this is probably the most standard-for-the-buck option.
- Do stuff ourselves:
  - Extend the Gaia email autoconfig mechanism to do the thunderbird thing and try all of the (IMAP) options available in a row.  We'd basically try each cluster until we found one that would let us in.  We would an appropriate autoconfig entry for this.
  - Have the "dig mail.VANITYDOMAIN", "dig -x IP OF THAT SERVER" dance automatically happen on the ISPDB server as an additional heuristic like the MX heuristic.

	Gen Kanai [:gen]
	Comment 1 • 10 years ago

This bug has affected me. It works with the workaround that Andrew outlines but will cause problems moving forward. We should maybe work with Dreamhost to get documentation on their wiki.

http://wiki.dreamhost.com/Category:E-mail_Client_Configuration

	Andrew Sutherland [:asuth] (he/him) Reporter
	Comment 2 • 9 years ago

New situation!  I just did an MX lookup for someone else's account that is hosted on sub3, and the mx entries were mx1.sub3.homie.mail.dreamhost.com and mx2.  This is something we can easily regex/transform.

I no longer use dreamhost for mail, but was on sub4 previously; we'd want to check people on other clusters... it's possible this difference was due to sub3, or possibly due to dreamhost's recent changes after their spam servers were getting overloaded.

	BMO Automation
	Comment 4 • 6 years ago

Firefox OS is not being worked on