-----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
- or if that's not possible (if the client doesn't identify itself as part of
the login sequence) then somehow via login name - maybe by an extension? So
where my usual login might be "[EMAIL PROTECTED]", and that would continue to
be supported as the default login, I could now have
"[EMAIL PROTECTED]", "[EMAIL PROTECTED]", 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-----
