jbdovecot at fcgh.net
2008-Oct-03 18:44 UTC
[Dovecot] Feature wish: "Virtual" POP3 folder with IMAP
Hallo, is it possible to implement a "flat folder view" for POP3 users? The problem is that POP3 only knows one folder: INBOX. Now, if a user logs in via POP3, he won't see messages that live outside the INBOX folder - this could be e.g. a *SPAM*-flagged message moved to another folder via Sieve/LDA/other mechanism. What about adding a feature `pop3_remap_folders` to virtually place *all* messages spread across different folders inside INBOX, only for the POP3 session, and without impact on the actual folder structure as seen thru IMAP? I see some issues though: - How would SENT and TRASH be handled? These special folders shouldn't be part of the game. - What happens if the POP3 client deletes a message, which is the default behavior of Outlook and friends? Proposed logic: really delete message if not logged in via IMAP since ($filemtime_of_message - $user_configurable_amount_of_seconds), else gracefully ignore client's delete request. This *could* become a problem if quotas are enabled, but then again it should be the admin's decision to offer this feature to his users. - Message IDs: Would the above Delete-only-if workaround confuse some mail clients and make them download the same messages over and over? - Perhaps another way: create a separate POP3 directory inside the mailbox, only used by dovecot-pop3. Inside reside symlinks to the actual messages spread across different IMAP folders, which can safely be deleted by a POP3 client and also following the real-delete logic described above. The benefit of such a virtual folder remapping would be great for systems also using webmail and/or Sieve. Regards, James -- jbdovecot at fcgh.net
on 10-3-2008 11:44 AM jbdovecot at fcgh.net spake the following:> Hallo, > > is it possible to implement a "flat folder view" for POP3 users? > > The problem is that POP3 only knows one folder: INBOX. Now, if a user logs > in via POP3, he won't see messages that live outside the INBOX folder - this > could be e.g. a *SPAM*-flagged message moved to another folder via > Sieve/LDA/other mechanism. > > What about adding a feature `pop3_remap_folders` to virtually place *all* > messages spread across different folders inside INBOX, only for the POP3 > session, and without impact on the actual folder structure as seen thru > IMAP? > > I see some issues though: > > - How would SENT and TRASH be handled? These special folders > shouldn't be part of the game. > > - What happens if the POP3 client deletes a message, which is the > default behavior of Outlook and friends? Proposed logic: really delete > message if not logged in via IMAP since ($filemtime_of_message - > $user_configurable_amount_of_seconds), else gracefully ignore client's > delete request. This *could* become a problem if quotas are enabled, but > then again it should be the admin's decision to offer this feature to his > users. > > - Message IDs: Would the above Delete-only-if workaround confuse > some mail clients and make them download the same messages over and over? > > - Perhaps another way: create a separate POP3 directory inside the > mailbox, only used by dovecot-pop3. Inside reside symlinks to the actual > messages spread across different IMAP folders, which can safely be deleted > by a POP3 client and also following the real-delete logic described above. > > The benefit of such a virtual folder remapping would be great for systems > also using webmail and/or Sieve. >A pop3 user probably wouldn't be using any server side filtering. If you have mostly pop3 users you should be just adding headers or modifying the subject so they can client side filter them. I don't think there should be any default server side filtering except for either tagging or deleting said flotsam. A user should be technically able to know how and what the filters are and how to use them, and be using IMAP if he wants server side filtering that moves mail around. Besides what you propose probably violates a few RFC's. -- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20081003/6d20c5d6/attachment-0002.bin>
Heiko Schlichting
2008-Oct-03 23:02 UTC
[Dovecot] Feature wish: "Virtual" POP3 folder with IMAP
James wrote:> is it possible to implement a "flat folder view" for POP3 users?No. If you need folder, use IMAP. If you need Sieve, use IMAP. If you need Sent or Spam folders, use IMAP. POP3 is limited and it is neither possible nor useful to simulate IMAP behavoir with POP3. That's the reason why IMAP was invented. Heiko Heiko Schlichting Freie Universit?t Berlin heiko at FU-Berlin.DE Zentraleinrichtung f?r Datenverarbeitung (ZEDAT) Telefon +49 30 838-54327 Fabeckstra?e 32 Telefax +49 30 838454327 14195 Berlin
Timo Sirainen
2008-Oct-04 12:48 UTC
[Dovecot] Feature wish: "Virtual" POP3 folder with IMAP
On Fri, 2008-10-03 at 20:44 +0200, jbdovecot at fcgh.net wrote:> is it possible to implement a "flat folder view" for POP3 users?v1.2 has virtual mailboxes where you could create a virtual INBOX for POP3 users.> - What happens if the POP3 client deletes a message, which is the > default behavior of Outlook and friends? Proposed logic: really delete > message if not logged in via IMAP since ($filemtime_of_message - > $user_configurable_amount_of_seconds), else gracefully ignore client's > delete request. This *could* become a problem if quotas are enabled, but > then again it should be the admin's decision to offer this feature to his > users. > > - Message IDs: Would the above Delete-only-if workaround confuse > some mail clients and make them download the same messages over and over?Probably. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20081004/374d1733/attachment-0002.bin>
Possibly Parallel Threads
- [Bug 9103] New: ext4 creation timestamp
- RPM package wish list
- To those of you who wish to help keep Shorewall going
- wish list for table column sorting
- CRC Checksum problems causing issues with bridging and maybe things like nfs. Wish we had better documentation. (was Re: XenNetworking - Reason for NOARP on eth1/br1?)