1112549 - [FFOS2.0][Woodduck][Email]Can not create 163 email account in Email app

Status: RESOLVED DUPLICATE of bug 1105573

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

Description

[sync-1]

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 1

[sync-1]

Attachment: Email log

Comment 2

[sync-1]

Attachment: log

Comment 3

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

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

[Josh Cheng [:josh]]

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!

Comment 5

[sync-1]

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

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

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

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

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

[Jeffrey Stedfast]

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.