Hi All. Does anyone know of a way to background or perhaps queue sending mail. Sup has me so efficient I''ve even lost the patience to wait for msgs to be sent. I really want to hit ''y'' and move on. Any thoughts, experiences? My first though was manipulating the buffers so that the previous buffer would get called back before the mail gets confirmed as sent and then the confirmation itself could still be displayed in the notification area. -- Thanks, Phil
Le 17/03/2011 ? 15:17, Philippe LeCavalier a ?crit:> Hi All. > > Does anyone know of a way to background or perhaps queue > sending mail. Sup has me so efficient I''ve even lost the patience to > wait for msgs to be sent. I really want to hit ''y'' and move on. > > Any thoughts, experiences? My first though was manipulating the buffers > so that the previous buffer would get called back before the mail gets > confirmed as sent and then the confirmation itself could still be > displayed in the notification area.Try with a real mta like postfix or exim. There are simple to use/configure. Personnaly, i''ve a little preference in exim. -- Bruno d''Arcangeli
Hi Bruno. Excerpts from Bruno d''Arcangeli''s message of Thu Mar 17 11:32:12 -0400 2011:> Le 17/03/2011 ? 15:17, Philippe LeCavalier a ?crit: > > Hi All. > > > > Does anyone know of a way to background or perhaps queue > > sending mail. Sup has me so efficient I''ve even lost the patience to > > wait for msgs to be sent. I really want to hit ''y'' and move on. > > > > Any thoughts, experiences? My first though was manipulating the buffers > > so that the previous buffer would get called back before the mail gets > > confirmed as sent and then the confirmation itself could still be > > displayed in the notification area. > > Try with a real mta like postfix or exim. There are simple to use/configure. > Personnaly, i''ve a little preference in exim. >I''ve used both and can''t really say I prefer one over the other but I''m not certain I understand how that would help me background or queue sending mail in sup. Like right now, after I press ''y'', I want sup to _immediately_ bring me to either my inbox-mode or this thread in thread-mode. Either buffer would be fine with me though I suspect for continuity proposes return to the thread might be more logical. I just don''t want to wait for the ''Message Sent!''. Even if Exim or Postfix might act faster than msmtp(what I''m using now) sup is set up in a way that it waits for the process to terminate before bringing me to the previous buffer. What I''d like to suggest is that sup should immediately bring you to the previous buffer. -- Thanks, Phil
Philippe LeCavalier, 2011-03-17 16:17:> Sup has me so efficient I''ve even lost the patience to > wait for msgs to be sent.You need to wait? I don''t. Sup is instatly back after hitting ''y''. Your MTA must be somehow broken. -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
Excerpts from Philippe LeCavalier''s message of Thu Mar 17 15:15:30 -0400 2011: Hi Philippe,> Even if Exim or Postfix might act faster than msmtp(what I''m using > now) sup is set up in a way that it waits for the process to > terminate before bringing me to the previous buffer. What I''d like > to suggest is that sup should immediately bring you to the previous > buffer.I get a near instant return to the buffer when submitting via ''sendmail'' (exim in my case). It''s only takes the time required to spit the content of the mail through the pipe to that process...once done, the delivery is asyncrhonous to sup. If it''s not behaving that way when using a real mta, something with the mta config is borked.[1] Thanks -Ben [1] By default sendmail used to try immediate handoff before queuing, which could result in delayed return. I''m not sure if it still does though. -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302
Hi Tero. Excerpts from Tero Tilus''s message of Thu Mar 17 15:54:59 -0400 2011:> Philippe LeCavalier, 2011-03-17 16:17: > > Sup has me so efficient I''ve even lost the patience to > > wait for msgs to be sent. > > You need to wait? I don''t. Sup is instatly back after hitting ''y''. > Your MTA must be somehow broken.That''s because of your connection speed. Like right now I''m at a client that''s got me connected to a 10Mbps fibre link so it feels ''instant''. But some client have slower DSL links and when I''m at home -I''m in the country- I''ve got a 1.5Mps wireless and Sup makes me wait 5 to 10 seconds while msmtp terminates. That pause drives me nuts. I want sup to leave that buffer in the background. Like what about someone on dial-up or a very slow DSL. It must be even longer. -- Thanks, Phil
Excerpts from Philippe LeCavalier''s message of Thu Mar 17 15:15:30 -0400 2011:> Even if Exim or Postfix might act faster than msmtp(what I''m using now) > sup is set up in a way that it waits for the process to terminate before > bringing me to the previous buffer. What I''d like to suggest is that sup > should immediately bring you to the previous buffer.Exim or Postfix will both act as the local message queue for you, unlike msmtp which blocks while it talks to the upstream remote mail server. It''s not so much Sup''s blocking as msmtp''s blocking here which is the problem, IME -- talking to the local MTA is wicked fast, and you can set your local MTA to use your upstream remote mail server as its smarthost -- and there''s no reason to add a message queue to Sup if your MTA can handle it. Given Exim''s recent security troubles I''d recommend Postfix. - Kevin -- Kevin Riggle (kevinr at free-dissociation.com) http://free-dissociation.com
Excerpts from Philippe LeCavalier''s message of Thu Mar 17 21:10:36 +0100 2011:> But some client have slower DSL links and when I''m at home -I''m in the > country- I''ve got a 1.5Mps wireless and Sup makes me wait 5 to 10 > seconds while msmtp terminates. That pause drives me nuts. I want sup to > leave that buffer in the background. Like what about someone on dial-up > or a very slow DSL. It must be even longer.Give nullmailer a try. It will queue your message and deliver it in the background. No need to hack sup and keep it running until the message has been delivered. On my laptops I''ve integrated nullmailer with NetworkManager so I can write mails while on the bus and have them delivered as soon as I enter the reach of a wifi network that I have access to. A custom ssh based transport tunnels the mails to my smarthost (the university network blocks the SMTP ports). Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 500 bytes Desc: not available URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20110317/2b52e4ea/attachment.bin>
On Thu, Mar 17, 2011 at 7:17 AM, Philippe LeCavalier <support at plecavalier.com> wrote:> > Hi All. > > Does anyone know of a way to background or perhaps queue > sending mail. Sup has me so efficient I''ve even lost the patience to > wait for msgs to be sent. I really want to hit ''y'' and move on. > > Any thoughts, experiences? My first though was manipulating the buffers > so that the previous buffer would get called back before the mail gets > confirmed as sent and then the confirmation itself could still be > displayed in the notification area.It sounds like you''re refering to how msmtp blocks while talking to your smtp server. As others have mentioned exim or postfix will do the job. My preference is postifx. If you are already using msmtp, perhaps the msmtpq script would be preferable for you, there''s a readme that details usage: http://msmtp.git.sourceforge.net/git/gitweb.cgi?p=msmtp/msmtp;a=tree;f=scripts/msmtpq;h=edde598fe8394b371a8c67a0dc910423ae88904b;hb=HEAD
Excerpts from Sascha Silbe''s message of Thu Mar 17 18:32:19 -0400 2011:> Excerpts from Philippe LeCavalier''s message of Thu Mar 17 21:10:36 +0100 2011: > > > But some client have slower DSL links and when I''m at home -I''m in the > > country- I''ve got a 1.5Mps wireless and Sup makes me wait 5 to 10 > > seconds while msmtp terminates. That pause drives me nuts. I want sup to > > leave that buffer in the background. Like what about someone on dial-up > > or a very slow DSL. It must be even longer. > > Give nullmailer a try. It will queue your message and deliver it in the > background. No need to hack sup and keep it running until the message > has been delivered. > > On my laptops I''ve integrated nullmailer with NetworkManager so I can > write mails while on the bus and have them delivered as soon as I enter > the reach of a wifi network that I have access to. A custom ssh based > transport tunnels the mails to my smarthost (the university network > blocks the SMTP ports). > > Sascha >That sounds just about perfect. These kinds of conversations always leave me wondering why I haven''t heard of said program before, in this case it''s nullmailer. I guess I should just be happy I''m learning something new every day! Thanks Sascha! -- Thanks, Phil
Excerpts from Kevin Riggle''s message of Thu Mar 17 16:16:09 -0400 2011:> Excerpts from Philippe LeCavalier''s message of Thu Mar 17 15:15:30 -0400 2011: > > Even if Exim or Postfix might act faster than msmtp(what I''m using now) > > sup is set up in a way that it waits for the process to terminate before > > bringing me to the previous buffer. What I''d like to suggest is that sup > > should immediately bring you to the previous buffer. > > Exim or Postfix will both act as the local message queue for you, unlike > msmtp which blocks while it talks to the upstream remote mail server. > It''s not so much Sup''s blocking as msmtp''s blocking here which is the > problem, IME -- talking to the local MTA is wicked fast, and you can set > your local MTA to use your upstream remote mail server as its smarthost > -- and there''s no reason to add a message queue to Sup if your MTA can > handle it. > > Given Exim''s recent security troubles I''d recommend Postfix. > > - Kevin > -- > Kevin Riggle (kevinr at free-dissociation.com) > http://free-dissociation.com > _______________________________________________ > sup-talk mailing list > sup-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/sup-talk >Thanks Kevin. I get what everyone is saying now. I just needed explained as you did. Makes total sense to me now. I''m going to give preference to Sascha''s suggestion first. But if I''m unsuccessful I''ll definitely give a local -full- MTA a try. -- Thanks, Phil
Philippe LeCavalier, 2011-03-17 22:10:> > You need to wait? I don''t. Sup is instatly back after hitting ''y''. > That''s because of your connection speed.Are you kidding? I''ve sent mail using sup when hanging on GPRS (roughly 30 kbps and 1500ms ping lag) in a train moving 200 km/h. Instant send. If it was about uplink speed I definitely would have experienced it then. -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
Excerpts from Tero Tilus''s message of Thu Mar 17 20:53:46 -0400 2011:> Philippe LeCavalier, 2011-03-17 22:10: > > > You need to wait? I don''t. Sup is instatly back after hitting ''y''. > > That''s because of your connection speed. > > Are you kidding?No I wasn''t.>I''ve sent mail using sup when hanging on GPRS (roughly 30 kbps and >1500ms ping lag) in a train moving 200 km/h. Instant send. If it was >about uplink speed I definitely would have experienced it then.I agree. I understand now that it was, as explained, msmtp waiting for the remote smtp session to finish. Whcih, whether I knew that or not wasn''t really my point. I just wanted to throw the process of msmtp blocking while talking to the relay in the background. But I see know that using the local MTA would be just as ''instant'' as putting the buffer in the background. Or perhaps should I say making that need obsolete... -- Thanks, Phil
Excerpts from Philippe LeCavalier''s message of Thu Mar 17 19:08:41 -0400 2011:> Excerpts from Sascha Silbe''s message of Thu Mar 17 18:32:19 -0400 2011: > > Excerpts from Philippe LeCavalier''s message of Thu Mar 17 21:10:36 +0100 2011: > > > > > But some client have slower DSL links and when I''m at home -I''m in the > > > country- I''ve got a 1.5Mps wireless and Sup makes me wait 5 to 10 > > > seconds while msmtp terminates. That pause drives me nuts. I want sup to > > > leave that buffer in the background. Like what about someone on dial-up > > > or a very slow DSL. It must be even longer. > > > > Give nullmailer a try. It will queue your message and deliver it in the > > background. No need to hack sup and keep it running until the message > > has been delivered. > > > > On my laptops I''ve integrated nullmailer with NetworkManager so I can > > write mails while on the bus and have them delivered as soon as I enter > > the reach of a wifi network that I have access to. A custom ssh based > > transport tunnels the mails to my smarthost (the university network > > blocks the SMTP ports). > > > > Sascha > > > That sounds just about perfect. These kinds of conversations always > leave me wondering why I haven''t heard of said program before, in this > case it''s nullmailer. I guess I should just be happy I''m learning > something new every day! Thanks Sascha!Sascha, would you be so kind as to post(or send me) your remotes file if you use TLS? I can seem to get nullmailer working with my host. It''s timing out on the cert check since it''s not a valid cert. In msmtp I used to use: tls on tls_certcheck off tls_starttls off But I can''t seem to find anything related to that for nullmailer. -- Thanks, Phil