From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 10.52.187.5 with SMTP id fo5cs228660vdc; Wed, 11 May 2011 06:37:55 -0700 (PDT) Received: by 10.224.179.203 with SMTP id br11mr7832102qab.197.1305121075276; Wed, 11 May 2011 06:37:55 -0700 (PDT) Return-Path: Received: from rubyforge.org (rubyforge.org [205.234.109.19]) by mx.google.com with ESMTP id p6si262576qcu.135.2011.05.11.06.37.54; Wed, 11 May 2011 06:37:55 -0700 (PDT) Received-SPF: pass (google.com: domain of sup-talk-bounces@rubyforge.org designates 205.234.109.19 as permitted sender) client-ip=205.234.109.19; Authentication-Results: mx.google.com; spf=pass (google.com: domain of sup-talk-bounces@rubyforge.org designates 205.234.109.19 as permitted sender) smtp.mail=sup-talk-bounces@rubyforge.org; dkim=neutral (body hash did not verify) header.i=@googlemail.com Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id D0FAB15B8029; Wed, 11 May 2011 09:37:54 -0400 (EDT) Received: from mail-wy0-f178.google.com (mail-wy0-f178.google.com [74.125.82.178]) by rubyforge.org (Postfix) with ESMTP id 7B580185838E for ; Wed, 11 May 2011 09:19:55 -0400 (EDT) Received: by wyb33 with SMTP id 33so465100wyb.23 for ; Wed, 11 May 2011 06:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:subject:from:to:in-reply-to:references:date :message-id:user-agent:content-transfer-encoding:mime-version :content-type; bh=vEg8BQ/Q5kD0+PPJUW+S/fTxH6E/OhgT70WeiOBgTqU=; b=LJ4j8fyajoTCNKmpR7LJ6YpuJtQ5/0uXJdyZYMCVj5Vq9cgOOU87acxfAFvYh8USqU UbtIuEvmpEgymODiHFY2U7YMDDRzO3FMJJTnbEUXDv/9wyme+81Ubt179iJwUZVOCy8s 3qjCViscnsuprMygYurx81/0n44NrJxeISUaU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:to:in-reply-to:references:date:message-id:user-agent :content-transfer-encoding:mime-version:content-type; b=pAyAgKKEjlUYg75T7jD7yZAoINzJdDAnqRg06p16ZQAn1M+auyiREajV6bfVXd+GQ2 er6O4Chm9yLnjyQGc9NxlEsvUIhwvnwcBE4U+BJi5CwgRkEPdzaZAB9272965k9kuThX pHfz74CF90qOP26JoR7LLdz4egkfY/TjTEx8Y= Received: by 10.227.167.129 with SMTP id q1mr9639374wby.101.1305119994762; Wed, 11 May 2011 06:19:54 -0700 (PDT) Received: from localhost (dhcp-90-080.inf.ed.ac.uk [129.215.90.80]) by mx.google.com with ESMTPS id z9sm99002wbx.17.2011.05.11.06.19.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2011 06:19:53 -0700 (PDT) From: Patrick Totzke To: sup-talk In-reply-to: <1305115211-sup-2468@PrxServer3> References: <1305058093-sup-1016@minibox> <1305115211-sup-2468@PrxServer3> Date: Wed, 11 May 2011 14:20:04 +0100 Message-Id: <1305118404-sup-8314@optimusprime> User-Agent: Sup/git MIME-Version: 1.0 Subject: Re: [sup-talk] multiple accounts X-BeenThere: sup-talk@rubyforge.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: User & developer discussion of Sup List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0752655631==" Sender: sup-talk-bounces@rubyforge.org Errors-To: sup-talk-bounces@rubyforge.org --===============0752655631== Content-Transfer-Encoding: 8bit Content-Type: multipart/signed; boundary="=-1305120004-191724-2540-9516-1-="; protocol="application/pgp-signature" --=-1305120004-191724-2540-9516-1-= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Excerpts from Ruthard Baudach's message of Wed May 11 13:10:25 +0100 2011= : > > =3D=3D=3D dtk schrieb am 2011-05-10 22:17: =3D=3D=3D < > > Hey folks, > > = > > I've been test driving sup with my main mail account for some weeks n= ow, 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 o= ther > > accounts in sup now as well. > > = > > I do have a problem, though, since I can't seem to find a way to defi= ne seperate > > :sent_sources per account. And I really don't want to get private/wor= k 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 b= e 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 creatio= n > 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 --=-1305120004-191724-2540-9516-1-= Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3KjQQACgkQlDQDZ9fWxar+XACdGKO5VGnMoUfH7osFbpcqF4k/ naEAn0ICcRZQcYf8imBkFym+6aArmz0/ =jpzE -----END PGP SIGNATURE----- --=-1305120004-191724-2540-9516-1-=-- --===============0752655631== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk --===============0752655631==--