From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 10.52.187.5 with SMTP id fo5cs220157vdc; Wed, 11 May 2011 03:14:13 -0700 (PDT) Received: by 10.52.94.239 with SMTP id df15mr921810vdb.254.1305108852789; Wed, 11 May 2011 03:14:12 -0700 (PDT) Return-Path: Received: from rubyforge.org (rubyforge.org [205.234.109.19]) by mx.google.com with ESMTP id r27si6696196vbw.81.2011.05.11.03.14.12; Wed, 11 May 2011 03:14:12 -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 8677715B802D; Wed, 11 May 2011 06:14:12 -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 63FBD15B8029 for ; Wed, 11 May 2011 05:41:48 -0400 (EDT) Received: by wyb33 with SMTP id 33so288436wyb.23 for ; Wed, 11 May 2011 02:41:48 -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=XyUFUcKLijtoXOKDujaTkpvAI9w+XkmZPraqtcunDec=; b=aYtcjI+9laqcivuDD8ywNxl/fk8GmAfpEjX/1IPBcjmSfYNvbAqDoRFo77tnuyWhdE QLdlrPZrpjcytLegHFOnrvk+UyMjxkout37Cwx85hgLiIaM9TyN0iE+8F7cXIvO5H+ET XQF1pXznNbXkZqaMT4to5ufwNA+Yumep2C6+s= 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=PVlnORhtrgK9Y7fGPWvsWSgm+j31kdFo/P73bA6E4b459F3GCqZF8jnsWa+gvUtTew H+yRJ13N9CeA9kf/JBmqHSIkz/m0D/NS9XfFyvuomBqLLGYS136gOu9Z+Rj/+3qBvTkC 6KD0Mzw5wGlMYY+WdmzopJSPsi11wb7WjLyKM= Received: by 10.227.128.138 with SMTP id k10mr9320600wbs.82.1305106908345; Wed, 11 May 2011 02:41:48 -0700 (PDT) Received: from localhost (cpc1-sgyl2-0-0-cust47.sgyl.cable.virginmedia.com [80.192.18.48]) by mx.google.com with ESMTPS id bd8sm4909347wbb.48.2011.05.11.02.41.46 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2011 02:41:47 -0700 (PDT) From: Patrick Totzke To: sup-talk In-reply-to: <1305072191-sup-3288@minibox> References: <1305058093-sup-1016@minibox> <1305063169-sup-9131@chigamba> <1305067227-sup-4227@minibox> <1305072191-sup-3288@minibox> Date: Wed, 11 May 2011 10:41:44 +0100 Message-Id: <1305105912-sup-2960@brick> 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="===============1296684825==" Sender: sup-talk-bounces@rubyforge.org Errors-To: sup-talk-bounces@rubyforge.org --===============1296684825== Content-Transfer-Encoding: 8bit Content-Type: multipart/signed; boundary="=-1305106905-43932-21083-80-4-="; protocol="application/pgp-signature" --=-1305106905-43932-21083-80-4-= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 +020= 0 2011: > > I know that when you send an email from Google smtp, you don't have t= o save > > it anywhere. It will automagically be saved with a GMail/Send tag (mo= st of > > the time 'Send' only'). You don't configure your GMail account to sav= e > > anything in msmtp; it happens on Google side. > > Isn't there a way to do so with msmtp ? I know you can choose an acco= unt 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 se= nding > > 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 ma= in > > purpose of it, or am I wrong ? > well, as an MUA I feel it is its task to manage mails, and that certain= ly > includes accessing my mailbox. Admittedly stressing the comparison, spe= aking > proper maildir e.g. means moving mails from new/ to cur/, so I feel lik= e 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 sour= ce > 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 responsibl= e for > transferring mails between systems rather than shuffling around mails l= ocally). > = > ready to be educated > dtk ;) --=-1305106905-43932-21083-80-4-= Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3KWdgACgkQlDQDZ9fWxaqJtACfYgMNziCQ+O85uEt4fJZYdBFE sA8AoJXSZ3/mbVWCXeBu4jf3D0k5XEDD =k4PX -----END PGP SIGNATURE----- --=-1305106905-43932-21083-80-4-=-- --===============1296684825== 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 --===============1296684825==--