-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 12 Nov 2008, Daniel L. Miller wrote:
I don't if this has been discussed before - or already implemented - but it would be great if I could define one or more "aliases" for a folder. A particular example might be "Sent" where different (badly-written) clients might have hard-coded "Sent" folder locations like "Sent", "Sent Items", "Sent Mail", "Mail Delivered", etc. - and I'd love to get those consolidated.
It would also be nice to show a different set of folders based on the client the login sequence) then somehow via login name - maybe by an extension? So
- or if that's not possible (if the client doesn't identify itself as part of
where my usual login might be "user@domain.com", and that would continue to be supported as the default login, I could now have "user@domain.com+thunderbird", "user@domain.com+mobile", etc.?
Because the IMAP client does not identify itself, the server does not know, which alias to return to the client. I'm not convinced that the extension method you describe will be widely accepted.
I definitely would like a solution for this problem as well.
But if the server would return all aliases, most recent clients will at least download all headers from all of them (not knowing about that they are all equal); if the server would return just one alias, the client would assume that its folder has been deleted and redownload the sent message as soon as the folder re-appears.
I wonder whether the users would accept, if the sent items are located in one specified folder (say "sent-mail"), but the other aliases are "virtual" folders, which are always empty and when a message is placed there, it is placed into the main folder actually. The users (of such badly written IMAP clients, in which you cannot select the actual name of the Sent-Folder) can not use the built-in sent-folder anymore, but need to select one "normal"-looking folder named "sent-mail" explicitly.
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFJG9z5VJMDrex4hCIRApCdAJ4xoW01wkoHCdRyTqDjegtiOMxS8QCfaRu8 t5Lj6BCmXnjKXbt8YOOZo1E= =iLGu -----END PGP SIGNATURE-----