Closed Bug 475139 Opened 15 years ago Closed 14 years ago

Autoconfig should provide more option for imap account

Categories

(Thunderbird :: Account Manager, defect)

Product:
Thunderbird
Component:
Account Manager
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 752484

People

(Reporter: el.cameleon.1, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Build Identifier: 3.0b1

As describe on the wiki ( https://wiki.mozilla.org/Thunderbird:Autoconfiguration ), Autoconfig will be great for the pop account configuration, which is quite simple, but will only do half of the job (security settings for the connection) for imap account. I believe it needs to set up at least 2 other kind of things:
- root folder for imap account (see bug 80858 ) in order to avoid the user to go into the advanced configuration of server parameters
- set up the name of special folder (Sent, Draft, Trash, Junk) in order to avoid the user to manually do the job folder by folder.

These two point are one of the reason why rdf file are at this moment more interesting for easely set up imap account. They are actually used in at least two add-ons:
- Gmail IMAP Account Setup ( https://addons.mozilla.org/fr/thunderbird/addon/6381 )
- Laposte.net IMAP Account Setup (by myself, in sandbox https://addons.mozilla.org/en-US/thunderbird/addon/10331 )

Reproducible: Always

Steps to Reproduce:
1. Create manually a new imap account with these parameters:
- login: e.cameleon (@laposte.net) (without the space and brakets)
- password: test 
2. Try to manually set up the roots folder and special folder
3. Try to do the same with the add-on "Laposte.net IMAP Account Setup" and see the difference
Actual Results:  
It take to much time to manually set up the imap account because things are not understandable or needed by most users.

Expected Results:  
Should works as easy as the add-ons "Laposte.net IMAP Account Setup" works
Status: UNCONFIRMED → NEW
Ever confirmed: true
Depends on: 80858
Bug 80858 is an *alternative* to this one, not a blocker.
No longer depends on: 80858
Sorry Ben, I was thinking that they are linked together because the resolution of bug 80858 mean that a part of this bug won't need to be solve. But you are right, it is not a blocker.
Hi,

As Autoconfig arrive in the next beta of TB3, I believe it would be useful to linked this bug to bug 422814 in order not to forget it.
Ben or david, could you please make it, as I am not sure what is the better choice (depend on or block?)
marking it wanted tb3+, but there's no guarantee that we'll get to it, unfortunately.  The root folder stuff could be done with or w/o autoconfig, but the special folder stuff would require the autoconfig stuff be extended to implement the same stuff the rdf stuff did w.r.t. special folders.
Flags: wanted-thunderbird3+
Hi all,

I have updated the GoogleDocs MailServerList available on the wiki: htps://wiki.mozilla.org/MailServerList with the required fields for Free.fr and Laposte.net. 
I have also add some description of these fields to the wiki.

Please tell me if you think it needs to be clarified.
Gerv suggested that we could hardcode some common values for "Sent" etc., in English (for all locales) and localizable, case-insensitive, so that we could just use them when they are found. Of course that would not work with an account that has previously been messed up by Thunderbird or another client creating a Sent in addition to the expected "Outbox" or whatever.

I personally think that this is not terribly important, given that the user can get to the information (both folders are visible in both Thunderbird and webmail), and there's nothing saying that we must adapt to whatever the provider's webmailer uses.
I am not sure that hardcode in Thunderbird the different possibility of specials-folder's names would be a good solution, because there is a risk that there is a lots of combinations... I believe this is more the aim of the autoconfig. But why not if it is really easier?
Hard coding the names doesn't sound worth it, especially since there's a way to get the special folder names from the server - bug 476260.
(In reply to comment #8)
> Hard coding the names doesn't sound worth it, especially since there's a way to
> get the special folder names from the server - bug 476260.

It could be a very good solution, but only if this futur is supported by more ISP than Gmail and Apple... Is there a way to know if an ISP support this future?
(In reply to comment #9)
> 
> It could be a very good solution, but only if this futur is supported by more
> ISP than Gmail and Apple... Is there a way to know if an ISP support this

yes with the imap log see bug 476260 comment 0 the server replies to the CAPABILTY command with XLIST.
Many of the settings in the old ISP Hook RDF file were vital to our client configurations.  With this functionality removed, configuration of TB3 will now be considerably harder for our users that it was in the past.  It will be a hard sell getting our users to upgrade unless some of these features are re-implemented in autoconfig.

For your reference, some of the IMAP settings that we specify, in addition to the "root folder path" mentioned above, are:

In the <NC:nsIMsgIncomingServer> section:
<NC:biffMinutes>29</NC:biffMinutes>  (this reduces the load on our servers to the maximum length allowed to keep an IMAP session alive, when IDLE is implemented.)
<NC:nsMsgImapDeleteModel>0</NC:nsMsgImapDeleteModel>  (this helps to keep delete behavior identical across webmail and Thnuderbird configs.)
<NC:rememberPassword>false</NC:rememberPassword>  (because the password store doe snot meet with security standards for the organization).

In the <NC:nsIImapIncomingServer> section:
<NC:deleteModel>IMAPDelete</NC:deleteModel>  (this maps to the same deletion model used by our webmail system.)
<NC:dualUseFolders>false</NC:dualUseFolders>  (as dual use folders are not supported in our system)

I will also note that we used to be able to provide an LDAP directory server to be used in conjunction with our IMAP account (through a combination of the IDP RDF file and modification of the default prefs.js file.  Although this problem is not a missing LDAP setting per-se, it is another type of functionality that we will lose with the new autoconfig system, as it is currently implemented.
biffMinutes and rememberPassword are classical settings which should be decided by the user and not the email provider. These are intentionally not in the file, for exactly that reason.

> the password store does not meet with security standards for the organization

The master password database is cryptographically strong. You can turn them on in the prefs. You can customize prefs for your organization fairly easily.

Aren't dualUseFolders autodetected? It should be.
(FWIW, I include organizations in that "email provider" in this case. I realize that you are a university.)
Thanks for taking the time to reply, Ben.  I appreciate all of the work being done to make TB easier to configure.  

Please consider the following counter-points:

(In reply to comment #12)
> biffMinutes and rememberPassword are classical settings which should be decided
> by the user and not the email provider. These are intentionally not in the
> file, for exactly that reason.

I disagree with this assertion.  It is absolutely the role of an email provider to set default/recommended settings for email clients.  If a provider supports IDLE, they should be able to force this setting on.  If their servers get clobbered because too many clients set their biffMinutes setting to "1", they should be able to set a default to a more reasonable interval.  If an organization has conditioned its users to expect certain behavior out of its recommended (and provided) email client, it ought to be able to continue to provide that same behavior out-of-box.

Keeping in mind that Thunderbird is not a "managed" application, the end user is always free to tune these settings to the they way they prefer them.  However, most (all?) of our users do not want to deal with advanced configuration dialogs in Thunderbird.  They want the client to behave correctly on first use.  The ability to pre-configure Thunderbird 2.0 to the point where the end user needed to provide only a username and password was a blessing.  While this is the stated (and admirable) goal of autoconfig in TB 3, it has not been achieved from the perspective of our organization in this release-candidate version of the feature.

> > the password store does not meet with security standards for the organization
> The master password database is cryptographically strong. You can turn them on
> in the prefs. You can customize prefs for your organization fairly easily.

I am sure that TB is using very nice cyphers indeed.  However, this is not considered relevant to our policy makers.  This is reversable encryption, and vulnerable to offline brute-force attacks.  Thus, its use is not recommended in our organization, and we would like it default-set to "off".

> Aren't dualUseFolders autodetected? It should be.

No, they are not.  I have confirmed that under TB 3.0 RC2 dual use folders still are not autodetected.  It never occured to me that they were supposed to be auto-detected, actually.

Thanks for your consideration of these concerns,
-Greg Mackinnon
University of Vermont
> certain behavior out of its recommended (and provided) email client

If you are providing the client, you can trivially change the defaults in the default prefs. There may also be ways to auto-create accounts (I don't know about this) and set the prefs only for that account.

This is an entirely different case than an ISP. Whoever delivers the app also controls how it behaves.
(In reply to comment #15)
> > certain behavior out of its recommended (and provided) email client
> If you are providing the client, you can trivially change the defaults in the
> default prefs. There may also be ways to auto-create accounts (I don't know
> about this) and set the prefs only for that account.

You are correct that we can modify the default prefs.js file.  We do, in fact, do this already.

Unfortunately, prefs.js cannot easily be used to modify all of the settings that we want to put in place.  For that, we used the ISP Hook RDF file.  All of the settings that I am discussing go into the ISP RDF, not into prefs.js.  

With the UI exposed by the ISP Hook now removed from Thunderbird, we are left without a means of fully pre-configuring the client.  

> This is an entirely different case than an ISP. Whoever delivers the app also
> controls how it behaves.

Indeed.  But since autoconfig is now the only tool available to make these sorts of configuration changes, I would think it would behoove the team to make it work for both ISPs and internal organizational support staff.
> both ISPs and internal organizational support staff.

I think these are very different cases, from a policy point of view.

> You are correct that we can modify the default prefs.js file.  We do, in fact,
> do this already.

Good. I think all the server settings have a setting in default prefs, in mail.server.default.<prefname>. With that, you should be able to achieve what you want already.
(Unfortunately, that would affect all accounts, as I said, but I don't think that's a big problem in your case, and the user can always change it anyways.)

> since autoconfig is now the only tool available

There are other ways, e.g. what I said above, or by just delivering the right user prefs with a fully configured account, and fully automatically creating it. I don't know the details, but I know some organizations do that. I'll have to think more about this case to make this easier.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.