Closed
Bug 1112549
Opened 10 years ago
Closed 10 years ago
[FFOS2.0][Woodduck][Email]Can not create 163 email account in Email app
Categories
(Firefox OS Graveyard :: Gaia::E-Mail, defect, P2)
Firefox OS Graveyard
Gaia::E-Mail
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 1105573
People
(Reporter: sync-1, Unassigned)
References
Details
Attachments
(2 files)
Created an attachment (id=1074724) Email log DEFECT DESCRIPTION: Can not create 163 email account in Email app REPRODUCING PROCEDURES: 1,Lanuch Email app,input your name , account name and password; 2,Choose Manual setup,ACCOUNT TYPE choose IMAP+SMTP; 3,Input hostname (eg:imap.163.com/smtp.163.com),press next(the MS always pop up username or password invalid)->KO EXPECTED BEHAVIOUR: Should log in imap type Email account successfully ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT: REPRODUCING RATE: For FT PR, Please list reference mobile's behavior: ================================================================ Here is some log for email : 12-17 16:27:32.287 1397 1477 I Gecko : ^[[32mWLOG: PROBE:SMTP attempting to connect to smtp.163.com^[[0m 12-17 16:27:32.315 1397 1477 I Gecko : ^[[32mWLOG: PROBE:IMAP attempting to connect to imap.163.com^[[0m 12-17 16:27:33.065 1397 1477 I Gecko : ^[[32mWLOG: PROBE:SMTP connected, checking address validity^[[0m 12-17 16:27:33.299 1397 1477 I Gecko : ^[[33mWWAR: PROBE:IMAP sad. Error | NO | Error while executing request: EXAMINE The login is not safe! Please update your mail client: http://mail.163.com/dashi | EXAMINE The login is not safe! Please update your mail client: http://mail.163.com/dashi^[[0m 12-17 16:27:33.331 1397 1477 I Gecko : ^[[32mWLOG: PROBE:SMTP happy^[[0m
Comment 3•10 years ago
|
||
Ugh, so this is what we witnessed/documented on bug 1105573 for v2.1/v2.2. It appears sending an "ID" command with payload as part of our login process will placate the server, but since we have no idea what the server or server operator's rationale is, it's hard to be sure if that's good enough. We can certainly try and do that for v2.0.
Comment 4•10 years ago
|
||
Hi Andrew, We have previously already communicate to partner that China is not in launch country for now and agree to postpone. Please check https://bugzilla.mozilla.org/show_bug.cgi?id=991489#c18.I would still communicate with partner about this which we will fix in 2.1/2.2 per bug 1105573. Thanks!
https://bugzilla.mozilla.org/show_bug.cgi?id=991489#c18 I would suggest we leave this bug open. For woodduck, this should not be a blocker. since the user impact is small. 1) Most of 163 email users are in china. And China is not the target market for woodduck.
Comment 6•10 years ago
|
||
I think we might already be able to close this bug then, since for v2.1/v2.2 we have already implemented sending an IMAP "ID" directive. Specifically, we send this: ID ("vendor" "Mozilla" "name" "GaiaMail" "version" "0.2" "support-url" "http://mzl.la/file-gaia-email-bug") For my test account at 163.com, as far as I could tell, this made the server both: 1) Let me configure the account without throwing any IMAP errors. 2) Also seemed to avoid me receiving any emails that told me to use the Android app. At least when I'd sync over the next few days after implementing the fix. And just now when I recreated the account on a v2.2 trunk b2g-desktop build. (Noting that it looks a lot like my Inbox got emptied out? Maybe I was supposed to login every 30 days or they do that?) This is covered in further detail on bug 1105573. Even though I *think* things work okay now on v2.1/v2.2, I haven't closed that bug since it's still possible 163.com/126.com could decide to start generating those errors again for us and I want people to be able to find the bug/dupe to it. So I'm changing this bug to dupe to bug 1105573 for clarity.
Comment 7•10 years ago
|
||
Uh, and if someone wants to verify that things indeed do work better on v2.1/v2.2 and comment on that bug, that would be helpful. (Or if things don't work! That's also useful. I want us to work! :)
Comment 8•10 years ago
|
||
It's probably worth noting what the IMAP ID specification has to say regarding this error. Implementations MUST NOT make operational changes based on the data sent as part of the ID command or response. The ID command is for human consumption only, and is not to be used in improving the performance of clients or servers. This includes, but is not limited to, the following: Servers MUST NOT attempt to work around client bugs by using information from the ID command. Clients MUST NOT attempt to work around server bugs based on the ID response. Servers MUST NOT provide features to a client or otherwise optimize for a particular client by using information from the ID command. Clients MUST NOT provide features to a server or otherwise optimize for a particular server based on the ID response. Servers MUST NOT deny access to or refuse service for a client based on information from the ID command. Clients MUST NOT refuse to operate or limit their operation with a server based on the ID response. Pay close attention to the first sentence of the last paragraph that I pasted. 163.com is clearly violating this specification and, imho, being pretty dick-tastic to their users by attempting to force them to use their proprietary mail client against their will.
You need to log in
before you can comment on or make changes to this bug.
Description
•