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)
Tracking
(b2g18 affected, b2g18-v1.0.1 wontfix)
RESOLVED
FIXED
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:
Comment 4•11 years ago
|
||
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)
(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.
Comment 9•11 years ago
|
||
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)
Assignee | ||
Comment 10•11 years ago
|
||
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.
Comment 11•11 years ago
|
||
(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)
Comment 12•11 years ago
|
||
For now, we'll assume Jim will investigate this and provide more info.
Flags: needinfo?(squibblyflabbetydoo)
Assignee | ||
Comment 13•11 years ago
|
||
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)
Comment 14•11 years ago
|
||
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?
Assignee | ||
Comment 15•11 years ago
|
||
I believe so, yes. I'll put up a patch later today/tomorrow.
Assignee | ||
Comment 17•11 years ago
|
||
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 18•11 years ago
|
||
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+
Comment 19•11 years ago
|
||
landed on jsas/master: https://github.com/mozilla-b2g/jsas/pull/12 https://github.com/mozilla-b2g/jsas/commit/bcaa30e6269a58f21b2152505a5a2a1c0e91c7fb merged into jsas/worker-thread (the branch we actually use for GELAM): https://github.com/mozilla-b2g/jsas/commit/b953c81b8dad7be4a4cc7a228e69fcef3df5a107 landed on gaia-email-libs-and-more/master: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/237 https://github.com/mozilla-b2g/gaia-email-libs-and-more/commit/ca1b0838d124ca6f6eedf2b0c12a27a28bdf519c landed on gaia/master: https://github.com/mozilla-b2g/gaia/pull/11651 https://github.com/mozilla-b2g/gaia/commit/2f6487c57a1ee4bc1df8126b90e69df48095b115 This uplifts to v1-train cleanly if it's desired on leo/v1-train.
Assignee: nobody → squibblyflabbetydoo
Status: NEW → RESOLVED
Closed: 11 years ago
status-b2g18:
--- → affected
status-b2g18-v1.0.1:
--- → wontfix
Resolution: --- → FIXED
Comment 20•11 years ago
|
||
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?
Comment 21•11 years ago
|
||
(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)
Comment 22•11 years ago
|
||
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.
Comment 23•11 years ago
|
||
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)
Comment 24•11 years ago
|
||
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)
Assignee | ||
Comment 25•11 years ago
|
||
(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)
Updated•11 years ago
|
Flags: needinfo?(jcheng)
Comment 26•11 years ago
|
||
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? → ---
Updated•11 years ago
|
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.
Description
•