Subject: Re: [sup-talk] multiple accounts

From: Wirt Wolff <[email-masked]>
Date: Tue, 10 May 2011 15:36:25 -0600

Excerpts from dtk's message of Tue May 10 14:17:00 -0600 2011:
> 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?

Is this what you mean?

http://sup.rubyforge.org/wiki/wiki.pl?MultipleAccountsAndReply

i.e. get a mail to [email-masked] replies from a private acct and mails
to [email-masked] replies are from [email-masked]?

--
wmw
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: dtk <[email-masked]>
Date: Wed, 11 May 2011 17:08:48 +0200

Excerpts from d.t.k's message of Mi Mai 11 12:41:14 +0200 2011:
> Excerpts from Patrick Totzke's message of Mi Mai 11 11:41:44 +0200 2011:
> > I agree: a single send-sink seems totally unnatural.
> > In fact, we have the same problem with drafts.
> yeah, actually I can think of some more situations in which I would wish for
> account specific sources: I'd love to add a :spam_source (e.g. 'Junk') and a :ham_source (e.g. INBOX) where mails
> are moved when the 'spam' label is set/removed, so that operation is mapped onto
> folders (I use a server side spamassassin to automagically learn from specified
> folders)
>
> > I recently mentioned both shortcomings on sup-devel
> > (http://rubyforge.org/pipermail/sup-devel/2011-May/001095.html).
> > As you say: a quick glance at the code confirms that one can only
> > specify one send-sink, as well as draft-sink.
> > However, there is some sort of "DraftManager" object. I guess one can
> > play with that..
> actually, as a dirty hack it shouldn't be too hard to do: message objects know
> about their sources. Now we could reference the account a source belongs to in
> every source in addition to fields like labels, usual, archived, etc. Et voila.
> From the related account we could then get any required sink: draft, sent, spam,
> ham, ...
uah, what was I thinking? Actually, for the first two cases (draft, sent), it
should be /way/ easier. There already /is/ a mechanism for correllating those
messages to an account. I think it is acceptable to assume that sent mails as
well as drafts have the from: header (which is most probably where the acct
correllation hooks in) set (this may not be true for the spam/ham scenario). So
since there is a mechanism to get the account to such a mail, all we would need
to do is to provide account objects with a :sent_source and a :draft_source of
type location. Case solved.

Now that's gonna be easy ;)
dtk

PS depending on the direction this discussion is taking, I wonder whether I
should subscribe to and include sup-devel :|
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: dtk <[email-masked]>
Date: Wed, 11 May 2011 15:50:02 +0200

Excerpts from Ruthard Baudach's message of Mi Mai 11 14:10:25 +0200 2011:
> > === dtk schrieb am 2011-05-10 22:17: === <
> > Hey folks,
> >
> This sounds sort of "unsupish".
I know what you mean. It deals with folders, and sup doesn't. And still I tend
to regard that kind of behavior rather as an extension, an improvement than a
contradiction. Here's why:

> The main idea of sup is to separate
> the physical storage of emails [...]
> from the logical structure needed to archive (and access) the emails.
>
> This separation of physical storage and logical structure is [...] the reason
> why sup is so good organizing emails.
true

> The downside is, that it's almost impossible to use other email clients
> beside of sup.
false. As you say

> Sup organizes emails by indexing them and searching the index, so it's
> completely unimportant where the emails are stored.
So why not store it in a folder that makes it compatible with all those plain
old MUAs (like that webmail client I need when not at my machine or that stupid
GUI MUA my boss forces me to use so he can send me exchange invites)?

> Actually, the mere existence of an :sent_source: is astonishing
I wouldn't call it so much 'astonishing' but rather a well founded compromise,
since first it makes sup compatible with plain old MUAs and second
> sup could store sent messages anywhere, it would not matter to the sup user.

> 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
it doesn't!? o_O
I've been using Damien's branch[0] for basically what is the entire time I'm
using sup and it plays really, really nice with all my other MUAs without losing
/any/ of the great innovative advantages of a plain sup, at least as far as I
can tell. So I really fail to see how that would be considered a bad thing ;)

> It's just not necessary.
As you can probably see from my argumentation so far, I'd beg to differ ;P

> 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, 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.
yeah, thx for the hints!! Bs as I already stated, not only do I consider that a
rather hacky work around, but I also have other applications in mind plus I would
prefer to just do it the right way^TM ;)

Thanks for your clarifications
dtk

----------
[0]http://rubyforge.org/pipermail/sup-devel/2010-July/000631.html
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: dtk <[email-masked]>
Date: Tue, 10 May 2011 22:17:00 +0200

Hey folks,

tia
dtk

---

From: Patrick Totzke <[email-masked]>
Date: Wed, 11 May 2011 10:41:44 +0100

Hiya!
I agree: a single send-sink seems totally unnatural.
In fact, we have the same problem with drafts. Has anyone of you managed
to store drafts anywhere else than in ~/.sup/drafts ? let alone
in different locations for different accounts?
I recently mentioned both shortcomings on sup-devel
(http://rubyforge.org/pipermail/sup-devel/2011-May/001095.html).
As you say: a quick glance at the code confirms that one can only
specify one send-sink, as well as draft-sink.
However, there is some sort of "DraftManager" object. I guess one can
play with that..

Anyhow, my current solution is to use a local mbox as send-sink 
and use a bcc to myself. Then I use server-side filters to
mark incoming mails from myself as read and move it to sent.
offlineimap then syncs the sent folder, which is then included in
sources.yaml with archived:true and autoadd label:sent.

The problem with this is, that despite different sup's on different
hosts both can read the send mails wich are stored on the correct
servers, the sup-instance that was used to compose the mail actually
displays its local version and somehow skips the one from the server.
BUT: I cannot prevent my mailhost from adding another signature to the
mail and therefore, the mail sup stores is different from the one I
sent! To conclude: different send-sinks for different accounts are
the sensible solution in my view.
cheers'
/p

Excerpts from dtk's message of Wed May 11 01:16:03 +0100 2011:
> Excerpts from Matthieu Rakotojaona's message of Mi Mai 11 01:23:02 +0200 2011:
> > I know that when you send an email from Google smtp, you don't have to save
> > it anywhere. It will automagically be saved with a GMail/Send tag (most of
> > the time 'Send' only'). You don't configure your GMail account to save
> > anything in msmtp; it happens on Google side.
> > Isn't there a way to do so with msmtp ? I know you can choose an account to
> > send from, but after a quick looking you can't choose a folder where to save
> > the sent email. Maybe you'd have to choose another MTA to save the sending
> > mail ? Simple relays like msmtp or nbsmtp (in the example) can't save in a
> > specific folder.
> hmm, actually I don't think it's usually an smtp feature but rather an IMAP one?
> 
> > sup is just like mutt, an MUA, and HAPPENS to be able to
> > save your sent mail to a specific folder. But I think it's not the main
> > purpose of it, or am I wrong ?
> well, as an MUA I feel it is its task to manage mails, and that certainly
> includes accessing my mailbox. Admittedly stressing the comparison, speaking
> proper maildir e.g. means moving mails from new/ to cur/, so I feel like copying
> sent mails into a destined directory sounds rather appropriate, as does deleting
> mails, etc...
> 
> Besides, sup /does/ it, so why not do it properly? Making the sent source
> account dependent feels natural to me. And I don't see why I would need a more
> complex MTA for that (which according to my understanding is responsible for
> transferring mails between systems rather than shuffling around mails locally).
> 
> ready to be educated
> dtk ;)

---

From: Ruthard Baudach <[email-masked]>
Date: Wed, 11 May 2011 14:10:25 +0200

> 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).

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.

This separation of physical storage and logical structure is ingenial,
and the reason why sup is so good organizing emails.

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.

calling the actual sendmail command. But I'm affraid my Ruby is not
good enough to do that.

Ruthard Baudach

---

From: Matthieu Rakotojaona <[email-masked]>
Date: Wed, 11 May 2011 01:23:02 +0200

On Wed, May 11, 2011 at 12:52 AM, dtk <[email-masked]> wrote:

> Excerpts from Wirt Wolff's message of Di Mai 10 23:36:25 +0200 2011:
> not exactly. My local maildir sources are synced back to two different imap
> servers (hosting my two different mail addresses) via offlineimap.
>
> What I want is mails sent via [email-masked] to end up in the
> 'Sent' folder on foozle.com while mails sent via [email-masked] end up in
> the
> 'Sent' folder on private.net.
>
> But so far (at least as far as I can tell) I can specify only /one/ maildir
> as
> /the/ :sent_source, which means copies of sent mails (independent of the
> account
> they were sent over) will end up on /one/ imap server.
>
> hope that made it any clearer? :/
>
> thanks anyway
> dtk

My 2 cents :

specific folder. sup is just like mutt, an MUA, and HAPPENS to be able to

-- 
Matthieu RAKOTOJAONA

---

From: dtk <[email-masked]>
Date: Wed, 11 May 2011 00:52:19 +0200

What I want is mails sent via [email-masked] to end up in the
'Sent' folder on foozle.com while mails sent via [email-masked] end up in the
'Sent' folder on private.net.

But so far (at least as far as I can tell) I can specify only /one/ maildir as
/the/ :sent_source, which means copies of sent mails (independent of the account
they were sent over) will end up on /one/ imap server.

thanks anyway
dtk

---

From: dtk <[email-masked]>
Date: Wed, 11 May 2011 02:16:03 +0200

ready to be educated
dtk ;)

---

From: d.t.k <[email-masked]>
Date: Wed, 11 May 2011 12:41:14 +0200

Hi,

ham, ...

I don't think it's too beautiful if sources know what account they belong to. I
feel like it should rather be the other way around (an acct knows its srcs).
Specifying the sources of an account in the config.yaml might seriously clutter
that file up, though, especially for users with many imap folder. So we could
either reference a file containing the sources for an account in config.yaml
(per account) or name the file by some convention (sources_<account-name>.yaml)
and have it parsed automagically (convention over configuration?).

Thinking about it, if we could correlate mails and accounts (via the source) we
might just store the belonging account in a message field.

> the sensible solution in my view.
I agree. Your solution may provide a work around for now, but it feels rather
hacky. I'd prefer having account specific sources handled properly (as I have
other applications in mind, see above) as much as I imagine you would.

dtk

---

From: Patrick Totzke <[email-masked]>
Date: Wed, 11 May 2011 14:20:04 +0100

> threads the mail belongs to with the label "private" resp. "business"

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.

> 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?

> The downside is, that it's almost impossible to use other email clients
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.

> or copying emails or storing sent emails in different sources.
disagree: much discussed use-case: my personal outmails should not be
stored on the company mailserver, nor the other way around.

> 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
Unfortunately, I too feel uncomfortable with ruby, otherwise I would
definately give more constructive feedback instead of just complaining
here 8) 
Cheers,
/p
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk