Closed Bug 874348 Opened 11 years ago Closed 11 years ago

[Buri][Email]Failed to send and receive mail with 163 exchange account

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

(b2g18 affected, b2g18-v1.0.1 wontfix)

RESOLVED FIXED
Tracking Status
b2g18 --- affected
b2g18-v1.0.1 --- wontfix

People

(Reporter: sync-1, Assigned: squib)

References

Details

Attachments

(4 files)

AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.019.111
 Firefox os  v1.0.1
 Mozilla build ID:20130518070208
 
 +++ This bug was initially created as a clone of Bug #456058 +++
 
 DEFECT DESCRIPTION:
 Failed to send and receive mail with 163 exchange account 
 
  REPRODUCING PROCEDURES:
 Case 1:
 1.Create a 163 account automatically;The email type will be exchange;
 2.Fail to send or receive mail with the account-->ko
 Case 2:
 3.Create a 163 exchange account manually;
 4.Fail to send or receive mail with the account-->ko
 
 
  EXPECTED BEHAVIOUR:
 Can send and receive mails with 163 exchange account
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:5/5
 
  For FT PR, Please list reference mobile's behavior:
 
 ++++++++++ end of initial bug #456058 description ++++++++++
 
 
 
 CONTACT INFO (Name,Phone number):
 
  DEFECT DESCRIPTION:
 
  REPRODUCING PROCEDURES:
 
  EXPECTED BEHAVIOUR:
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:
Clone from brother
Attached file log
Clone from brother
163 exchange account? 
Did you mean tech.163.com?
Flags: needinfo?(sync-1)
I'm not 100% clear on what the .qmdl log file is, but whatever it is, it doesn't seem to have any useful info for the e-mail app inside it.

Please provide "adb logcat" style logs as described in https://wiki.mozilla.org/Gaia/Email/RequiredBugInfo
Status: NEW → UNCONFIRMED
Ever confirmed: false
(In reply to comment #1)
 > Comment from Mozilla:163 exchange account? 
 > Did you mean tech.163.com?
 > 
 
 No,the server is i.163.com;
 In fact,the 163 is predifined; When input right username and password,then 163
 exchange account will be created automatically;
Flags: needinfo?(sync-1)
Created an attachment (id=415213)
 new log
Attached file new log
Created an attachment (id=415213)
 new log
(In reply to comment #2)
 > Comment from Mozilla:I'm not 100% clear on what the .qmdl log file is, but
 > whatever it is, it doesn't seem to have any useful info for the e-mail app
 > inside it.
 > 
 > Please provide "adb logcat" style logs as described in
 > https://wiki.mozilla.org/Gaia/Email/RequiredBugInfo
 > 
 
 see new log.
 thanks.
Whoa.  So, the server in question seems to terrifyingly support very little functionality:

Error: This server doesn't support the command FolderSync
Error: This server doesn't support the command SendMail

This suggests either a weird protocol version or we failed to follow a server bounce to the right server or something like that, but Jim would probably have better ideas.

Can you provide information on the exchange server in use and provide credentials for a test account?  It would probably be best if you mail the credentials to asuth@mozilla.com and jporter@mozilla.com rather than posting them in the bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(sync-1)
It's probably not a real Exchange server, and isn't reporting what commands it supports. The ActiveSync code has some sanity checks to make sure we don't run unsupported commands. While we could remove them, I plan on using these checks in more places as we support more versions of ActiveSync, since feature detection seems like it would be a lot safer than checking arbitrary version numbers.
(In reply to Andrew Sutherland (:asuth) from comment #9)
> Whoa.  So, the server in question seems to terrifyingly support very little
> functionality:
> 
> Error: This server doesn't support the command FolderSync
> Error: This server doesn't support the command SendMail
> 
> This suggests either a weird protocol version or we failed to follow a
> server bounce to the right server or something like that, but Jim would
> probably have better ideas.
> 
> Can you provide information on the exchange server in use and provide
> credentials for a test account?  It would probably be best if you mail the
> credentials to asuth@mozilla.com and jporter@mozilla.com rather than posting
> them in the bug.

Have sent information and credentials from *****@tcl.com.
Flags: needinfo?(sync-1)
For now, we'll assume Jim will investigate this and provide more info.
Flags: needinfo?(squibblyflabbetydoo)
Ok, so the issue here is that this server gives us a URL with "Microsoft-ActiveSync-Server" already appended, which we don't expect. This should be easy enough to fix, but in order to do that, I'll have to play some games with moving the repos around so that I can make a proper fork of mozilla-b2g/jsas.
Flags: needinfo?(squibblyflabbetydoo)
Jim, does this just mean changing Connection.open so that its baseUrl computation will not append '/Microsoft-Server-ActiveSync' if it's already present, or is there something more to do?
I believe so, yes. I'll put up a patch later today/tomorrow.
PR up for the jsas part: https://github.com/mozilla-b2g/jsas/pull/12

I'm not totally sure I'm happy with the way I'm doing things; see my comments over on Github.
Attachment #792622 - Flags: review?(bugmail)
Comment on attachment 792622 [details] [review]
https://github.com/mozilla-b2g/jsas/pull/12

r=asuth, deeper comments on github, but in general the approach seems fine and preferable if the fix is going to end up uplifted.  Feel free to file a follow-up bug to clean things up more if you'd really like us to eventually converge to your other proposal.  The one thing I would worry about in terms of explicitly setting autoconfig entries or the like is just that it wouldn't surprise me if other ActiveSync servers just follow hotmail's lead and don't specify the service endpoint.
Attachment #792622 - Flags: review?(bugmail) → review+
leo? as this may provide a more robust solution to Bug 914520 - [Buri][Shira-51525][Settings]Not possible to setup T-Online and Web.de Email account.
blocking-b2g: --- → leo?
(In reply to Joe Cheng [:jcheng] from comment #20)
> leo? as this may provide a more robust solution to Bug 914520 -
> [Buri][Shira-51525][Settings]Not possible to setup T-Online and Web.de Email
> account.

Do we know for sure that this is needed to fix the bug 914520 problem?
Flags: needinfo?(jcheng)
Build info:
Firefox os  v1.1
Mozilla build ID:20130916041201

I cann't setup t-online account automatically after I merged the "https://github.com/mozilla-b2g/gaia/commit/2f6487c57a1ee4bc1df8126b90e69df48095b115" patch.

In addition, if I merge the patch except the code of ln2592~2594, The t-online account is OK and the 163 account is OK too.
Triage - We're thinking of blocking on this, but I need more information from Andrew about why comment 22 indicating this isn't working.

Andrew - Can you clarify?
Flags: needinfo?(bugmail)
The situation as it relates to comment 22 is this:

There is something that looks like an autodiscover server on autodiscover.t-online.de.  It returns 403 for an apparently valid account using both my t-online.de 'web' password and my 'email client' password.  (I was able to use the same credentials to create an IMAP/SMTP support via manual setup.)

This breaks automatic account creation because we have special logic in accountcommon.js in _getConfigFromAutodiscover where if the error is an HttpError with status 401 or 403 we map the error to specific error types (401: bad-user-or-pass, 403: not-authorized).  We treat these error codes as fatal, which stops the entire autoconfiguration process.

By not uplifting lines 2592-2594 in comment 22, the attempt to probe 'autodiscover.t-online.de' gets skipped entirely after our prior attempt to probe 't-online.de/autodsicover/autodiscover.xml' fails.  Specifically, there is no server there so the XHR onerror event triggers.  Our JSAS autodiscover() code only retries 'autodiscover.DOMAIN' if the error was of type AutodiscoverDomainError or HttpError, which a general Error is not.


I don't actually know how to make t-online.de's ActiveSync implementation work for us.  Jim is working on some autodiscovery improvements; maybe that can help?

For the current time, it seems like what we want to do across 1.1, 1.2, and trunk is to just copy the Thunderbird ISP Database entry for t-online.de into our distribution so we bypass the ActiveSync autodiscovery process entirely.  In general, we prefer IMAP as a protocol over ActiveSync, so this isn't crazy.
Flags: needinfo?(bugmail) → needinfo?(squibblyflabbetydoo)
(In reply to Andrew Sutherland (:asuth) from comment #24)
> By not uplifting lines 2592-2594 in comment 22, the attempt to probe
> 'autodiscover.t-online.de' gets skipped entirely after our prior attempt to
> probe 't-online.de/autodsicover/autodiscover.xml' fails.  Specifically,
> there is no server there so the XHR onerror event triggers.  Our JSAS
> autodiscover() code only retries 'autodiscover.DOMAIN' if the error was of
> type AutodiscoverDomainError or HttpError, which a general Error is not.

This part's not actually true. jsas handles the first 403 internally and retries with 'autodiscover.t-online.de' before passing anything back to GELAM.

I'm still trying to figure out why we're getting a 403 in the first place, though.
Flags: needinfo?(squibblyflabbetydoo)
Flags: needinfo?(jcheng)
Uplift of this patch is not required to completely resolve bug 914520; clearing leo?.  Please see https://bugzilla.mozilla.org/show_bug.cgi?id=914520#c40 for more details.
blocking-b2g: leo? → ---
Attachment mime type: text/plain → text/x-github-pull-request
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: