[Dovecot] Folder Aliases - Revisited Yet Again
I just did a search through my archives - seems this topic has been requested a few times since my posting two years ago. I asked about a specific implementation - which Mr. Sirainen never commented on. He was probably focused on something more important at the time - like a paying job. So I'll ask again...
Calling Timo!
If we can't get clients to agree on a "standard" set of folders (probably reasonably safe assumption) and if protocol implementations of variations of "*LIST*" are too far in the future...what about having alternative folder names presented based on login name - maybe by an extension? So 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.?
And each of those extensions would then have a system-wide map defining folder name relationships, like "Sent=Sent Items". Does this seem doable?
On Thu, 2010-08-12 at 17:04 -0700, Daniel L. Miller wrote:
If we can't get clients to agree on a "standard" set of folders (probably reasonably safe assumption)
Actually that assumption might go away :) Google implemented XLIST extension for GMail that flags the special mailboxes. iPhone at least supports that, possibly some others too. Now morg group is trying to get that standardized, and Google has promised to implement it also: http://tools.ietf.org/html/draft-ietf-morg-list-specialuse-02
and if protocol implementations of variations of "*LIST*" are too far in the future...what about having alternative folder names presented based on login name - maybe by an extension? So 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.?
This part can already be done with some passdbs and userdbs. You just need to have the userdb return some client=thunderbird/mobile/etc extra field.
And each of those extensions would then have a system-wide map defining folder name relationships, like "Sent=Sent Items". Does this seem doable?
This is more troublesome.. You could probably hack something horrible by having each client use a different maildir and use symlinks. Or I guess you could also create listescape-like plugin that changes some mailbox names. Hmm. Yeah, that might work.
I'm kind of annoyed with listescape though. Hopefully for v2.1 I can figure out some API changes to make it much easier to modify mailbox names, and I guess also make such aliasing plugin much easier to implement.
On 8/13/2010 6:07 AM, Timo Sirainen wrote:
On Thu, 2010-08-12 at 17:04 -0700, Daniel L. Miller wrote:
If we can't get clients to agree on a "standard" set of folders (probably reasonably safe assumption)
[...]
I'm kind of annoyed with listescape though. Hopefully for v2.1 I can figure out some API changes to make it much easier to modify mailbox names, and I guess also make such aliasing plugin much easier to implement.
Did you happen to look into this in your spare time?
On 11.4.2012, at 8.06, Daniel L. Miller wrote:
On 8/13/2010 6:07 AM, Timo Sirainen wrote:
On Thu, 2010-08-12 at 17:04 -0700, Daniel L. Miller wrote:
If we can't get clients to agree on a "standard" set of folders (probably reasonably safe assumption)
[...]
I'm kind of annoyed with listescape though. Hopefully for v2.1 I can figure out some API changes to make it much easier to modify mailbox names, and I guess also make such aliasing plugin much easier to implement.
Did you happen to look into this in your spare time?
Yes, this is much easier with v2.1 I think. The new listescape plugin is just a tiny wrapper that will probably just be replaced by a setting some day in future. I haven't actually tried to write such alias plugin though.
On 11.4.2012, at 8.12, Timo Sirainen wrote:
Yes, this is much easier with v2.1 I think. The new listescape plugin is just a tiny wrapper that will probably just be replaced by a setting some day in future. I haven't actually tried to write such alias plugin though.
Here: http://dovecot.org/patches/2.1/mailbox-alias-plugin.c
But as it is, it doesn't really work in a useful way, since e.g.:
x create real x OK Create completed. x list "" real x OK List completed. x list "" alias
- LIST (\HasNoChildren) "/" "alias"
x OK List completed. x create real x NO [ALREADYEXISTS] Mailbox already exists x status real (messages)
- STATUS "real" (MESSAGES 0)
x OK Status completed.
Perhaps a more useful feature would be if LIST showed both alias and real? That would need a bit more code.
participants (2)
-
Daniel L. Miller
-
Timo Sirainen