TB 2.0.0.24 last Tb 2.0. Sure thing, or just "not planned to upgrade"?
Timo Pietilä
last planned update for TB 2 -series. Mozilla team encourages people to
"upgrade" to bug-ridden Tb 3.
Is that the final word?
I see at least one blocking bug in Tb 3 and that is that new account
wizard that is so infuriatingly badly designed that it has no limits.
IMO TB3 is still beta. Broken beta. At least import that new and
improved upcoming new account wizard from TB 3.1 to Tb 3.0 before
dropping support for Tb 2. Also I think there is still that msf-file
corruption bug around, which is bad bad thing. And lack of collapsed
header: I just learned that it is easy userChrome.css -change to get rid
of those buttons. Why not make that change _WHEN_ person chooses to use
old toolbar. Should be very easy change in code.
Also in migration phase from Tb 2 to TB 3:
1) Do not change anything before user decides so.
- No automatic setting to download everything.
- No Smart Folders
2) Migration wizard should be offered, but not mandatory.
Otherwise you end up ruining many people first experience of TB3. Which
reduces users.
Those few changes should be relatively easy work to fix (except that
msf-corruption bug perhaps).
You can build up some "tour of new features". There are couple of those
that I didn't even notice before I reverted back to TB2 because TB3 was
so bad for me. There might actually be one or two things that have got
better, but for first impressions that was not apparent.
Timo Pietilä
Dan Mosedale
> Just noticed what my TB says when I open it. It says that this is the
> last planned update for TB 2 -series. Mozilla team encourages people
> to "upgrade" to bug-ridden Tb 3.
>
> Is that the final word?
help folks who administer deployments. With luck, we'll get that out
this week.
Dan
Timo Pietilä
Thank you. I would hate to be forced to downgrade my TB2 to TB3 unless
some of those showstopping bugs are resolved. I think we skip the TB3.0
and go directly to 3.1 (that looks a lot more promising for corporate
environment).
BTW I think I'm seeing a bug in your post. In subject-line there is a
lot of spaces between "to" and "upgrade", but in my answer they are gone
again (I think).
That is: the subject line in header panel, not in the message list.
Are you seeing the same?
Timo Pietil�
Jaakko Luoto
> Dan Mosedale wrote:
>> We're working on a more detailed explanation of our current thinking
>> to help folks who administer deployments. With luck, we'll get that
>> out this week.
>
> Thank you. I would hate to be forced to downgrade my TB2 to TB3 unless
> some of those showstopping bugs are resolved. I think we skip the TB3.0
> and go directly to 3.1 (that looks a lot more promising for corporate
> environment).
Our plans are currently about the same as yours - we will wait for 3.1.
If some serious security hole is found in 2.0.0.24 and it takes a long
time (several months) to get a corporate-deployable version of 3.0 or
3.1, we will have to consider changing our primary email client. But I
see Mozilla folks are working on our problems. Nice to hear that there's
some information coming up.
> BTW I think I'm seeing a bug in your post. In subject-line there is a
> lot of spaces between "to" and "upgrade", but in my answer they are gone
> again (I think).
>
> That is: the subject line in header panel, not in the message list.
>
> Are you seeing the same?
I'm seeing the same on 2.0.0.24. And I've seen that same "extra spaces
in subject line" bug several times before.
If you look at the source of Dan's message (ctrl+u), there's a line feed
AND a tab character in the middle of the subject. In your messages,
there's only line feed and a space.
--
Jaakko Luoto <jaakko.luot...@tut.fi>
Faculty of Computing and Electrical Engineering at TUT
IT Administration
Nathan Tuggy
Bug 271312, perhaps?
--
Nathan Tuggy [:tuggyne]
nat...@tuggycomputer.com
Timo Pietilä
Looks like that one. However it also looks that in TB 2 it has been
fixed, but Lanikai 3.1b2 has re-introduced it.
Or fixed it, but TB2 shows that tab-char in header panel which it should
not do.
In any case Lanikai 3.1.b2 treats long subject lines different way than TB2.
Timo Pietilä
Ron K.
> Nathan Tuggy wrote:
>> On 2010-04-15 23:54, Jaakko Luoto wrote:
Also see bug: https://bugzilla.mozilla.org/show_bug.cgi?id=64948
--
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported Major Error used BSOD to msg the enemy!
Dan Mosedale
> On 4/13/10 1:30 PM, Timo Pietilä wrote:
>> Just noticed what my TB says when I open it. It says that this is the
>> last planned update for TB 2 -series. Mozilla team encourages people
>> to "upgrade" to bug-ridden Tb 3.
>>
>> Is that the final word?
> to help folks who administer deployments. With luck, we'll get that
> out this week.
enough along to post this week; we'll be doing it next week. Sorry for
the delay.
Dan
Ben Bucksch
> I see at least one blocking bug in Tb 3 and that is that new account
> wizard that is so infuriatingly badly designed that it has no limits.
Timo Pietilä
I thought that was going in 3.1. Apparently that is for both 3.0 and 3.1.
I have dilemma with that one:
As you can see from my email-address we use
firstname...@domain.rootdomain -format. That wizard extrapolates
from that that my server must be domain.rootdomain and adds imap or pop
in front of it.
Problem is that we have imap.helsinki.fi -mailserver, but it is _not_
the right server for most users.
How do I prevent clueless users from making connection to that server
without preventing them from making connection to that server (for some
users that _is_ the right server)?
I would prefer that program does not try to guess the right server, but
forces user to enter it manually.
However I understand that my case is probably very minor minority of
cases, so wizard guessing that would probably be preferred.
How about possibility to tune that wizard, so that it _offers_ that
other server (or nothing) by defaultPref -setting with config script?
Timo Pietilä
Ben Bucksch
> As you can see from my email-address we use
> firstname...@domain.rootdomain -format. That wizard extrapolates
> from that that my server must be domain.rootdomain and adds imap or
> pop in front of it.
> Problem is that we have imap.helsinki.fi -mailserver, but it is _not_
> the right server for most users.
>
> How do I prevent clueless users from making connection to that server
By providing an autoconfig server for your domains.
https://developer.mozilla.org/en/Thunderbird/Autoconfiguration
Ben Bucksch
> By providing an autoconfig server for your domains.
Specifically:
https://developer.mozilla.org/en/Thunderbird/Autoconfiguration#Configuration_server_at_ISP
Timo Pietilä
How about those users that need that server?
Timo Pietil�
Ben Bucksch
> Ben Bucksch wrote:
>>> As you can see from my email-address we use
>>> firstname...@domain.rootdomain -format. That wizard
>>> extrapolates from that that my server must be domain.rootdomain and
>>> adds imap or pop in front of it.
>>> Problem is that we have imap.helsinki.fi -mailserver, but it is
>>> _not_ the right server for most users.
>>>
>>> How do I prevent clueless users from making connection to that server
>>
>> By providing an autoconfig server for your domains.
>
> How about those users that need that server?
Only you know which ones those are (based on domain (ideally) or email
address).
Did you read the document?
Timo Pietilä
No I don't. It's pure guesswork. Those cannot be separated based on
email-address (both have same firstname...@domain.rootdomain
-address). And I have something like 50000 users. Maybe more (haven't
checked lately). Users can have posts in several different systems with
same accountID, but not with same address. However there is no easy way
to figure out which of those systems is used for that firstname.lastname
-format. Maybe some ldap -query for out directory.
It would be different case if we would use the "real" address which is
acco...@server.domain.rootdomain -format, but that isn't preferred
address because servers can change.
> Did you read the document?
Yes. There is no answer to my dilemma.
hmmm... Or maybe there is.
In example configuration XML there is this:
----
<clientConfig version="1.1">
<emailProvider id="freenet.de">
<domain>freenet.de</domain>
....
<incomingServer type="imap">
<hostname>imap.freenet.de</hostname>
<port>993</port>
<socketType>SSL</socketType>
<authentication>password-encrypted</authentication>
<username>%EMAILADDRESS%</username>
</incomingServer>
----
If I change those <hostname>imap.freenet.de</hostname> to
<hostname></hostname> etc.
with my domain name in
<emailProvider id="freenet.de">
<domain>freenet.de</domain>
Then I would get "empty" form without program trying to guess anything?
I need to test that.
Timo Pietilä
Ben Bucksch
> Ben Bucksch wrote:
>
> No I don't. It's pure guesswork.
If *you* as mail admin can't tell which server they need, how can users?
I would strongly suggest that you straighten our your systems.
> Those cannot be separated based on email-address (both have same
> firstname...@domain.rootdomain -address). And I have something
> like 50000 users. Maybe more (haven't checked lately). Users can have
> posts in several different systems with same accountID, but not with
> same address. However there is no easy way to figure out which of
> those systems is used for that firstname.lastname -format. Maybe some
> ldap -query for out directory.
It is possible. If an email for fred.fl...@example.com or
fr...@cs.example.com arrives, your systems put it into one mailbox. There
is a certain rule, or database. Find out what it is and make the
autoconfig server reflect/use that. (You can ignore forwards that the
users create themselves, of course.)
From what I gather, this will be a *real* boon for your users.
> If I change those <hostname>imap.freenet.de</hostname> to
> <hostname></hostname> etc.
You mean leave it empty? No, you can't. The configuration must be final
and correct. It is what we will create.
You can use the 5 placeholders (%EMAILLOCALPART% etc.), but that's it.
Ben
Timo Pietilä
> On 20.04.2010 08:17, Timo Pietil� wrote:
>> Ben Bucksch wrote:
>>> Only you know which [servers] those are (based on domain (ideally) or
>>> email address).
>>
>> No I don't. It's pure guesswork.
>
> If *you* as mail admin can't tell which server they need, how can users?
I'm not mail admin. I do however distribute software and otherwise
maintain workstation management systems (security, control etc.). Mail
admins are different section of our computer management team. Remember
that we have around 50000 users. Those few admins have enough work to do
without individual workstation program problems. We probably have more
servers and systems than ordinary small company has workstations (few
hundred servers).
> I would strongly suggest that you straighten our your systems.
This is university with about 200 years of history (even computers about
40 years) and we have everything between chemical weapons laboratories
to philosophers pondering "why are we here". Computer Sciences
especially are quite "interesting" case to centralized management.
So called "academic freedom" has long history here. I'm surprised we
have managed to get it as coherent as it is. It wasn't long ago when
every department had their own systems with varying degrees of
competence (some horrifying stories there) and complexity (same).
Unfortunately overlapping systems in this whole mess is unavoidable. (Or
at least has been so, we are simplifying systems and getting rid of
redundant parts as we speak. It just takes time. Upper management
decided that we have so many projects that not all of them can be
started simultaneously. Result: they all started simultaneously. AARGH).
>> Those cannot be separated based on email-address (both have same
>> firstname...@domain.rootdomain -address). And I have something
>> like 50000 users. Maybe more (haven't checked lately). Users can have
>> posts in several different systems with same accountID, but not with
>> same address. However there is no easy way to figure out which of
>> those systems is used for that firstname.lastname -format. Maybe some
>> ldap -query for out directory.
"out" should be "our". Stupid proofreading still doesn't read my mind.
> It is possible. If an email for fred.fl...@example.com or
> fr...@cs.example.com arrives, your systems put it into one mailbox. There
> is a certain rule, or database. Find out what it is and make the
> autoconfig server reflect/use that. (You can ignore forwards that the
> users create themselves, of course.)
That is what I can't do within Thunderbird. I would need to figure out
which system that firstname.lastname refers to automatically and that is
not an easy task (I'm guessing. Don't actually know. Might be easy or not).
Setting up web site and maintaining that for this insignificant problem
is probably a bit overkill anyway. It isn't any news that "too smart"
wizard guesses things wrong, so users probably are not surprised about that.
> From what I gather, this will be a *real* boon for your users.
Probably, but not useful to us here.
>> If I change those <hostname>imap.freenet.de</hostname> to
>> <hostname></hostname> etc.
>
> You mean leave it empty? No, you can't. The configuration must be final
> and correct. It is what we will create.
You mean that if wizard fails to connect with "wrong" settings it
doesn't offer possibility to fix those settings? If it does then setting
that to empty would be sufficient to prevent stupid users for
_accidentally_ getting wrong server there. I could enter right server
for 99% of cases there, but it still leaves that last problem which is
below.
> You can use the 5 placeholders (%EMAILLOCALPART% etc.), but that's it.
In that case it gets userID incorrectly as well, because that is another
thing that can't be figured out from email-address (inside Thunderbird).
I could use something like "account_ID_here" to all users, so that they
all just fix that obviously wrong one.
IE. forcing users to enter right settings instead of wizard trying to
guess them. That would be quite enough. It would still be improvement
over old (Tb2) wizard with server probing capability and automatic port
settings.
In any case I can just write documentation about how to set things for
us in account wizard (because it will guess things wrong). I'm guessing
that is sufficient for most cases. Those that are stupid enough that
they can't figure out what went wrong (and undoubtedly there will be
some) can just contact our helpdesk.
Timo Pietil�
Jaakko Luoto
> Ben Bucksch wrote:
>>> Ben Bucksch wrote:
>>>> Only you know which [servers] those are (based on domain (ideally)
>>>> or email address).
>>>
>>> No I don't. It's pure guesswork.
>>
>> If *you* as mail admin can't tell which server they need, how can users?
>
> I'm not mail admin. I do however distribute software and otherwise
> maintain workstation management systems (security, control etc.). Mail
> admins are different section of our computer management team. Remember
> that we have around 50000 users. Those few admins have enough work to do
> without individual workstation program problems.
Same here. This autoconfig web server is a great idea, but way too
difficult to kick off in a complicated University environment.
In our domain all e-mail addresses are in the form
firstname...@tut.fi, but each user has made a forwarding rule that
directs emails to a specific server, that may depend on his/her
department and personal choices (this is stored in LDAP). So making this
work would need co-operation and time of at least the web admins of
tut.fi (to create a the autoconfig.tut.fi server), and someone to code &
test the LDAP-query. And then someone should maintain it, fix possible
bugs, update it whenever new TB versions have new requirements, and so
on. All of these people are working in different departments/teams than
me, and they may not have this much time or resources to put to a single
mail client like TB.
IF there was a parameter to change the address of the autoconfig xml to
something else than autoconfig.tut.fi/... (etc), we might at least be
able to do the web server & LDAP part on our own without the need of
cross-department collaboration. But some other departments who don't
have their own web server infrastructure, would still be in problems.
Unfortunately the static autoconfig XML (placed on a web server or
deployed on local disk) is not an option for us either, because the
login account name can't be derived from "firstname.lastname". Only
chances to find it out is LDAP-query (challenging, with so many moving
parts) or user typing it manually (easy and quite failproof because they
have to type it daily somewhere anyway).
> IE. forcing users to enter right settings instead of wizard trying to
> guess them. That would be quite enough. It would still be improvement
> over old (Tb2) wizard with server probing capability and automatic port
> settings.
I am also looking for a simple way to force users to have to input their
account & server settings themselves, without any automatic guessing -
That would probably just be so much easier to implement in TB, without
having to develop the autoconfig XML thingy until it fulfills *every*
organization's and ISP's special needs.
Ben Bucksch
> In our domain all e-mail addresses are in the form
> firstname...@tut.fi, but each user has made a forwarding rule that
> directs emails to a specific server, that may depend on his/her
> department and personal choices (this is stored in LDAP).
So, if users manually chose which mail server to put their mail on, they
should know which one this is and can enter it manually.
Autoconfig is for mom&dad&claire users who have no clue what a "server" is.
Or you set up autoconfig and query LDAP, yes, if your organization uses
that. Most organizations that use LDAP say "yeah, no problem, we'll just
have to query our LDAP server". I think it would be just a few lines in
Python, Perl, PHP or your language of choice.
> So making this work would need co-operation and time of at least the web admins of
> tut.fi (to create a the autoconfig.tut.fi server),
No. You need an DNS entry, that's all. The autoconfig.tut.fi server can
be *any* server - it could be standing in France in fact. It can be the
same host as your web server (and if so, it's trivial), but doesn't have
to (that's simple, too). Yes, you need to know how to set up Apache. But
I take that for granted for admins.
Please note that users have a *real* problem with setting up accounts.
If you spend a few hours (or days) on this, these are well-spent.
Ben Bucksch
on http://example.com/.well-known/autoconfig/mail/config-v1.xml , with
"please.click.manual.config.example.org" as incoming server hostname.
But I discourage that.
Timo Pietilä
> On 21.04.2010 18:56, Jaakko Luoto wrote:
>> In our domain all e-mail addresses are in the form
>> firstname...@tut.fi, but each user has made a forwarding rule that
>> directs emails to a specific server, that may depend on his/her
>> department and personal choices (this is stored in LDAP).
>
> So, if users manually chose which mail server to put their mail on, they
> should know which one this is and can enter it manually.
> Autoconfig is for mom&dad&claire users who have no clue what a "server" is.
You think we don't have those? Think again. When autoconfig doesn't work
they get stuck. They don't know what went wrong. If it forces them to
proceed with right server, account ID etc. then they don't. Then they at
least know which setting they are missing.
> Or you set up autoconfig and query LDAP, yes, if your organization uses
> that. Most organizations that use LDAP say "yeah, no problem, we'll just
> have to query our LDAP server". I think it would be just a few lines in
> Python, Perl, PHP or your language of choice.
You are programmer, so that kind of "solution" is obviously easy to you.
Not so for me. I don't even know the system where that information is
stored.
>> So making this work would need co-operation and time of at least the
>> web admins of
>> tut.fi (to create a the autoconfig.tut.fi server),
>
> No. You need an DNS entry, that's all. The autoconfig.tut.fi server can
> be *any* server - it could be standing in France in fact. It can be the
> same host as your web server
server -> servers. Which is yet another thing that is not maintained by me.
> (and if so, it's trivial), but doesn't have
> to (that's simple, too). Yes, you need to know how to set up Apache. But
> I take that for granted for admins.
Setting some server somewhere can obviously be done. Problem is that it
needs maintaining, constant security fixes, log file monitoring, upkeep
planning, lifecycle plan etc. Too much work for this insignificant problem.
> Please note that users have a *real* problem with setting up accounts.
Not with proper documentation. Home users might not have those. Things
are different in corporate users.
> If you spend a few hours (or days) on this, these are well-spent.
Few hours setting up + few years of maintaining. No thank you.
Timo Pietilä
Timo Pietilä
That is exactly what I was talking about. It's easier to just "tell the
user what goes in which box" than to try to get autoconfig working.
Timo Pietilä
Ben Bucksch
> That is exactly what I was talking about. It's easier to just "tell
> the user what goes in which box" than to try to get autoconfig working.
Easier for you, not for the user.
Ben Bucksch
> Ben Bucksch wrote:
>> language of choice.
>
> You are programmer, so that kind of "solution" is obviously easy to you.
If you're a university, you have tons of programmers running around.
And FWIW, this was to Jaakko, not to you!
> I don't even know the system where that information is stored.
Find out! You can write endless posts here and insult us, how about
doing some actual work for your organization?
Setting up autoconfig is core to your job of caring for client software
in your organization, and would help *your* users.
But whatever. I told you everything, even how to work *against* the
autoconfig system. Your thing.
>> Please note that users have a *real* problem with setting up accounts.
>
> Not with proper documentation.
Yes, *with* documentation. All ISPs have public documentation, usually
very clear. It's nevertheless a problem.
Timo Pietilä
> On 22.04.2010 08:10, Timo Pietilä wrote:
>> That is exactly what I was talking about. It's easier to just "tell
>> the user what goes in which box" than to try to get autoconfig working.
>
> Easier for you, not for the user.
Correct. In this case however that small difficulty for user is big
benefit for sysadmins, which in turn reflects to better service when needed.
Timo Pietilä
Timo Pietilä
> On 22.04.2010 07:01, Timo Pietilä wrote:
>> Ben Bucksch wrote:
>>> I think it would be just a few lines in Python, Perl, PHP or your
>>> language of choice.
>>
>> You are programmer, so that kind of "solution" is obviously easy to you.
>
> If you're a university, you have tons of programmers running around.
Jeah, right. Those programmers that I know that know the systems well
enough and have necessary security clearances to actually do something
about it are too busy doing other stuff.
> And FWIW, this was to Jaakko, not to you!
He had same problem as I and you didn't answer to me. I don't see much
point asking same question again to get same answer from you.
>> I don't even know the system where that information is stored.
>
> Find out! You can write endless posts here and insult us, how about
> doing some actual work for your organization?
Hello? What insult? If I criticize new account wizard and not
automatically praise it how is it an insult?
Face it, there are situations where this new account wizard still fails
to do its job. For me bad thing is that it _does_ find a server and it
is a _wrong_ one, but I bet most problems you will find are that the
UserID it tries to extrapolate from email-address will go wrong to
nearly every corporate with firstname.lastname -format email-addresses.
Those usually do have different UserID than email-address.
That is not an insult. It is simple fact. Inconvenient fact maybe but
not an insult.
Note that you are talking with two different Finnish sysadmins from two
different universities. We live in small country and yet we already have
problems with our relatively small environments. I bet there are exactly
same problems in much bigger universities like some Cambridge university.
OTOH it is quite possible that they have much more strict rules how to
do things and have just abandoned TB because it is pretty bad for
roaming profiles (every mail it downloads goes to roaming-part of the
profile which is _BAD_). No program, no problems either.
We might do that same decision here too. Autoconfig or no autoconfig, TB
does some things in absolutely wrong way. However I would rather not
abandon TB because I like it. Much more than alternatives.
> Setting up autoconfig is core to your job of caring for client software
> in your organization, and would help *your* users.
Well, it's quite far from being "core of my job". I do that because I
care, but with someone else in my place we would just have abandoned TB
because it does things in wrong way. I have waited pretty patiently (I
think) for improvements in migration wizard and some other parts of the
program like that account autoconfig.
Someone else in my place would have just noticed that TB3 is utter crap
in our environment when TB2 had unpatched security hole, made an
recommendation to abandon it, removed it from client computers and then
continued his job as usual. I don't think that many other people would
have had trouble of learning about how to prevent it from downloading
stuff with config scripts, followed autoconfig setting improvements,
followed bugzilla etc for one insignificant mailer program for which we
already have several alternatives in our computers.
> But whatever. I told you everything, even how to work *against* the
> autoconfig system. Your thing.
When I asked what happens when I enter empty "<hostname></hostname>" you
answered that that is not possible. I asked why and you didn't answer.
You did answer to Jaakko about "disabling autoconfig" that entering
there "please.click.manual.config.example.org" as incoming server would
work as disabling autoconfig, which is basically opposite what you said
to me.
>>> Please note that users have a *real* problem with setting up accounts.
>>
>> Not with proper documentation.
>
> Yes, *with* documentation. All ISPs have public documentation, usually
> very clear. It's nevertheless a problem.
University is not usual ISP. We have university users with university
computers using university servers in university network. Our
information package to users is much more "direct" than any ordinary ISP
website. We even have local support guys that can come in place to help
completely clueless users within minutes. I believe this is the case for
most bigger organizations.
Corporate environment and home environments are two completely different
beasts.
Timo Pietilä
Jaakko Luoto
> On 21.04.2010 18:56, Jaakko Luoto wrote:
>> In our domain all e-mail addresses are in the form
>> firstname...@tut.fi, but each user has made a forwarding rule that
>> directs emails to a specific server, that may depend on his/her
>> department and personal choices (this is stored in LDAP).
>
> So, if users manually chose which mail server to put their mail on, they
> should know which one this is and can enter it manually.
> Autoconfig is for mom&dad&claire users who have no clue what a "server" is.
Exactly, they should know the correct one. But TB 3.0 guesses the wrong
one, and that's really confusing for a user. If it asked straight away
for a server name, i'd be happy. The
"please.click.manual.config.example.org" tip from your other post, as
ugly as it is, might work as a compromise.
> Or you set up autoconfig and query LDAP, yes, if your organization uses
> that. Most organizations that use LDAP say "yeah, no problem, we'll just
> have to query our LDAP server". I think it would be just a few lines in
> Python, Perl, PHP or your language of choice.
>
>> So making this work would need co-operation and time of at least the
>> web admins of
>> tut.fi (to create a the autoconfig.tut.fi server),
>
> No. You need an DNS entry, that's all. The autoconfig.tut.fi server can
> be *any* server - it could be standing in France in fact. It can be the
> same host as your web server (and if so, it's trivial), but doesn't have
> to (that's simple, too). Yes, you need to know how to set up Apache. But
> I take that for granted for admins.
I am administrating a single faculty in the university. Our domain is
cs.tut.fi (but emails are with the ending @tut.fi). If we asked tut.fi
admins to make a DNS entry that would point autoconfig.tut.fi ->
our-autoconfig-server.cs.tut.fi, that would make it unusable for admins
in OTHER faculties.
If there was a setting to use the our-autoconfig-server.cs.tut.fi
address directly, that would help our situation. Then we could just use
the static .xml -format, for example, without having to use LDAP at all.
> Please note that users have a *real* problem with setting up accounts.
> If you spend a few hours (or days) on this, these are well-spent.
I know, and I hope it would be that easy. But tut.fi -level services are
controlled by the central University IT management. Their solution for
us is to move our systems completely under their MS Exchange services.
Thunderbird and other open-source stuff is considered less professional
or something in the upper levels, whereas we want our users to use TB,
because its easier to support only one mail client in our cross-OS
projects and userbase. This is not where they want to "spend" recources,
as much as *I* would want them to.
Jaakko Luoto
> If there was a setting to use the our-autoconfig-server.cs.tut.fi
> address directly, that would help our situation. Then we could just use
> the static .xml -format, for example, without having to use LDAP at all.
Sorry, I was being too optimistic here, the static .xml wouldn't work
because of the firstname.lastname->accountname conversion problem.
Ben Bucksch
>>> I don't even know the system where that information is stored.
>>
>> Find out! You can write endless posts here and insult us, how about
>> doing some actual work for your organization?
>
> Hello? What insult? If I criticize new account wizard and not
> automatically praise it how is it an insult?
FWIW, I was referring to other threads where you called TB3 all kinds of
names. Or as you do right here in this post:
> TB3 is utter crap in our environment
And also to language like: "Face it", which is considered impolite in
English contexts.
I can see you are frustrated, but I wish you'd turn it into something
constructive instead of ranting. I tried to lead you to it, but you
refuse to even do the work to *investigate* what I suggest. That's when
I snapped.
> Note that you are talking with two different Finnish sysadmins from
> two different universities.
You just said you are not a sysadmin. You said setting up a virtual web
server is an insurmountable problem for you.
I have helped and answered you quite a lot, gave many constructive
suggestions, far more than reasonable given the amount of users, but you
continue to hammer on me even when I answer other people.
> You did answer to Jaakko about "disabling autoconfig" that entering
> there "please.click.manual.config.example.org" as incoming server
> would work as disabling autoconfig, which is basically opposite what
> you said to me.
I had pondered about your question and came up with this.
I still think - and said - that it's a very bad idea.
I don't know what you still want from me. I spent my private time to
give you advise how to set up an autoconfig server (and I wrote quite
some documentation about it, which cost me a lot of time), and I even
gave you the solution you demanded for, and you still rant here. What do
you want??
Ben
Ben Bucksch
> Ben Bucksch wrote:
>> On 21.04.2010 18:56, Jaakko Luoto wrote:
>>> In our domain all e-mail addresses are in the form
>>> firstname...@tut.fi, but each user has made a forwarding rule that
>>> directs emails to a specific server, that may depend on his/her
>>> department and personal choices (this is stored in LDAP).
>> So, if users manually chose which mail server to put their mail on, they
>> should know which one this is and can enter it manually.
>> Autoconfig is for mom&dad&claire users who have no clue what a "server" is.
> Exactly, they should know the correct one. But TB 3.0 guesses the wrong
> one, and that's really confusing for a user. If it asked straight away
> for a server name, i'd be happy.
Ah, I don't remember you mentioning that it guesses the wrong config
(Timo did). Guessing the wrong config is indeed very confusing and bad.
I still think that it's partially a problem with your setup, but also
partially with the whole idea of guessing. We try hard to get it right,
and I think it's extraordenary cases like yours where we get it wrong. I
personally think that those organizations setting up an autoconfig
server (serving the *right* config) is a fair compromise for those rare
cases.
> The "please.click.manual.config.example.org" tip from your other post, as
> ugly as it is, might work as a compromise.
Yes, if (and only if) you really really can't provide the correct config
either and the user knows it anyways.
> If there was a setting to use the our-autoconfig-server.cs.tut.fi
> address directly, that would help our situation. Then we could just use
> the static .xml -format, for example, without having to use LDAP at all.
>
FYI, if you can make a setting, that means you distribute your own
Thunderbird for cs.tut.fi users?
If that's the case, you can use the static XML files in the installation
folder.
See
<https://developer.mozilla.org/En/Thunderbird/Autoconfiguration#How_to_add_support_for_your_domain>.
Timo Pietilä
> On 22.04.2010 14:57, Timo Pietil� wrote:
>>>> I don't even know the system where that information is stored.
>>>
>>> Find out! You can write endless posts here and insult us, how about
>>> doing some actual work for your organization?
>>
>> Hello? What insult? If I criticize new account wizard and not
>> automatically praise it how is it an insult?
>
> FWIW, I was referring to other threads where you called TB3 all kinds of
> names. Or as you do right here in this post:
>
>> TB3 is utter crap in our environment
That is what it is. In our environment. 3.1 is better. And probably 3.0
is too once those biggest design flaws have been fixed.
> I can see you are frustrated, but I wish you'd turn it into something
> constructive instead of ranting. I tried to lead you to it, but you
> refuse to even do the work to *investigate* what I suggest. That's when
> I snapped.
I have investigated some. You are not authority to me, so I do as mcuh
work as I wish in this area, nothing more.
>> Note that you are talking with two different Finnish sysadmins from
>> two different universities.
>
> You just said you are not a sysadmin.
Where? I'm sysadmin, just not _mail_ sysadmin. We have over 200 IT
professionals working here. At least 50 of those are more or less
"sysadmins". I'm just one of those.
> You said setting up a virtual web
> server is an insurmountable problem for you.
No, I said it is too much work. I didn't say setting one up is a
problem. Maintaining it is. I just don't have time for that. Nobody here
has.
> I have helped and answered you quite a lot, gave many constructive
> suggestions, far more than reasonable given the amount of users, but you
> continue to hammer on me even when I answer other people.
Where do I hammer _you_? Seriously? I have said that autoconfig doesn't
do its work for us here and you have told us several options that do not
help much and one that might help. I have commented those, but I don't
remember hammering _you_. Maybe you take criticisms toward autoconfig a
bit too personally.
>> You did answer to Jaakko about "disabling autoconfig" that entering
>> there "please.click.manual.config.example.org" as incoming server
>> would work as disabling autoconfig, which is basically opposite what
>> you said to me.
>
> I had pondered about your question and came up with this.
OK. That's good if it works. If it doesn't then I still have unsolvable
dilemma. I hope it works.
> I still think - and said - that it's a very bad idea.
To us it is not.
> I don't know what you still want from me.
Nothing actually. I didn't ask you to answer to my original post. It was
just pondering about unsolvable dilemma. It was completely your idea to
answer at all. I wasn't even expecting any answer. After you answered I
asked you few questions and you have now answered to those. Anyway there
is nothing personal there. Just conversation about autoconfig
shortcomings. You giving me options, and I (and Jaakko) telling why
those are not practical.
We both are satisfied about static XML dummy placeholder solution (if it
works).
> I spent my private time to
> give you advise how to set up an autoconfig server (and I wrote quite
> some documentation about it, which cost me a lot of time), and I even
> gave you the solution you demanded for, and you still rant here.
Well, as long as you keep asking something or giving solutions that
don't help I will be answering to you and explaining why that solution
doesn't work or whatever you did ask.
> What do
> you want??
Like here. Even if had nothing to say about this issue anymore you
asked, so polite thing is to answer:
Originally my post was a comment to point out that new autoconfig system
still fails in some cases. That point is still valid. That was supposed
to just make developers aware of such situation. Maybe correct system
accordingly, if there is a way to improve UI further. I gave two
possible ways to correct that: defaultPref with config script (which had
to be used by most bigger organizations anyway, if they want to keep
using TB) or with wizard asking server instead of guessing it.
Like you said, that XML can help (or autoconfig server) in most cases if
someone cares to examine those things. If that XML can be used to fill
in dummy placeholders that say "Your account here" and "Your incoming
server here" then that is sufficient to me. I haven't got time yet to
test if that works but I hope it works. If it does, then that *is* valid
configuration method to "mix" autoconfig (with very useful server
probing) and manual entering right values to places where wizard would
fail. Good enough to put in some FAQ actually.
Timo Pietil�
Timo Pietilä
> FYI, if you can make a setting, that means you distribute your own
> Thunderbird for cs.tut.fi users?
Quick comment: that is the case for every organization where users are
not allowed to install software. That means any large corporate or
university. We need to set default things and disable auto-updates etc.,
because users can't do those themselves. Users do not have admin-rights
to their computers.
So: static "within distribution package" -solutions are valid to pretty
much any corporation.
Timo Pietilä
Jaakko Luoto
>> Exactly, they should know the correct one. But TB 3.0 guesses the wrong
>> one, and that's really confusing for a user. If it asked straight away
>> for a server name, i'd be happy.
>
> Ah, I don't remember you mentioning that it guesses the wrong config
> (Timo did). Guessing the wrong config is indeed very confusing and bad.
> I still think that it's partially a problem with your setup, but also
> partially with the whole idea of guessing. We try hard to get it right,
> and I think it's extraordenary cases like yours where we get it wrong. I
> personally think that those organizations setting up an autoconfig
> server (serving the *right* config) is a fair compromise for those rare
> cases.
I pointed out the wrong-guessing, but it was in another thread ("TB2 ->
TB3 in corporate environment"). Timo's problems with TB3-deployment have
been so much similar to mine, so I haven't felt necessary to repeat
them. I also believe that they have prevented many other organizations
from deploying TB2 - I've spoken with a few colleagues from other
educational institutions in Finland, and none of those with a proper
deployment tool (SCCM, .MSI...) are deploying TB 3.0. It's only been
used in less controlled environments where users install mail clients
themselves.
>> The "please.click.manual.config.example.org" tip from your other post, as
>> ugly as it is, might work as a compromise.
>
> Yes, if (and only if) you really really can't provide the correct config
> either and the user knows it anyways.
Wouldn't it be a much cleaner solution if there was a preference for
starting the manual config automatically? Shouldn't be difficult to
develop. Even without those "tons of programmers running around"... :)
I have one (perhaps even better) idea:
If the autoconfig XML-file format supported one more placeholder:
%USERNAME% (or something similar), which contained the name of the
account under which the Thunderbird process is running, the problem
would be solved in my environment. We use the same accounts for desktop
use and for logging to the mail server. This way we could deploy a
static XML without the "please.click.manual" hack, and I think most of
our users (the ones that are using the faculty's primary mailserver, at
least) would get the automatic configuration as easily you have intended.
>> If there was a setting to use the our-autoconfig-server.cs.tut.fi
>> address directly, that would help our situation. Then we could just use
>> the static .xml -format, for example, without having to use LDAP at all.
>
> FYI, if you can make a setting, that means you distribute your own
> Thunderbird for cs.tut.fi users?
> If that's the case, you can use the static XML files in the installation
> folder.
Yeah, that was a brainfart - I had forgotten the
firstname.lastname->account conversion problem. But yes, I distribute my
self-made MSI packages of Firefox & Thunderbird with several other added
and modified files and some extensions bundled.
Kent James
>> Find out! You can write endless posts here and insult us, how about
>> doing some actual work for your organization?
>
> Hello? What insult? If I criticize new account wizard and not
> automatically praise it how is it an insult?
>
Hi Timo,
While your posts are sometimes, shall I say, counter-cultural to the
prevailing standard here, I do hope that you do not get discouraged, and
keep posting. Thunderbird needs to better understand its deficiencies in
environments beyond the individual user, and you are providing valuable
insights to many of us.
rkent
Timo Pietilä
> I have one (perhaps even better) idea:
>
> If the autoconfig XML-file format supported one more placeholder:
> %USERNAME% (or something similar), which contained the name of the
> account under which the Thunderbird process is running, the problem
> would be solved in my environment. We use the same accounts for desktop
> use and for logging to the mail server.
That would work here too. Also I believe in almost any bigger
organizations. Good thinking. So obvious that it's embarrassing that I
didn't think that too.
Just out of curiosity I checked few other universities (around the
world) and quite a few of them had instructions how to create email
alias for firstname.lastname -format. Almost in all cases that one loses
the vital part of the domain -part of the email-address and without
specially crafted autoconfig setting that autoconfig would fail for both
userID and server. Same happens in government email-addresses etc.
This new and improved autoconfig still fails without local admins doing
extra work. However with *that* change you propose only server is
something that needs to be set for those environments. And I believe 99%
of those cases do not have that unfortunate case I have.
So:
Designers!! Note this.
One other thing for UI:
If TB already has SMTP-server that is set as default, autoconfig should
at last offer that for new accounts. This wouldn't always work (because
username for that smtp-server might be different), but offering it would
at least be improvement.
Timo Pietilä
Jaakko Luoto
> Jaakko Luoto wrote:
>
>> I have one (perhaps even better) idea:
>>
>> If the autoconfig XML-file format supported one more placeholder:
>> %USERNAME% (or something similar), which contained the name of the
>> account under which the Thunderbird process is running, the problem
>> would be solved in my environment. We use the same accounts for desktop
>> use and for logging to the mail server.
>
> That would work here too. Also I believe in almost any bigger
> organizations. Good thinking. So obvious that it's embarrassing that I
> didn't think that too.
>
> Designers!! Note this.
Great! I filed a bug for this, we'll see what happens:
https://bugzilla.mozilla.org/show_bug.cgi?id=561531
BTW, I also noticed the "User input fields" part in this page:
https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat
That userinput element seems interesting too, but requires unwanted user
interaction, so I hope that at least the placeholder idea gets to TB 3.1.
Ben Bucksch
> [OS username]
> https://bugzilla.mozilla.org/show_bug.cgi?id=561531
>
> BTW, I also noticed the "User input fields" part in this page:
> https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat
Yes, that's what will solve this eventually. This allows config files to
specifically ask the user for a certain value - with custom label, so
you can use your organization's terminology, given that there are often
several values which would be candidates for "username" - maybe not in
your case, but in many others.
This is the proper solution.
Using the OS username is a nice idea, but has a conceptual problem: It's
not based on the email address entered at all, so associated with that
only via real-life factors, which may change. Let's say a user has 2
login accounts at your organization, for whatever reason. Surely, he'll
want to check mail for both. The wizard will prefill the wrong value.
Luckily, the problem is - assuming good UI - hopefully noticable and
obvious to fix: Click [Manual config], change this one value (given the
prefilled value as example, the correct value is now obvious), [Create
Account]. Other problem: It does nothing to help users who want to check
mail from home.
Ben
Timo Pietilä
> On 24.04.2010 09:10, Jaakko Luoto wrote:
>> [OS username] https://bugzilla.mozilla.org/show_bug.cgi?id=561531
>>
>> BTW, I also noticed the "User input fields" part in this page:
>> https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat
>>
>
> Yes, that's what will solve this eventually. This allows config files
> to specifically ask the user for a certain value - with custom label,
> so you can use your organization's terminology, given that there are
> often several values which would be candidates for "username" - maybe
> not in your case, but in many others. This is the proper solution.
>
> Using the OS username is a nice idea, but has a conceptual problem:
> It's not based on the email address entered at all
I think Jaakkos point was that this should be possible to enter in
autoconfig-XML. That solves many problems for most of us. It obviously
should not be "default" in there because home users would then be
screwed. Anyway corp. sysadmins need to set things like that for their
distribution package anyway, so possibility to use login username there
would be great improvement.
> hopefully noticable and obvious to fix: Click [Manual config], change
> this one value (given the prefilled value as example
Why click manual config at all? Just show user prefilled sheet with all
fields changeable right there.
Timo Pietil�
Jaakko Luoto
>>> BTW, I also noticed the "User input fields" part in this page:
>>> https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat
>>
>> Yes, that's what will solve this eventually. This allows config files
>> to specifically ask the user for a certain value - with custom label,
>> so you can use your organization's terminology, given that there are
>> often several values which would be candidates for "username" - maybe
>> not in your case, but in many others. This is the proper solution.
>>
>> Using the OS username is a nice idea, but has a conceptual problem:
>> It's not based on the email address entered at all
>
> I think Jaakkos point was that this should be possible to enter in
> autoconfig-XML. That solves many problems for most of us. It obviously
> should not be "default" in there because home users would then be
> screwed. Anyway corp. sysadmins need to set things like that for their
> distribution package anyway, so possibility to use login username there
> would be great improvement.
>
> all fields changeable right there.
Yep, that User Input Fields functionality doesn't really solve this.
It's just one more way to force a user to input some of the fields. In
my opinion, the easiest way to solve this in a way which requires user
interaction, would be to present changeable default/guessed settings to
the user straight away, as Timo suggested in the quote under this.
But I really would like to solve this in a way which wouldn't require
any interaction from the user (or at least 90% of the users) AND we
could do this completely with a MSI package containing some settings.
The bug that I filed would make this possible.