In some large enterprise environments (notably some university configurations), account autoconfig can be effectively known ahead of time by the admins never to work. This means that Tb3 offers a materially more aggravating new user experience in these environments than Tb2 did. This is described in more detail at <http://groups.google.com/group/mozilla.dev.apps.thunderbird/msg/cdb46120e67a1ede>. Given that we're hoping to code-freeze next Friday the 14th, I would very strongly bias towards the simplest solution (which I suspect is a hidden pref for use by MCD deployers) rather than the most correct solution. The hidden pref has the disadvantage that it only helps organizations who deploy MCD. BenB has suggested that a way to do this in the autoconfig file itself would be to implement bug 564043. This (and any other autoconfig-based solution) has the disadvantage that it doesn't help universities where the model is satellite IT departments who may or may not subscribe to central mail/web/DNS services but don't control those servers. Thoughts?
My quick-and-dirty suggestion to this is filed in bug 561531. At least it would solve the case for most users in our environment, and we could use the local autoconfig file. BenB's suggestion with custom inputfields looks more elegant and multipurpose, but would it be ready in time?
> strongly bias towards the simplest solution The simplest solution is to put in the autoconfig file "click.Edit.please" as hostname. That will appear to the user in the hostname field. It is also guaranteed to not allow him to proceed otherwise, because the verification will fail due to a non-reachable host. I think the suggestion above is sufficient for these rare sites which have a very heterogeneous setup at the same email domain *and* don't want to spend the time to set up autoconfig properly using a lookup.
Note that the above suggestion will then easily migrate over (almost without any effort) to custom fields in bug 564043.
Here's an example file: <?xml version="1.0" encoding="UTF-8"?> <clientConfig version="1.1"> <emailProvider id="odduni.de"> <domain>odduni.de</domain> <displayName>Odd University</displayName> <displayShortName>Odd Uni</displayShortName> <incomingServer type="imap"> <hostname>click.Edit.please</hostname> <port>143</port> <socketType>plain</socketType> <authentication>password-cleartext</authentication> <username>your-unix-account</username> </incomingServer> <outgoingServer type="smtp"> <hostname>enter.your.mail.server.please</hostname> <port>25</port> <socketType>plain</socketType> <authentication>password-cleartext</authentication> <username>your-unix-account</username> </outgoingServer> <documentation url="http://www.odduni.de/helpdesk/how-to-setup-your-email-account.html" /> </emailProvider> </clientConfig> You can place it in the Thunderbird installation, directory isp/, filename <domain>.xml, i.e. in this case in isp/odduni.de.xml . It should then be used for all @odduni.de email addresses. (But not @cs.odduni.de - they are separate. If @cs.odduni.de accounts are just as odd, you can use another file for them. OTOH, if the @cs.odduni.de account all are on the same IMAP/SMTP server, you can give those users a proper config.) The above suggestion has the advantage that you can pre-configure supply *some* values already (they are still changeable), and most importantly that you can give the user hints, like "your-unix-account", as people likely have many different usernames, esp. in such heterogeneous setups, and may be confused which one to use. So, I think this is much better than *just* disabling autoconfig, even though you do force users to go to Manual Edit mode. And you get it for free: no code change necessary.
After discussion with bwinton, sold! Which is to say that he pointed out that a lockPref doesn't really add value, since if someone is already using MCD, they can just ship the correct email configuration in the first place, avoiding this whole mess. So I think the only important thing to do here is to relnote the options for admins on one of the enterprise wiki pages. Which is to say, document the alternatives of: a) the workaround ben proposes in comment 4 b) using MCD to preconfigure the email settings So I think there are two pieces of work remaining here: a) write that documentation on one of the Enterprise wiki pages b) make sure that the relnotes point to the most appropriate Enterprise wiki page, rather than this specific issues. Adding the relnote keyword so that bit doesn't get lost.
Documentation is at <https://developer.mozilla.org/en/Thunderbird/Autoconfiguration>, relnote should point there. I'll add this hack to that page. I agree your last point b) (last paragraph) is important. I'll a suggest a relnote text about autoconfig in general later.
(In reply to comment #6) > Documentation is at > <https://developer.mozilla.org/en/Thunderbird/Autoconfiguration>, relnote > should point there. and I suspect we want to link it at https://wiki.mozilla.org/Thunderbird/Enterprise and https://developer.mozilla.org/en/Thunderbird/Deploying_Thunderbird_in_the_Enterprise > I'll add this hack to that page. > I agree your last point b) (last paragraph) is important. > > I'll a suggest a relnote text about autoconfig in general later. Benb, I suspect we're close to needing bits for relnotes. Also, do you have more to add to devmo?
(In reply to comment #4) > <incomingServer type="imap"> > <hostname>click.Edit.please</hostname> > > <outgoingServer type="smtp"> > <hostname>enter.your.mail.server.please</hostname> I tried this with Thunderbird 3.1 Beta 2, and I have to say that using this workaround is much more confusing for a user than I though. Those text strings are in a small font in the middle of the complex dialog and will get unnoticed really easily. (There actually wasn't an Edit button available, so better would be "click.manual.setup.please"). So most users probably just click "Create account" because the dialog show green light icons and that button is clickable, resulting in a non-working account. > So, I think this is much better than *just* disabling > autoconfig, even though you do force users to go to Manual Edit mode. I don't agree, there should be a way for admins to *force* users to do the manual editing before creating the account, OR disable the (This part is a little offtopic, but...) in case you're wondering why we haven't just put up an autoconfig server: The autoconfig server could be used by spammers or other malicious users for phishing people's mail redirection targets (in our environment) and to find out if an email address exists or not. After all, the autoconfig.example.com server is trivial to find, as there isn't an option to change the autoconfig server address to anything else. We are still weighing if we want to risk our users' personal security by making that kind of service open to the public.
> So most users probably just click "Create account" ..., > resulting in a non-working account. No, when you click "Create Account", we try to log in, and hostname "click.manual.setup.please" (please use ".please" as top level domain here) won't be found, so it will not continue and show an error. > to find out if an email address exists or not. You just return a valid config for all email accounts, even non-existing ones.
(In reply to comment #9) > > So most users probably just click "Create account" ..., > > resulting in a non-working account. > > No, when you click "Create Account", we try to log in, and hostname > "click.manual.setup.please" (please use ".please" as top level domain here) > won't be found, so it will not continue and show an error. You're correct. Somehow I managed to get it to create a non-working account, but I can't reproduce it. With that error message it's fine. > > to find out if an email address exists or not. > > You just return a valid config for all email accounts, even non-existing ones. Yes. But still you'll have make sure it's hard to spot the real ones from the fake ones. If the results are random (each access gives different results), that reveals it's fake. If the fakes always have identical "default" mail server address, then you can see that at least those users that aren't using the default server are real ones. So the results should be somewhat random, but believable to the human eye and repeating a query should always return the same result. I'm not saying that this is impossible to do in code, but these security concerns make it non-trivial for an organization to deploy an autoconfig server, and a lot of thought has to be put to it. It is one extra hole in the perimeter that an attacker could abuse, and the fact that the server address is hardcoded (why???) makes it easy to find. The possible risks should at least be addressed clearly in the documentation about setting up an autoconfig server. Btw, how does Thunderbird function if autoconfig.domain.tld is found in the DNS, but a firewall prevents accessing it? Is it the same result than when the server doesn't exist? I would have tested this myself, but I can't do it easily because the damn address is hardcoded...
(In reply to comment #4) > Here's an example file: I used this xml file approach with big success until Tb started to create dummy profiles, which do not receive/send mails at all and had to be deleted&recreated without autoconfig option. Unfortunately it still don't work with 3.0.5 and 3.1.
Removing relnote keyword from bugs that are no longer significant or not needing to be mentioned in the release notes.
don't anticipate doing this myself