Closed Bug 914520 Opened 11 years ago Closed 11 years ago

[Buri][Shira-51525][Settings]Not possible to setup T-Online and Web.de Email account.

Categories

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

defect

Tracking

(blocking-b2g:leo+, b2g18 fixed, b2g-v1.1hd fixed, b2g-v1.2 fixed)

RESOLVED FIXED
blocking-b2g leo+
Tracking Status
b2g18 --- fixed
b2g-v1.1hd --- fixed
b2g-v1.2 --- fixed

People

(Reporter: sync-1, Assigned: asuth)

References

Details

Attachments

(10 files)

Firefox os  v1.1
  Mozilla build ID:20130828041203
 
 DEFECT DESCRIPTION:
 Not possible to setup T-Online and Web.de Email account
 
  REPRODUCING PROCEDURES:
 Description: 
 Currently it is not possible to create a new T-Online and Web.de Email account by using the wizard.
 After entering username and password there is only shown an error message.
 
 T-Online
 When manually configuring T-Online with correct IMAP settings (secureimap.t-online.de, Port 993) and SMTP settings (securesmtp.t-online.de, Port 587) the setup also fails!
 
 Web.de
 When manually configuring Web.de with correct IMAP settings (imap.web.de, Port 993) and SMTP settings (smtp.web.de, Port 587) the setup also fails!
 
 Remark:
 The POP3 T-Online Email settings which are listed in the ISD could not be entered, as the user interface only offers IMAP mode!
 In addition both accounts require STARTTLS in SMTP server settings in combination with port 587.
 This could not be configured in the Email client.
 
 Customer Impact Statement: 
 High number of customer care calls possible due to non working Email configuration.
 T-Online and Web.de are two of the most prominent Email accounts in Germany and also listed under the Top 5 ISD Email accounts.
 
 
 Expected Behaviour: 
 Email auto configuration is correctly working for Top 5 ISD Email accounts.
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:
Summary: [Buri][T-mobile 51525][Settings]Not possible to setup T-Online and Web.de Email account. → [Buri][Shira-51525][Settings]Not possible to setup T-Online and Web.de Email account.
QAWANTED to confirm this bug
Keywords: qawanted
I tried reproducing this with my "gmx.de" account and "web.de" account and was not able to reproduce. I was not trying this from the wizard but entering the settings.

perhaps we want to reach out to more users on b2g-release
The current code in-tree only supports port 465, also known as ssmtp/smtps.  It's the port where the connection starts out encrypted.

Port 587 is for startTLS which upgrades to an encrypted connection.  A gecko patch landed recently which means that we can now complete our startTLS support in bug 847032.  :mcav has a patch up for review by me; I expect it to land sometime in the next few days.

In general, we want to prefer using port 465 over port 587 because we can establish it faster.

I understand GMX seems to actually run two separate services spread over various domain names, so that's a little confusing and needs more research.  In my quick poking just now, it seemed like there might be also be some certificate complications that will need to be investigated.
Depends on: 847032
blocking-b2g: --- → leo?
For the leo nom - find out in the qawanted request as well if this reproduces on 1.01.
impacting DE users. blocking
blocking-b2g: leo? → leo+
QA Contact: laliaga
QA Contact: laliaga
I actually see this problem with web.de. When I tried the wizard it failed too. Sadly the error messages are not that verbose:

I/Gecko   (19844): WLOG: Attempting to get autoconfiguration for web.de
I/Gecko   (19844): WLOG:   Looking in GELAM
I/Gecko   (19844): WLOG:   Looking in local file store
I/Gecko   (19844): WLOG:   Looking at domain
E/GeckoConsole(19844): [JavaScript Error: "not well-formed" {file: "app://email.gaiamobile.org/index.html" line: 1324 column: 184 source: "            <span class="button-wrapper button-small"><a wicket_id="lotto.jackpot.service" href="https://lotto.web.de/webshop/product/lottonormal/?partnerId=0WEHOM0HOM&advertisementId=0HPMODU000000000000000000000000000000000000"><span>Zum Lottoservice</span></a></span>"}]
I/Gecko   (19844): WLOG:   Trying domain autodiscover
D/memalloc(19844): /dev/pmem: Unmapping buffer base:0x45cb2000 size:7200768 offset:6586368
E/GeckoConsole(19844): [JavaScript Error: "not well-formed" {file: "app://email.gaiamobile.org/index.html" line: 1324 column: 184 source: "            <span class="button-wrapper button-small"><a wicket_id="lotto.jackpot.service" href="https://lotto.web.de/webshop/product/lottonormal/?partnerId=0WEHOM0HOM&advertisementId=0HPMODU000000000000000000000000000000000000"><span>Zum Lottoservice</span></a></span>"}]
I/Gecko   (19844): WLOG:   Looking in the Mozilla ISPDB
I/Gecko   (19844): WLOG:   Looking up MX
I/Gecko   (19844): WLOG:   Found MX for web.de
I/Gecko   (19844): WLOG: FAILURE

Is there a way to make the last failure output more verbose? Is there any kind of debug option available?
Oh, in the display I see a little error text: [no-config-info(mxsame)]. Not sure if that helps.
:whimboo, you need a more recent gaia build; the fix only landed a few hours ago on bug 847032.  What's happening is we get the ISP database entry and then decide that we can't use it because the SMTP server needs STARTTLS and the builds prior to today's landing don't like that.  With the fix, we like it.  Nightly builds starting tomorrow should have it.  v1.1 builds should have it within a few days depending on how fast we can test and land the uplifts.  v1.0.1 won't get the fix.
(In reply to Andrew Sutherland (:asuth) from comment #8)
> :whimboo, you need a more recent gaia build; the fix only landed a few hours
> ago on bug 847032.  What's happening is we get the ISP database entry and
> then decide that we can't use it because the SMTP server needs STARTTLS and
> the builds prior to today's landing don't like that.  With the fix, we like
> it.  Nightly builds starting tomorrow should have it.  v1.1 builds should
> have it within a few days depending on how fast we can test and land the
> uplifts.  v1.0.1 won't get the fix.

Yep, I asked whimboo to see if he could reproduce it first, since he has a web.de account (it was marked qawanted).   

Andrew, if bug 847032 is the correct fix for this, please nom it blocking-b2g=leo? so we can get it escalated via triage and uplifted asap.   Thanks.
Keywords: qawanted
Well, I have created an account to be able to test this. I will keep it until next week, once it has been backported and I can test it on b2g18. Thanks for letting me know.
I uplifted fixes to b2g18/v1-train yesterday.  They should now be in nightly builds or builds that should be done verrrrry shortly (I'm not used to being in European time zones).

I verified that Gaia should be able to consume both sets of ISP Database entries; it was just STARTTLS that was a problem for us.

:whimboo, I'm needsinfo-ing you to verify the bug.  Thanks for your assistance in this!  If it's possible for you to hold onto the account and provide the credentials on https://intranet.mozilla.org/Gaia/Email so we could quasi-automatically verify that in the future, that would be great.  If it involves paying money and you can't do a lump sum and expense it, it's probably easier for you to let the account drop.  (I've been having creating accounts in other countries so far because I lack a mailing address and in some places identification numbers.  I'm hoping when Mozilla Berlin opens, we can deal with the address problem!)
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: needinfo?(hskupin)
Resolution: --- → FIXED
Works fine now with:

Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/bebaca30ea30
Gaia   8b20ff956f8e366a17a7ef5f64935a6a6a8cb0c0
BuildID 20130915041201
Version 18.0

(In reply to Andrew Sutherland (:asuth) from comment #11)
> assistance in this!  If it's possible for you to hold onto the account and
> provide the credentials on https://intranet.mozilla.org/Gaia/Email so we
> could quasi-automatically verify that in the future, that would be great. 
> If it involves paying money and you can't do a lump sum and expense it, it's
> probably easier for you to let the account drop.  (I've been having creating
> accounts in other countries so far because I lack a mailing address and in
> some places identification numbers.  I'm hoping when Mozilla Berlin opens,
> we can deal with the address problem!)

We already have an office in Berlin for more than a year now. So nothing should hold us back from asking one of those guys working there, if they can create a Mozilla wide account for testing.
Flags: needinfo?(hskupin)
(In reply to Henrik Skupin (:whimboo) from comment #12)
> Works fine now with:
> 
> Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/bebaca30ea30
> Gaia   8b20ff956f8e366a17a7ef5f64935a6a6a8cb0c0
> BuildID 20130915041201
> Version 18.0
> 
> (In reply to Andrew Sutherland (:asuth) from comment #11)
> > assistance in this!  If it's possible for you to hold onto the account and
> > provide the credentials on https://intranet.mozilla.org/Gaia/Email so we
> > could quasi-automatically verify that in the future, that would be great. 
> > If it involves paying money and you can't do a lump sum and expense it, it's
> > probably easier for you to let the account drop.  (I've been having creating
> > accounts in other countries so far because I lack a mailing address and in
> > some places identification numbers.  I'm hoping when Mozilla Berlin opens,
> > we can deal with the address problem!)
> 
> We already have an office in Berlin for more than a year now. So nothing
> should hold us back from asking one of those guys working there, if they can
> create a Mozilla wide account for testing.

Henrik told me he has verified the fix on both t-online and web.de accounts.   TCL is free to pick up the patch from bug 847032 at their convenience.
Tested and is able to connect email to both t-online and web.de using the provided credentials.

Environmental Variables
Build ID: 20130917041200
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/b459ac3ebe24
Gaia: 862b5761825e010e3cc5968c096377e1ea54bbf2
Platform Version: 18.1

Performed with all passing: 
- Manual sync
- Automatic sync
- Receiving email
- Signing in with proper credentials
- Sending email with cc, bcc, subject, and body text
(In reply to Lucas A. from comment #14)
> Tested and is able to connect email to both t-online and web.de using the
> provided credentials.
> 
> Environmental Variables
> Build ID: 20130917041200
> Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/b459ac3ebe24
> Gaia: 862b5761825e010e3cc5968c096377e1ea54bbf2
> Platform Version: 18.1
> 
> Performed with all passing: 
> - Manual sync
> - Automatic sync
> - Receiving email
> - Signing in with proper credentials
> - Sending email with cc, bcc, subject, and body text

marking verified since this was against master branch
Status: RESOLVED → VERIFIED
I/Gecko   (  675): TCPSocket: Host info: securesmtp.t-online.de:587
I/Gecko   (  675): 
I/Gecko   (  675): TCPSocket: SSL: false
I/Gecko   (  675): 
I/Gecko   (  143): TCPSocket: content process: false
I/Gecko   (  143): 
I/Gecko   (  143): TCPSocket: window init: undefined
I/Gecko   (  143): TCPSocket: startup called
I/Gecko   (  143): 
I/Gecko   (  143): TCPSocket: Host info: securesmtp.t-online.de:587
I/Gecko   (  143): 
I/Gecko   (  143): TCPSocket: SSL: false
I/Gecko   (  143): 
I/Gecko   (  675): WWAR: PROBE:SMTP sad. error: | server-problem |  |
I/Gecko   (  675): WWAR: PROBE:IMAP sad. Error | BAD | Error while executing request: Invalid login | Invalid login
Only "inbox" folder.

I/Gecko   ( 1139): WERR: Error: This server doesn't support the command FolderSync
I/Gecko   ( 1139): WLOG: runOp(check: {"type":"syncFolderList","longtermId":"1/0","lifecycle":"do","localStatus":"done","serverStatus":"checking","tryCount":1,"humanOp":"syncFolderList"})
I/Gecko   ( 1139): WLOG: runOp(check: {"type":"syncFolderList","longtermId":"1/0","lifecycle":"do","localStatus":"done","serverStatus":"checking","tryCount":6,"humanOp":"syncFolderList"})
Flags: needinfo?(bugmail)
AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.211
Firefox os  v1.1
Mozilla build ID:20130916041201
Can we please stop posting account credentials to an open bug? I will make all of those attachments private now.
Tony, or whoever else has the permissions to update the passwords of the test account, please change them. Thanks.

Also I don't think that the problem reported here has nothing to do with this specific bug. As the error message shows, there is a network problem. That means run e.g. Firefox and try to open a web page. I believe you will get a not being able to connect error back. I had a similar situation lately and fixing the network issues solved it.
Flags: needinfo?(tchung)
buri.blff@gmail.com, can you please stop adding comments with the user and password listed? Thanks!
Flags: needinfo?(buri.blff)
Comment 17 seems to be indicating that t-online.de supports ActiveSync accounts, but we are having trouble (the bit about FolderSync not being supported).  In bug 874348 :squib fixed a problem like that for our support of 163.com that may correspond to this.  I landed the fix on master(v1.2), but not v1.1.

It's not clear in comment 14 if Lucas tried to create an ActiveSync account or just an IMAP account.  If an ActiveSync account works on master or v1.2 but not v1.1, then it's likely the issue is bug 874348 and we want to mark that bug leo+ so we can perform an uplift of the fix.  (Landing comments in https://bugzilla.mozilla.org/show_bug.cgi?id=874348#c19 if someone wants to try a cherry-pick too.  It probably applies cleanly without extra work.)

For the network failures... we currently don't hold wake-locks during the setup process; is it possible the screen is turning off and the network connection is dropping or something like that?
Flags: needinfo?(bugmail)
(In reply to Henrik Skupin (:whimboo) from comment #29)
> buri.blff@gmail.com, can you please stop adding comments with the user and
> password listed? Thanks!

OK, Thanks for your note.
Flags: needinfo?(buri.blff)
did you try adding the web.de account manually? thanks
Flags: needinfo?(sync-1)
can QA help to verify comment 30? about ActiveSync account? thanks
Keywords: qawanted
(In reply to Joe Cheng [:jcheng] from comment #34)
> can QA help to verify comment 30? about ActiveSync account? thanks

Is there a specific activesync account that we are asking for here?  the test account we received from DT is imap, so if help is needed, we'll need another test account created for EAS.   Else, i would defer someone else that currently has one in T-online to assist here with the test.   Please advise who can help.
Flags: needinfo?(tchung)
I'm reopening this because it doesn't seem like we autoconfig for t-online.de correctly because ActiveSync autodiscover works enough to break us.  See https://bugzilla.mozilla.org/show_bug.cgi?id=874348#c24 for more details, but in short:

- I created a free t-online.de account (pretty easy; no need for a mailing address or ID number)
- I created an e-mail password for use by e-mail clients
- I was able to manually configure IMAP/SMTP for it
- I was unable to manually configure ActiveSync for it because we die in autodiscovery
- I was unable to automatically configure an account because there's an autodiscover server and that sucks us in and we declare the apparent auth failure there as fatal which causes us to never check the ISP database and then retry as IMAP/SMTP.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Keywords: qawanted
I'm relying on Google Translate, but it appears that use of ActiveSync at t-online.de requires use of "Sync Plus" (marketing stuff at https://sync.t-online.de/) which is free if you have a Deutsche Telekom mobile plan and a t-online.de e-mail account.  Since I just have the free e-mail account, I'm not authorized.

If this is correct, it does mean there's a situation where we will fail to auth with ActiveSync but will succeed with IMAP (or potentially POP3), so we should change ActiveSync failures of this type to be non-fatal.

We should probably also do the proposed thing where we store a local ISP database entry to skip trying ActiveSync for the time being.  The rationale is that ActiveSync does provide calendar and contact sync capabilities, but we don't use those, so we're better off just using IMAP and accelerating our account creation process.

Wilfred, is this something you can help confirm?
Flags: needinfo?(wmathanaraj)
I am reaching out to DT. Still leaving NI on me for feedback.
Feedback:

the issue we raised regarding T-Online and Web.de email is only about IMAP. We are not expecting Active Sync to work with either service, if IMAP works with both services, we're fine.
Flags: needinfo?(wmathanaraj)
See Also: → 921529
Here's the plan then:

- I am going to add t-online.de's ISPDB entry to gaia which will cause us to fast-path to IMAP account creation.  I will uplift this to v1.1 and v1.2.  This is an extremely safe uplift since it only affects the autoconfig step and does not affect manual configuration or anything post-account creation.  This will mean that users who want to use ActiveSync will have to use manual setup, but since IMAP is preferable in general, I think this is the right choice.  (And much of the reason, other than risk, that we're not just relying on the next piece of the plan.)

- I have filed bug 921529 about avoiding this problem in general.  A failure in the autodiscover process will not stop us from advancing to the ISPDB setup stage.  I am going to fix this since it's reasonably easy and avoids this type of problem again in the future.

- We *do not* need to uplift bug 874348 to address this problem, I am clearing the leo? flag on that bug.

I have to do some recruiting stuff for the next few hours, but will take care of this after that.

Clearing the needinfo since no info is required from anyone at this point.
Assignee: nobody → bugmail
Status: REOPENED → ASSIGNED
Flags: needinfo?(sync-1)
Comment on attachment 811361 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/12517

This is the verbatim current t-online.de autoconfig entry.  I have manually verified that this does the right thing on gaia/master and when uplifted to gaia/v1-train.  v1.2 is assumed to uplift cleanly.

The "right thing" is defined as finding the local config file and going directly to performing an IMAP probe.  The log looks like this from v1.1 (on a GP Keon on the v1.1 stream with the app installed using PRODUCTION=1):

09-27 17:03:23.875 I/Gecko   ( 7834): WLOG: Attempting to get autoconfiguration for t-online.de
09-27 17:03:23.875 I/Gecko   ( 7834): WLOG:   Looking in GELAM
09-27 17:03:23.875 I/Gecko   ( 7834): WLOG:   Looking in local file store
09-27 17:03:24.735 I/Gecko   ( 7834): WLOG: SUCCESS
09-27 17:03:26.035 I/Gecko   ( 7834): WLOG: PROBE:IMAP attempting to connect to secureimap.t-online.de
09-27 17:03:26.035 I/Gecko   ( 7834): TCPSocket: content process: true
09-27 17:03:26.035 I/Gecko   ( 7834): 
09-27 17:03:26.035 I/Gecko   ( 7834): TCPSocket: window init: 4
09-27 17:03:26.045 I/Gecko   ( 7834): TCPSocket: startup called
09-27 17:03:26.045 I/Gecko   ( 7834): 
09-27 17:03:26.045 I/Gecko   ( 7834): TCPSocket: Host info: secureimap.t-online.de:993
09-27 17:03:26.045 I/Gecko   ( 7834): 
09-27 17:03:26.045 I/Gecko   ( 7834): TCPSocket: SSL: ssl
09-27 17:03:26.045 I/Gecko   ( 7834): 
09-27 17:03:26.045 I/Gecko   ( 7834): WLOG: PROBE:SMTP attempting to connect to securesmtp.t-online.de
09-27 17:03:26.045 I/Gecko   (  108): TCPSocket: content process: false
09-27 17:03:26.045 I/Gecko   (  108): 
09-27 17:03:26.055 I/Gecko   (  108): TCPSocket: window init: undefined
09-27 17:03:26.055 I/Gecko   (  108): TCPSocket: startup called
09-27 17:03:26.055 I/Gecko   (  108): 
09-27 17:03:26.055 I/Gecko   (  108): TCPSocket: Host info: secureimap.t-online.de:993
09-27 17:03:26.055 I/Gecko   (  108): 
09-27 17:03:26.055 I/Gecko   (  108): TCPSocket: SSL: ssl
09-27 17:03:26.055 I/Gecko   (  108): 
09-27 17:03:26.065 I/Gecko   ( 7834): TCPSocket: content process: true
09-27 17:03:26.065 I/Gecko   ( 7834): 
09-27 17:03:26.065 I/Gecko   ( 7834): TCPSocket: window init: 4
09-27 17:03:26.075 I/Gecko   ( 7834): TCPSocket: startup called
09-27 17:03:26.075 I/Gecko   ( 7834): 
09-27 17:03:26.075 I/Gecko   ( 7834): TCPSocket: Host info: securesmtp.t-online.de:587
09-27 17:03:26.075 I/Gecko   ( 7834): 
09-27 17:03:26.075 I/Gecko   ( 7834): TCPSocket: SSL: false
09-27 17:03:26.075 I/Gecko   ( 7834): 
09-27 17:03:26.085 I/Gecko   (  108): TCPSocket: content process: false
09-27 17:03:26.085 I/Gecko   (  108): 
09-27 17:03:26.085 I/Gecko   (  108): TCPSocket: window init: undefined
09-27 17:03:26.095 I/Gecko   (  108): TCPSocket: startup called
09-27 17:03:26.095 I/Gecko   (  108): 
09-27 17:03:26.095 I/Gecko   (  108): TCPSocket: Host info: securesmtp.t-online.de:587
09-27 17:03:26.095 I/Gecko   (  108): 
09-27 17:03:26.095 I/Gecko   (  108): TCPSocket: SSL: false
09-27 17:03:26.095 I/Gecko   (  108): 
09-27 17:03:27.445 I/Gecko   ( 7834): WLOG: PROBE:SMTP happy
09-27 17:03:27.775 I/Gecko   ( 7834): WLOG: searchargs:  UID 1:2
09-27 17:03:28.135 I/Gecko   ( 7834): WLOG: PROBE:IMAP happy, TZ offset: 2
09-27 17:03:28.355 I/Gecko   ( 7834): WLOG: runOp(do: {"type":"syncFolderList","longtermId":"2/0","lifecycle":"do","localStatus":"done","serverStatus":"doing","tryCount":0,"humanOp":"syncFolderList"})
09-27 17:03:29.445 I/GeckoDump( 7834): LOG: saveCacheCookie: 1305 in 1 segments
Attachment #811361 - Flags: review?(squibblyflabbetydoo)
Comment on attachment 811361 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/12517

rs=me
Attachment #811361 - Flags: review?(squibblyflabbetydoo) → review+
landed on gaia/master, wants uplift across v1.1, v1.1.0hd, v1.2:
https://github.com/mozilla-b2g/gaia/pull/12517
https://github.com/mozilla-b2g/gaia/commit/e6c0e9706efe5e69ac03df6f85ef18bd5d6500dd
Status: ASSIGNED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Uplifted e6c0e9706efe5e69ac03df6f85ef18bd5d6500dd to:
v1-train: c3f148e9dadfe5f159e5c3720da55a91be86d0e6
v1.2: 93d4e7e948d66bf329c4b3ae87ab78670e59d9cb
v1.1.0hd: c3f148e9dadfe5f159e5c3720da55a91be86d0e6
(In reply to Andrew Sutherland (:asuth) from comment #44)
> landed on gaia/master, wants uplift across v1.1, v1.1.0hd, v1.2:
> https://github.com/mozilla-b2g/gaia/pull/12517
> https://github.com/mozilla-b2g/gaia/commit/
> e6c0e9706efe5e69ac03df6f85ef18bd5d6500dd

Hi, 
 It is well! But I have a question: There is only t-online.de autoconfig file. Do we also need a autoconfig file for web.de?
(In reply to buri.blff from comment #47)
>  It is well! But I have a question: There is only t-online.de autoconfig
> file. Do we also need a autoconfig file for web.de?

No.  We had to add one for t-online.de because autoconfiguration would fail because t-online.de hosts an ActiveSync autodiscover server that was breaking the autoconfiguration process for those who did not pay for/otherwise have ActiveSync accounts.  web.de does not host an autodiscover server and so our standard process works.  We fetch the autoconfig file from https://autoconfig.thunderbird.net/v1.1/web.de and then does what that says.  It currently says IMAP.

Although we could add the autoconfig file locally to speed up account creation, it would be bad form/inadvisable because per https://autoconfig.thunderbird.net/v1.1/web.de IMAP is officially a non-free service.  However, it is my understanding that web.de has apparently relaxed the implementation to allow free accounts to use IMAP.  Because we are very limited in our ability to push out updates to the e-mail app, we need to be able to have the software use a different autoconfig file if they change their mind, or change free users to need to use a different host, etc.
(In reply to Andrew Sutherland (:asuth) from comment #48)
> Although we could add the autoconfig file locally to speed up account
> creation, it would be bad form/inadvisable because per
> https://autoconfig.thunderbird.net/v1.1/web.de IMAP is officially a non-free
> service.

Whoops, the URL I meant to paste is: https://hilfe.web.de/e-mail/imap.html
(In reply to Andrew Sutherland (:asuth) from comment #48)
> (In reply to buri.blff from comment #47)
> >  It is well! But I have a question: There is only t-online.de autoconfig
> > file. Do we also need a autoconfig file for web.de?
> 
> No.  We had to add one for t-online.de because autoconfiguration would fail
> because t-online.de hosts an ActiveSync autodiscover server that was
> breaking the autoconfiguration process for those who did not pay
> for/otherwise have ActiveSync accounts.  web.de does not host an
> autodiscover server and so our standard process works.  We fetch the
> autoconfig file from https://autoconfig.thunderbird.net/v1.1/web.de and then
> does what that says.  It currently says IMAP.
> 
> Although we could add the autoconfig file locally to speed up account
> creation, it would be bad form/inadvisable because per
> https://autoconfig.thunderbird.net/v1.1/web.de IMAP is officially a non-free
> service.  However, it is my understanding that web.de has apparently relaxed
> the implementation to allow free accounts to use IMAP.  Because we are very
> limited in our ability to push out updates to the e-mail app, we need to be
> able to have the software use a different autoconfig file if they change
> their mind, or change free users to need to use a different host, etc.

Thanks for your answer.
Andrew, I just flashed the latest "nightly" build from http://downloads.geeksphone.com/ onto my Keon and I'm getting the exact same symptoms with my @free.fr email address, am I doing something wrong or do you wish for me to file a new bug? FWIW, my build id is 20131013022938
Flags: needinfo?(bugmail)
(In reply to Jonathan Protzenko [:protz] from comment #51)
> Andrew, I just flashed the latest "nightly" build from
> http://downloads.geeksphone.com/ onto my Keon and I'm getting the exact same
> symptoms with my @free.fr email address, am I doing something wrong or do
> you wish for me to file a new bug? FWIW, my build id is 20131013022938

Different problem, different bug.  From bug 556750 it sounds like you have to explicitly enable a user setting to be allowed to use STARTTLS, and because of this, the Thunderbird ISP database entry calls for using 25 without any encryption.  We don't allow that configuration because we aren't okay with revealing passwords in the clear.

https://autoconfig.thunderbird.net/v1.1/free.fr discusses this a little too.

If we're lucky maybe free.fr has improve their configuration issues and we can just fix the Thunderbird ISP database entry.  If not, then I think maybe file a new bug about supporting free.fr (which sounds popular) and have it depend on us supporting a configuration where we don't perform SMTP auth and the user can't access their e-mail off the network/something else.
Flags: needinfo?(bugmail)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: