Excerpts from Ruthard Baudach's message of Wed May 11 13:10:25 +0100 2011: > > === dtk schrieb am 2011-05-10 22:17: === < > > Hey folks, > > > > I've been test driving sup with my main mail account for some weeks now, and > > have to admit that my other accounts didn't get too much love during that time, > > due to the clunky handling of thunderbird. So I'd like to manage my other > > accounts in sup now as well. > > > > I do have a problem, though, since I can't seem to find a way to define seperate > > :sent_sources per account. And I really don't want to get private/work mails to > > get mixed up :| > > > > Is there a way to define :sent_source: entries per account? > > This sounds sort of "unsupish". The main idea of sup is to separate > the physical storage of emails (maildirs, imap folders, mbox and so on) > from the logical structure needed to archive (and access) the emails. > > Sup organizes emails by indexing them and searching the index, so it's > completely unimportant where the emails are stored. An email labeled > "inbox" will be shown in the inbox regardless where it is stored, and > the same is true for emails labeled "draft" or "sent". > > This means, that, according to sup's philosophy, if you want to > differentiate between private and business mail, you would tag the > threads the mail belongs to with the label "private" resp. "business" > (or even both). I know thats the idea, but it only makes sense if you use sup for nothing else than reading your mail: Call me old-fashioned, but for me it is an integral part of the MUA to be able to manipulate mail. I want to use it as a frontend for all my (local) mail-organization: it should let me read, delete and respond to mails and handle crypto transparently. Hence, I consider it the responsibility of the mua to _physically_ manipulate mboxes and maildirs and storing my outgoing mail should also be done by the mua, not my transport agent. > Actually, the mere existence of an :sent_source: is astonishing, as sup > could store sent messages anywhere, it would not matter to the sup user. I guess every user would want to store outgoing mail _somewhere_? The question is where? letting the user choose this in the settings is a good idea, almost certainly better than hardcoding this to be sup:/sent (or sup:/drafts for that matter *cough* ). But of course, his choice may depend on the message in some way, most likely on the From: field. How about a hook "choose-sent-sink" that takes a msg and decides which source to store it in? > This separation of physical storage and logical structure is ingenial, > and the reason why sup is so good organizing emails. > The downside is, that it's almost impossible to use other email clients > beside of sup. The point is that using this "pure" approach - sup does no physical manipulation whatsoever - lets you no choice as to use other tools to physically organize your mail, obviously cousing inconsistancies in the index. > OK, this is not really helpfull, but might help to understand, why sup > does not do things which seem to be natural for a MUA - like deleting > or copying emails or storing sent emails in different sources. > It's just not necessary. disagree: much discussed use-case: my personal outmails should not be stored on the company mailserver, nor the other way around. > One idea, that might help: there is an "sendmail" hook and an > "before-edit" hook. "before-edit" might be used to automize the creation > of a bcc to oneself, Bcc to oneself is discussed below, is definately a workaround for mua shortcomings. > and the sendmail hook could probably be used > intercept the message and store it in an additional sent-source before > calling the actual sendmail command. But I'm affraid my Ruby is not > good enough to do that. Unfortunately, I too feel uncomfortable with ruby, otherwise I would definately give more constructive feedback instead of just complaining here 8) Cheers, /p
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk