1121455 - [email] Problems setting up a dreamhost account

Status: RESOLVED DUPLICATE of bug 1012495

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[Jonathan Watt [:jwatt]]

I had a lot of headaches trying to get the E-mail app to work with an e-mail account that I created to try and reproduce bug 1109315. After going down a lot of deadends it turns out that my SMTP server's domain name of mail.jwatt.org is in fact some sort of alias/redirect. The E-mail app doesn't seem to support whatever mechanism is used by my host, and it doesn't provide any information about what went wrong. It just fails to create the account in the app with no indication of whether the password/username, ports, host, etc. are wrong.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

You're using the sub3.mail.dreamhost.com cluster which only has a valid wildcard certificate for *.mail.dreamhost.com.  You need to use manual setup and use sub3.mail.dreamhost.com as the server name in both cases right now.

I would expect we would have been giving the bad-security error code message here since both IMAP and SMTP are expected to fail.  If you can provided a logcat as described at https://wiki.mozilla.org/Gaia/Email/RequiredBugInfo, that would be most useful to be able to identify if something is breaking in an unexpected way.  Otherwise a transcription of the error message (or a screenshot, see https://developer.mozilla.org/en-US/Firefox_OS/Debugging/taking_screenshots) is handy.  Either way, knowing the version of Firefox OS you are using is very important.

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

And note that we already have an autoconfig bug on dreamhost on bug 1012495; when checking out your domain I noticed new MX behaviour which could be helpful to resolving that more easily.

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

Saw the other bug traffic that indicated you're definitely on 2.1/22 so I just did a quick autoconfig run on trunk and the results look expected for this scenario.  On trunk autoconfig fails and we're forced to use manual config.  We show the 'Unable to establish a secure connection with "mail.jwatt.org".  There may be a problem with your network or the server.' string.  The underlying probe failures look like:

===
WINF: [slog] probe:imap:connecting {"connInfo":{"hostname":"mail.jwatt.org","port":"993","crypto":"ssl"}}
WLOG: [slog] oauth:credentials-ok
WINF: [slog] probe:smtp:connecting {"connInfo":{"emailAddress":"[e-mail]","hostname":"mail.jwatt.org","port":"465","crypto":"ssl"}}
WLOG: [slog] oauth:credentials-ok
WLOG: [slog] smtp:connect {"usingOauth2":false,"connInfo":{"emailAddress":"[e-mail]","hostname":"mail.jwatt.org","port":"465","crypto":"ssl"}}
WERR: [slog] imap:normalized-error {"error":{"name":"SecurityCertificateDomainMismatchError","message":""},"errorName":"SecurityCertificateDomainMismatchError","errorMessage":"","socketLevelError":"bad-security","protocolLevelError":null,"reportAs":"bad-security"}
WERR: [slog] imap:connect-error {"error":"bad-security"}
WERR: [slog] imap:normalized-error {"error":"bad-security","socketLevelError":"bad-security","reportAs":"bad-security"}
WERR: [slog] probe:imap:error {"error":"bad-security"}
WLOG: [slog] smtp:analyzed-error {"rawError":{"name":"SecurityCertificateDomainMismatchError","message":""},"rawErrorName":"SecurityCertificateDomainMismatchError","rawErrorMessage":"","normalizedError":"bad-security","errorName":"SecurityCertificateDomainMismatchError","errorMessage":"","wasSending":false}
WERR: [slog] smtp:connect-error {"error":"bad-security","connInfo":{"emailAddress":"[e-mail]","hostname":"mail.jwatt.org","port":"465","crypto":"ssl"}}
WLOG: [slog] smtp:analyzed-error {"rawError":"bad-security","normalizedError":"bad-security","wasSending":false}
WERR: [slog] probe:smtp:error {"error":"bad-security","connInfo":{"emailAddress":"[e-mail]","hostname":"mail.jwatt.org","port":"465","crypto":"ssl"}
===

This is what I'd expect.  Other than making dreamhost autoconfig work properly, we have somewhat limited options as it relates to mismatched certificates.  We could potentially use a different error message when we're in manual config and/or link to a support.mozilla.org page and get a bad certificate and the MX entry told us something we didn't understand.  The message could be along the lines of "If you're using a personal vanity domain, it's possible you need to use the server name of the hoster rather than your own vanity domain."

A heuristic could be to see what names were in the certificate and potentially display them to help the user out.  The problem with that is that I don't think TCPSocket is giving that to us right now, and I'm not sure it ever well.  Additionally, if there is an attempt to MITM and the attacker has a valid certificate with a reasonable-ish domain name, we run the risk of just having the user type that name in.

Comment 4

[Jonathan Watt [:jwatt]]

To be clearer, I'm not saying that there's not debug output, but rather that the normal Firefox OS user will have no clue what went wrong. I'm referring to the lack of helpful feedback in the UI (no "certificate mismatch" message).

I believe the reason this isn't an issue my Thunderbird install is because it asked me if I wanted to add an exception at some point, which I must have done. If the FxOS app doesn't want to offer that option, the aforementioned message would seem like a reasonable minimal bar.

(In reply to Andrew Sutherland [:asuth] from comment #3)
> We could potentially use a different error message when we're
> in manual config and/or link to a support.mozilla.org page and get a bad
> certificate and the MX entry told us something we didn't understand.  The
> message could be along the lines of "If you're using a personal vanity
> domain, it's possible you need to use the server name of the hoster rather
> than your own vanity domain."

Sounds better, but "vanity" would be wrong. Using my own domain for email is nothing to do with vanity and everything to do with having my own mail server to avoid having my mail stored by Google or whoever.

Comment 5

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Jonathan Watt [:jwatt] from comment #4)
> To be clearer, I'm not saying that there's not debug output, but rather that
> the normal Firefox OS user will have no clue what went wrong. I'm referring
> to the lack of helpful feedback in the UI (no "certificate mismatch"
> message).

I absolutely agree that we shouldn't expect users to look at the debug output!  In this case, from the information you provided it sounded like you were receiving a generic error message rather than our bad-security error message.  We recently had a bug along those lines, and the log output is the only way to determine what is actually going on under the hood.

> I believe the reason this isn't an issue my Thunderbird install is because
> it asked me if I wanted to add an exception at some point, which I must have
> done. If the FxOS app doesn't want to offer that option, the aforementioned
> message would seem like a reasonable minimal bar.

Yes, Thunderbird offers the ability to add an exception using some chrome-privileged stuff, the main hazard being even security professionals usually don't verify the fingerprint or key (although maybe in the mismatch case NSS/Toolkit do all the rest of the verification except the mismatch?  Not so bad in that case if the UI is making it clear.  If it's ambiguous when NSS gave up on the check, that would be bad.).

FxOS apps aren't capable of doing this and there is currently no system UI to add exceptions either.  Bug 769183 and bug 867899 cover making the system capable of doing this.  Bug 874346 is the bug about making the email app provide a footgun-ish option to move the user in that direction that's nominally WONTFIX as it relates to the Thunderbird approach but could be acceptable with some non-trivial mitigations.

> Sounds better, but "vanity" would be wrong. Using my own domain for email is
> nothing to do with vanity and everything to do with having my own mail
> server to avoid having my mail stored by Google or whoever.

Ah, yeah, the term vanity domain is pretty judgey, but it's a commonly used term, I swear!  (And I have several! :).  Although when I went to http://en.wikipedia.org/wiki/Vanity_domain to prove I'm not a jerk, it turns out it is a bit judgey too.  (Unfortunately "personal domain" doesn't imply the same semantics, since a personal domain could also be a VM running an actual mail server.  And saying something like "CNAMEd domain" is too technical and such.  I'll try hosted mail with custom domain or something like that in the future.)

Such is the trouble we face with these error messages; on all the pre-flame devices there's very little screen real estate and especially when we get into SSL/TLS issues, the problem is usually more that the user's mail provider fails to have valid certificates at all!  (This used to be the case for dreamhost, they were their own CA.)

The security error pre-dates the ability to detect domain mismatches.  I'll spin off a bug about providing a new error string for domain mismatches (*that otherwise appear valid*) now and will "see also" it, but I'm going to dupe this bug to the dreamhost autoconfig bug because that is really the best solution to this specific scenario.  Dreamhost's weird cluster setup just really complicates things, otherwise we could easily do what we do so that all gmail-hosted mail with custom domain stuff works.

Comment 6

[Jonathan Watt [:jwatt]]

Thanks for taking the time to give such an informative reply, Andrew!

(In reply to Andrew Sutherland [:asuth] from comment #5)
> Ah, yeah, the term vanity domain is pretty judgey, but it's a commonly used
> term, I swear!  (And I have several! :).  Although when I went to
> http://en.wikipedia.org/wiki/Vanity_domain to prove I'm not a jerk, it turns
> out it is a bit judgey too.

Ah, heh, good to know. :)