Why force user to test/re-test new account? Outrageously lame.
The automatic e-mail account setup feature was installed by the original Mozilla team in a deliberate attempt to make it nearly impossible for someone to configure their own e-mail. Why? Because they were getting paid by some outside e-mail service provider for every new e-mail subscriber. This outrageous abuse of the open-source net-neutral ethos upon which the Internet was founded occurred so long ago, I can't even remember the year. But I've just spent a couple of hours battling this automatic-setup malware, which should have been ripped out of the product years ago.
The solution is painfully simple: Ask the user if they want to use the 'Automatic e-mail setup program', 'Yes or No?' If not, let us setup the new account using the advanced setup screen! Is that so tough?
(Yes, I realize that if you interrupt the 're-test' function and select manual configure, then ignore the prompt to do a 're-test', and select Advanced Setup instead, you can finish configuring the new account in peace. But once the user says they want to manually configure the account, why keep hounding them to run a test process which is almost certain to fail? (Thats why we select manual configure...because we may not have a server that conforms to whatever your re-test function expects.)
Both Thunderbird and Firefox started out as great open-source projects, which together helped end the Microsoft monopoly over desktop computing. Its unfortunate that the original operators of Mozilla decided they wanted to be billionaires too...which is why so many forks of original Mozilla products have been built. (Thanks to the original intent of open-source software development.)
All Replies (5)
You seem to be talking about autoconfig. Autoconfig is not specific to vendors - it allows any organization to configure account settings to benefit their users.
Further, autoconfig predates Thunderbird accepting money for paid accounts by half a decade (iirc).
Thanks for your prompt reply.
Just to re-state what I posted (?) years ago when this 'feature' first appeared: I have no problem with Mozilla (or whoever) taking a referral fee when an end-user who needs to sign up for an e-mail account, decides to opt-in to whatever third-party e-mail account provider they've contracted with for that purpose. Its a perfectly legitimate way to fund an open-source app, particularly one as critical & beneficial as Firefox & Thunderbird have been.
My problem is with the attempt to make it difficult (if not impossible) to opt-out, and do the config manually -- as was the case when this bright idea first showed up.
At that time, in order to get around it, I had to go into the Thunderbird profile/javascript and manually clone a pop3 account at that level to get it done. After that, I setup dummy accounts on a private server of mine so I could add them, pass the verification, then go back modify the config more easily with the actual parameters, just to avoid having to deal with the verification process. But even as it stands now, its not clear how you get around 'IMAP' and, the 're-test', leaving trial-and-error.
I am very hopeful that the new team developing Thunderbird will respect the spirit of open-development by respecting the user base, something Mozilla stopped doing after they achieved such success with Firefox and Thunderbird.
A good place to start? Modify the current Thunderbird account add/configure protocol by...
1. Allowing the user to select IMAP or POP3 at the outset. 2. Making the server-identification test optional.
...as it should be.
(Thanks for listening.)
Have you even tried to set up an account in version 60?
a) It doesn't offer a vendor supplied, paid account as it's first choice
b) the autoconfig ends after a couple seconds, and even if it doesn't you can click "cancel" at any point to do manual config to accomplish your #1 above
There's no question but that the version I've been using (60.2.1) solves most of the problems which began when Mozilla introduced the 'e-mail server database/access test', and the for-profit e-mail address sales robot. (IMHO) the advanced configuration screens still have some rough edges and confusing aspects to them, but I opted not to mention them.
Instead, I proposed two of the most trivially easy modifications to the existing code imaginable:
1. A new select list (IMAP/POP3) on the "Set Up an Existing Email Account"
Its hard to come up with a rationale for not including that in the initial set of inputs, given the distinctly different configuration options the choice implies. And its worth mentioning: calling the dialogue "Set up an Existing Email..." jumps to the conclusion that there is an existing email account -- on some server 'out there somewhere'. Isn't the real primary purpose of the account setup option simply to configure another e-mail identity within the context of Tbird's internal construct of enumerated identities?
Providing a way to quickly ascertain whether a given Tbird-identity can contact its target server is arguably the last step in the process (and a handy feature). However, in my view, it ought never be an impediment to setting up new account IDs. I can certainly imagine a scenario where it would be quite reasonable for an administrator to want to setup a series of dummy account IDs for a given instance of Tbird -- and not have to actually create all the accounts on the server until the client needed them.
2. Changing the "run server test" from automatic, to user selectable.
As originally implemented, the end user literally had to have a live, active e-mail account on a server in order to continue configuring the local identity, and as such, one of the most egregiously obvious examples of software designed to coerce the end-user into buying something they might not want or need.
I don't know if you have noticed, but this 'mentality' -- trick users into 'clicking on things', or, start downloading/playing videos or audio tracks, without asking the user's permission. Posting fake headlines, fake descriptions of media, fake assertions that something is 'free'. Creating domain names that make the end-user believe they're visiting a known, trusted provider website, when in fact, its some untraceable boiler operation, attempting to drag them into some scam.
All of this has become pandemic on the Internet. Almost every government, and tens of thousands of private corporate enterprises are all piling on, engaging in these tactics. In my view, the only hope we have of preventing this scourge from ruining the Internet (and most of the promise it once offered), starts with the open-source, not-for-profit developer community.
(...which is the only reason I've continued to argue this rather trivial example thus far, and why this will be my last reply on the subject. If the new developer community wants to fix it, I hope they do, but as far as I'm concerned, I have reasonable work-arounds.)
I do not think a full manual anything is going to happen, so like all the rest of us you will remain with a pet peeve. Mine are anti virus products, the difficulty in making profile backups, moving to a new device, opening the profile manager and the fact the auto config will create a duplicate account name.
This is however a user support form, in it not for the purpose of discussion of the development process. If you wish to file an enhancement bug in bugzilla, please do. That is the venue for requesting change to the program.