Hi all, I''ve been using sup for a few days now, and I have to say, I''m absolutely in love with the concept!! I''m only getting used to archiving threads immediately and trusting sup to bring it back up when something new happens, but my mail processing has never been that efficient. Thank you very much! There is one niggle though, that bothers me. I am using offlineimap to sync an IMAP server with the local maildir that sup works on. That works rather nicely for one direction (IMAP -> local), but when I work on my local maildir (read mails, delete them, mark them as spam), changes don''t get propagated back to the server. I think this might be due to the fact that my sup doesn''t seems to move mail from the new/ to the cur/ dir of mein mailbox and therefor never any flags (Seen, Thrashed) are added? This is quite unpleasant to me, since that means that the inbox on the mail server (that other clients like a web mailer and a thunderbird at work use) stays cluttered with the usual bunch of mails arriving. So I enjoy being able to efficiently organize my mail when working from my box, but everytime I am away from it and I therefor have to use another client, I am presented with a mailbox that not only intermingles my legitimate mail with the occasional spam getting through and the mail I already dismissed (deleted), it not even has the mails I already processed marked as read. This is a pretty huge deal for me. I do imagine though that quite a few of you are using a similar setup. Can you please tell me how you handle the situation? Why doesn''t my sup add the correct maildir flags? Am I holding it wrong? -.- tia for you support! dtk
Hello, By default sup doesn''t modify the sources at all. There is a branch that allows backward synchronization, you will find more informations at the following address: http://www.mail-archive.com/sup-devel at rubyforge.org/msg00983.html Cheers, Excerpts from dtk''s message of lun. avril 11 10:08:52 +0200 2011:> Hi all, > > I''ve been using sup for a few days now, and I have to say, I''m absolutely in > love with the concept!! I''m only getting used to archiving threads immediately > and trusting sup to bring it back up when something new happens, but my mail > processing has never been that efficient. Thank you very much! > > There is one niggle though, that bothers me. I am using offlineimap to sync an > IMAP server with the local maildir that sup works on. That works rather nicely > for one direction (IMAP -> local), but when I work on my local maildir (read > mails, delete them, mark them as spam), changes don''t get propagated back to the > server. > I think this might be due to the fact that my sup doesn''t seems to move mail > from the new/ to the cur/ dir of mein mailbox and therefor never any flags > (Seen, Thrashed) are added? > This is quite unpleasant to me, since that means that the inbox on the mail > server (that other clients like a web mailer and a thunderbird at work use) > stays cluttered with the usual bunch of mails arriving. > So I enjoy being able to efficiently organize my mail when working from my box, > but everytime I am away from it and I therefor have to use another client, I am > presented with a mailbox that not only intermingles my legitimate mail with the > occasional spam getting through and the mail I already dismissed (deleted), it > not even has the mails I already processed marked as read. > This is a pretty huge deal for me. > > I do imagine though that quite a few of you are using a similar setup. Can you > please tell me how you handle the situation? Why doesn''t my sup add the correct > maildir flags? Am I holding it wrong? -.- > > tia for you support! > dtk-- Damien Leone <damien.leone at fensalir.fr> GPG: 0x82EB4DDF
> === dtk schrieb am 2011-04-11 10:08: === <> So I enjoy being able to efficiently organize my mail when working from my box, > but everytime I am away from it and I therefor have to use another client, I am > presented with a mailbox that not only intermingles my legitimate mail with the > occasional spam getting through and the mail I already dismissed (deleted), it > not even has the mails I already processed marked as read. > This is a pretty huge deal for me. > > I do imagine though that quite a few of you are using a similar setup. Can you > please tell me how you handle the situation? Why doesn''t my sup add the correct > maildir flags? Am I holding it wrong? -.-Thou shalt not have another e-mail client beside of sup -- because sup does not change the e-mail sources, and if other mail clients change sources, sup won''t be able to find the emails any longer. There are some workarounds for this, I installed sup on a PC I can access via dyndns, run sup there and log in with ssh to read my mail from different locations. Disadvantage: I cannot view attachements where I need a framebuffer device. Well -I could reconfigure my mailcap to use X-programs to view attachments and use ssh with X-forwarding, might work. William Morgan is working on a server - client based solution that will solve this problem, but I don''t dare to try it yet - being not work in progress, but yet in development. Greetings, Ruthard
Hi Damien, Excerpts from Damien Leone''s message of Mon Apr 11 11:22:09 +0200 2011:> By default sup doesn''t modify the sources at all.why is that? I thought the way a MUA is supposed to work with a maildir is rather straight forward[0]?> There is a branch > that allows backward synchronization, you will find more informations > at the following address: > > http://www.mail-archive.com/sup-devel at rubyforge.org/msg00983.htmlThanks for the hint!! I am a bit suspicious, though :| I don''t know much about git, but doesn''t that essentially mean that the branch is always stuck behind the features in master until the new features have manually been merged in? And that for every release of master a manual release of the ''maildir'' branch has to be made? Additionally, I consider this a very basic feature. What happens, if there is another basic feature that is maintained in _another_ branch? How will I ever be able to use them together? You know, I''m just wondering why this feature isn''t merged in upstream. Are there any reasons why anyone would _not_ want proper maildir handling? Or is this just a political decision (scared, since I''ve seen a few of those pull down cool projects :/)? Anyway, thanks for your fast reply! dtk ---------- [0]http://en.wikipedia.org/wiki/Maildir#Technical_operation
Hi Ruthard, thanks for your explanation! Excerpts from Ruthard Baudach''s message of Mon Apr 11 15:05:09 +0200 2011:> Thou shalt not have another e-mail client beside of sup -- because sup > does not change the e-mail sources, and if other mail clients change > sources, sup won''t be able to find the emails any longer.hmm, that feels like a rather basic ability of a MUA. Or am I mistaken? :/> There are some workarounds for this, I installed sup on a PC I can > access via dyndns, run sup there and log in with ssh to read my mail > from different locations.yeah, obviously many people use mutt that way, running in a screen. But that really ruins the whole offline reading thingy for me... ;P> William Morgan is working on a server - client based solution that will > solve this problem, but I don''t dare to try it yet - being not work in > progress, but yet in development.k, I have to admit that I don''t quite get yet why we need a distributed architecture to properly flag our mails (ok, maybe solving that problem is just a byproduct), but it sure sounds nice. Thunderbird, Claws, mutt et al make do without tough, me thinks :| I am just wondering if merging aforementioned branch into master wouldn''t make for a proper, fast and low-effort solution till the server-client refactoring has been put together and been thorougly tested? Or am I missing something? Thanks for your help! dtk
Hi, Excerpts from dtk''s message of lun. avril 11 23:44:51 +0200 2011:> why is that? I thought the way a MUA is supposed to work with a maildir is > rather straight forward[0]?Well, yeah, but not sup. :)> Thanks for the hint!! > I am a bit suspicious, though :| I don''t know much about git, but doesn''t that > essentially mean that the branch is always stuck behind the features in master > until the new features have manually been merged in? > And that for every release of master a manual release of the ''maildir'' branch > has to be made?I keep the maildir-sync branch up to date. If you want the latest version of sup and the maildir synchronization support then use the branch maildir-sync-next from my repository.> Additionally, I consider this a very basic feature. What happens, if there is > another basic feature that is maintained in _another_ branch? How will I ever be > able to use them together?Other features usually get merged faster.> You know, I''m just wondering why this feature isn''t merged in upstream. Are > there any reasons why anyone would _not_ want proper maildir handling? Or is this > just a political decision (scared, since I''ve seen a few of those pull down cool > projects :/)?I think it will be merged for the next version although I didn''t have any confirmation from William yet. I don''t see any reason why that wouldn''t be the case, as you said there are a lot of people interested in this feature. The reason why it is not merged yet is that the code has been finished a few weeks ago and needs some more testing (even if I''ve been using it for 9 months without trouble as well as other people from this list). -- Damien Leone <damien.leone at fensalir.fr> GPG: 0x82EB4DDF
Hi Damien, thanks for your patient reply! Excerpts from Damien Leone''s message of Tue Apr 12 09:34:45 +0200 2011:> Excerpts from dtk''s message of lun. avril 11 23:44:51 +0200 2011: > > why is that? I thought the way a MUA is supposed to work with a maildir is > > rather straight forward[0]? > > Well, yeah, but not sup. :)yeah, I did already recognize. not impressed :|> > You know, I''m just wondering why this feature isn''t merged in upstream. Are > > there any reasons why anyone would _not_ want proper maildir handling? Or is this > > just a political decision (scared, since I''ve seen a few of those pull down cool > > projects :/)? > > I think it will be merged for the next version although I didn''t have > any confirmation from William yet. I don''t see any reason why that > wouldn''t be the case, as you said there are a lot of people interested > in this feature. > > The reason why it is not merged yet is that the code has been finished > a few weeks ago and needs some more testing (even if I''ve been using > it for 9 months without trouble as well as other people from this > list).actually, this soothes my concerns quite a bit. Although I still wonder a bit why this feature hasn''t been built in right from the beginning, not being merged upstream due to being brand new is about the best explanation I can imagine. Well, I guess I''ll just check out your branch these days and hold my breath that it makes it into the next release ;) Thanks again dtk
On Tue, Apr 12, 2011 at 10:41 PM, dtk <d.t.k at gmx.de> wrote:> Although I still wonder a bit > why this feature hasn''t been built in right from the beginningMy two cents, which are only worth one : The syncing model (often used through IMAP) is based on an old file-centric idea : POP is a sum of all your mails, IMAP is a folder for each of your "group" of mail. But this approach allows one mail to be only in one folder, or at least that''s the way it was thought in the beginning. Yet, Sup approach, which is just like GMail, is mail-centric : a single mail can be in different folders. But instead of copying it in different folders, you can do much better: this single mail can be tagged as being part of different "groups"; theses groups are differentiated by labels. This way you can make it be in different "groups" much more easily than with older systems. Heliotrope''s (Sup next iteration) README :> Heliotrope provides all the features you actually want in a modern email > client: > > - fast, full-text search over all messages > - automatic threading > - arbitrary labels > - a sophisticated query language > - support for signed and encrypted email > - an extensible JSON-over-HTTP APISo, to sum up, with sup, one mail has multiple labels, and with Maildir/mbox, one folder( ~ one label) has multiple mails. So, when you apply labels to mails with sup, you have to copy them to all the folders in the maildir format. But you also have to check for all the folders where the mail could be, ... which is not so trivial. Even though, I totally agree with you : I''d love to see my mails being synced back. Not proposing it in the main branch makes it a little bit closed. But I have no excuse to complain, because I''m not contributing. So, I''m just waiting patiently (and use GMail) =] Waiting on the heliotrop/turnsole projects ! -- Matthieu RAKOTOJAONA
Excerpts from Matthieu Rakotojaona''s message of Tue Apr 12 23:43:10 +0200 2011:> On Tue, Apr 12, 2011 at 10:41 PM, dtk <d.t.k at gmx.de> wrote: > > Although I still wonder a bit > > why this feature hasn''t been built in right from the beginning > My two cents, which are only worth one :Au contraire! I highly appreciate your thoughts and opinion!> So, to sum up, with sup, one mail has multiple labels, and with > Maildir/mbox, one folder( ~ one label) has multiple mails. > > So, when you apply labels to mails with sup, you have to copy them to > all the folders in the maildir format. But you also have to check for > all the folders where the mail could be, ... which is not so trivial.I have to admit I wasn''t very precise when asking for ''proper'' maildir handling. In fact, I didn''t intent to ask for a solution that maps the complete label concept (which as you stated is way more powerful) onto the old-fashioned directory based approach. What I rather had in mind was a subset like the exception that is made for sent mail for the other standard directories. Sent mail is already being copied into a specified source to be kind of backwards compatible with the classical maildir structure. And I would feel it to be a natural extension to do so for spam, deleted, read mail as well.> Waiting on the heliotrop/turnsole projects !Thanks for the hint. Since two very well respected colleagues of mine are using ''not much'' right now, you might want to add that one to your list in case you don''t mind using emacs. l8r dtk