Outlook Express allow you to change that. I can't see reason this is not allowed.
17 years ago
The reason is that no one has written the code yet. Patches accepted. :) Duplicate of "UI: Account Settings, Server Panel, username & Server Name not editable" Thanks for using Mozilla and reporting bugs! *** This bug has been marked as a duplicate of 14295 ***
This does not appear to be a duplicate of the UI bug 14295. And it certainly is not fixed.
I'm able to change the servername and username, and pretty much everything else without any problem. The only thing I don't see the option to change is the server type, which probably rarely if ever needs to be changed, and incidentally, which Outlook Express doesn't allow changing either, other than the account type, the account settings are fully editable under SeaMonkey 1.1b Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061101 SeaMonkey/1.1b, and Thunderbird.
Hmmm, not sure why I made that comment back in June, but I think what I meant was, that I thought the poster was complaining s/he can't turn a POP account into an IMAP account, and vice versa after, creating the account.
Oh.. it is a very old bug I reported. That was because my company changed the mail server from a POP to a IMAP. I wanted to keep all the settings (filter, mail folders..etc.) I think it is a 'nice to have' since it is not common that a server type will change.
one major roadblock I see to this feature actually happening is that the method of storage and method of retrieval for mail are not decoupled. for instance IMAP mail lives under different folders to POP3 mail, so to change mailbox type / retrieval protocol would require moving all the mail. Maybe should decouple the store from the protocol first.
The perfect might be the enemy of the good here. It wouldn't be too hard to write code to allow changing of the account type by essentially creating a new account, removing the old account, and fixing up the identity to use the new account's special folders. In the case of converting a pop3 account to imap, we'd need to save the existing folders, perhaps by moving them into the local folders account, like we do for import. For imap to pop3, we wouldn't need to do that, and the most common usage case for us now is users who've been led down the imap path by autoconfig, but really want pop3. For the imap to pop3 case, we probably would want to create local folders out of the imap folders on the server, if any. I suppose we could optionally do that for the pop3 to imap case, if the user wants us to. The main problem with converting filters is converting the move/copy filter action target uri's. If we've converted folders, then the folders should exist, and this would be relatively easy. It wouldn't deal with other accounts' filters that point into this account, but I don't think that's a big deal.
(In reply to comment #8) > > Maybe should decouple the store from the protocol first. The difference between IMAP and POP3 is that one has storage on the server itself, one has it on the client. There's no decoupling that makes that difference go away. Our IMAP offline stores already look exactly like our local berkeley mailbox format folders, but there's no guarantee that offline storage is turned on.