1013026 - [OPENC_1.3] Unknown Exchange account does not work.

Status: RESOLVED INVALID

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

Description

[RuiLi]

Attachment: exchange_2014-05-20-10-35-18.7z

User Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36

Steps to reproduce:

Add a 163 exchange account. But fail to work. I see an Error in the log.
'E/GeckoConsole(  287): [JavaScript Error: "i.163.com:443 uses an invalid security certificate.'

Comment 1

[RuiLi]

Attachment: 2014-12-16-07-12-54.png

Comment 2

[Beatriz Rodríguez [:brg]]

Dup of 874346 ?

Comment 3

[RuiLi]

It also seems same as 874348. Does it?

Comment 5

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

2 things:
- We do not support ActiveSync on 163.com because its implementation has been repeatedly non-complaint with the spec.  That's why we have an autoconfig entry that forces 163.com to use IMAP.
- Your device's clock is set incorrectly.  From the log:

12-16 07:13:06.863 E/GeckoConsole(  287): [JavaScript Error: "i.163.com:443 uses an invalid security certificate.
12-16 07:13:06.863 E/GeckoConsole(  287): 
12-16 07:13:06.863 E/GeckoConsole(  287): The certificate expired on 12/02/14 15:08. The current time is 12/16/14 07:13.
12-16 07:13:06.863 E/GeckoConsole(  287): 
12-16 07:13:06.863 E/GeckoConsole(  287): (Error code: sec_error_expired_certificate)
12-16 07:13:06.863 E/GeckoConsole(  287): "]

All of the relevant 163.com servers have valid certificates: i.163.com, imap.163.com, etc.


:jsmith, please don't dupe to bug 874346 unless you've verified that the server in question has an invalid certificate and there aren't other valid domain paths, etc.  It's a contentious bug with a lot of discussion already and I think it's better for the health of the discussion on that bug if we only dupe things to that bug that we are absolutely sure are a case of the server having an invalid certificate.

Comment 6

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

Er, and note that bug 907435 is our bug on improving the error message in these cases, since it is still fairly common for devices to have incorrect timestamps, at least for developers/testers.

Comment 7

[RuiLi]

We set clock correctly and tested it again, and failed to work yet. I attached the log. Please help to check it. Thank you.
(In reply to Andrew Sutherland (:asuth) from comment #5)
> 2 things:
> - We do not support ActiveSync on 163.com because its implementation has
> been repeatedly non-complaint with the spec.  That's why we have an
> autoconfig entry that forces 163.com to use IMAP.
> - Your device's clock is set incorrectly.  From the log:

Comment 8

[RuiLi]

Attachment: 163exchange_2014-05-22-09-47-16.zip

Comment 9

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

Right, the log indicates that there is no longer a bad-security problem, but just that 163.com's implementation does not comply with our understanding of the spec.

But as I mentioned in comment 5, we don't support 163.com's ActiveSync implementation for this reason.  I've widened the scope of bug 894785 so that we will blacklist 163.com's ActiveSync implementation too so we can try and avoid confusion about this in the future (when we fix the bug).

Can you indicate why you are trying to use ActiveSync with 163.com?  Is there a problem with our IMAP implementation?

Comment 10

[RuiLi]

Ok, I got that. Because 163 exchange is one of our test cases, we must know the reason that make it fail. Thank you.

Comment 11

[RuiLi]

Hi Andrew, the log '163exchange_2014-05-22-09-47-16.zip' I attached last time is not a test using 163.com. It's another Exchange server. I checked it with our testers. Do you know why it failed? Does it not comply with your Exchange implementation? Thank you.
(In reply to Andrew Sutherland (:asuth) from comment #9)
> Right, the log indicates that there is no longer a bad-security problem, but
> just that 163.com's implementation does not comply with our understanding of
> the spec.
> 
>

Comment 12

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

(In reply to RuiLi from comment #11)
> Hi Andrew, the log '163exchange_2014-05-22-09-47-16.zip' I attached last
> time is not a test using 163.com. It's another Exchange server. I checked it
> with our testers. Do you know why it failed? Does it not comply with your
> Exchange implementation? Thank you.

Can you clarify what Exchange server in use?  The logs provided indicate that attempts were made to contact servers running on 192.168.1.2 and 192.168.1.7.  These are private IPs and not globally routable, so I'd expect this to be the result of tunnelling or locally run test servers or something?

To be able to address something like this, we'd likely want to know the domain in question and to be provided with test credentials that we can use to test against the domain.  Knowing the specific server implementation in use can also be helpful.  Any credentials should be cc'ed to [e-mail], [e-mail], and [e-mail] since we are the people likely to investigate such a problem.