* [sup-talk] background or queue msg sending
@ 2011-03-17 14:17 Philippe LeCavalier
2011-03-17 15:32 ` Bruno d'Arcangeli
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Philippe LeCavalier @ 2011-03-17 14:17 UTC (permalink / raw)
To: sup-talk
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
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [sup-talk] background or queue msg sending
2011-03-17 14:17 [sup-talk] background or queue msg sending Philippe LeCavalier
@ 2011-03-17 15:32 ` Bruno d'Arcangeli
2011-03-17 19:15 ` Philippe LeCavalier
2011-03-17 19:54 ` Tero Tilus
2011-03-17 22:42 ` Sean Escriva
2 siblings, 1 reply; 14+ messages in thread
From: Bruno d'Arcangeli @ 2011-03-17 15:32 UTC (permalink / raw)
To: sup-talk
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
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [sup-talk] background or queue msg sending
2011-03-17 15:32 ` Bruno d'Arcangeli
@ 2011-03-17 19:15 ` Philippe LeCavalier
2011-03-17 19:55 ` Ben Walton
2011-03-17 20:16 ` Kevin Riggle
0 siblings, 2 replies; 14+ messages in thread
From: Philippe LeCavalier @ 2011-03-17 19:15 UTC (permalink / raw)
To: sup-talk
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
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [sup-talk] background or queue msg sending
2011-03-17 14:17 [sup-talk] background or queue msg sending Philippe LeCavalier
2011-03-17 15:32 ` Bruno d'Arcangeli
@ 2011-03-17 19:54 ` Tero Tilus
2011-03-17 20:10 ` Philippe LeCavalier
2011-03-17 22:42 ` Sean Escriva
2 siblings, 1 reply; 14+ messages in thread
From: Tero Tilus @ 2011-03-17 19:54 UTC (permalink / raw)
To: Sup users
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/
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [sup-talk] background or queue msg sending
2011-03-17 19:15 ` Philippe LeCavalier
@ 2011-03-17 19:55 ` Ben Walton
2011-03-17 20:16 ` Kevin Riggle
1 sibling, 0 replies; 14+ messages in thread
From: Ben Walton @ 2011-03-17 19:55 UTC (permalink / raw)
To: sup-talk
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
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [sup-talk] background or queue msg sending
2011-03-17 19:54 ` Tero Tilus
@ 2011-03-17 20:10 ` Philippe LeCavalier
2011-03-17 22:32 ` Sascha Silbe
2011-03-18 0:53 ` Tero Tilus
0 siblings, 2 replies; 14+ messages in thread
From: Philippe LeCavalier @ 2011-03-17 20:10 UTC (permalink / raw)
To: sup-talk
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
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [sup-talk] background or queue msg sending
2011-03-17 19:15 ` Philippe LeCavalier
2011-03-17 19:55 ` Ben Walton
@ 2011-03-17 20:16 ` Kevin Riggle
2011-03-17 23:10 ` Philippe LeCavalier
1 sibling, 1 reply; 14+ messages in thread
From: Kevin Riggle @ 2011-03-17 20:16 UTC (permalink / raw)
To: sup-talk
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@free-dissociation.com)
http://free-dissociation.com
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [sup-talk] background or queue msg sending
2011-03-17 20:10 ` Philippe LeCavalier
@ 2011-03-17 22:32 ` Sascha Silbe
2011-03-17 23:08 ` Philippe LeCavalier
2011-03-18 0:53 ` Tero Tilus
1 sibling, 1 reply; 14+ messages in thread
From: Sascha Silbe @ 2011-03-17 22:32 UTC (permalink / raw)
To: sup-talk
[-- Attachment #1.1: Type: text/plain, Size: 972 bytes --]
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/
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 500 bytes --]
[-- Attachment #2: Type: text/plain, Size: 140 bytes --]
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [sup-talk] background or queue msg sending
2011-03-17 14:17 [sup-talk] background or queue msg sending Philippe LeCavalier
2011-03-17 15:32 ` Bruno d'Arcangeli
2011-03-17 19:54 ` Tero Tilus
@ 2011-03-17 22:42 ` Sean Escriva
2 siblings, 0 replies; 14+ messages in thread
From: Sean Escriva @ 2011-03-17 22:42 UTC (permalink / raw)
To: Philippe LeCavalier; +Cc: sup-talk
On Thu, Mar 17, 2011 at 7:17 AM, Philippe LeCavalier
<support@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
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [sup-talk] background or queue msg sending
2011-03-17 22:32 ` Sascha Silbe
@ 2011-03-17 23:08 ` Philippe LeCavalier
2011-03-18 1:34 ` Philippe LeCavalier
0 siblings, 1 reply; 14+ messages in thread
From: Philippe LeCavalier @ 2011-03-17 23:08 UTC (permalink / raw)
To: sup-talk
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
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [sup-talk] background or queue msg sending
2011-03-17 20:16 ` Kevin Riggle
@ 2011-03-17 23:10 ` Philippe LeCavalier
0 siblings, 0 replies; 14+ messages in thread
From: Philippe LeCavalier @ 2011-03-17 23:10 UTC (permalink / raw)
To: sup-talk
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@free-dissociation.com)
> http://free-dissociation.com
> _______________________________________________
> sup-talk mailing list
> sup-talk@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
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [sup-talk] background or queue msg sending
2011-03-17 20:10 ` Philippe LeCavalier
2011-03-17 22:32 ` Sascha Silbe
@ 2011-03-18 0:53 ` Tero Tilus
2011-03-18 1:31 ` Philippe LeCavalier
1 sibling, 1 reply; 14+ messages in thread
From: Tero Tilus @ 2011-03-18 0:53 UTC (permalink / raw)
To: Sup users
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/
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [sup-talk] background or queue msg sending
2011-03-18 0:53 ` Tero Tilus
@ 2011-03-18 1:31 ` Philippe LeCavalier
0 siblings, 0 replies; 14+ messages in thread
From: Philippe LeCavalier @ 2011-03-18 1:31 UTC (permalink / raw)
To: sup-talk
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
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [sup-talk] background or queue msg sending
2011-03-17 23:08 ` Philippe LeCavalier
@ 2011-03-18 1:34 ` Philippe LeCavalier
0 siblings, 0 replies; 14+ messages in thread
From: Philippe LeCavalier @ 2011-03-18 1:34 UTC (permalink / raw)
To: sup-talk
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
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2011-03-18 2:28 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-03-17 14:17 [sup-talk] background or queue msg sending Philippe LeCavalier
2011-03-17 15:32 ` Bruno d'Arcangeli
2011-03-17 19:15 ` Philippe LeCavalier
2011-03-17 19:55 ` Ben Walton
2011-03-17 20:16 ` Kevin Riggle
2011-03-17 23:10 ` Philippe LeCavalier
2011-03-17 19:54 ` Tero Tilus
2011-03-17 20:10 ` Philippe LeCavalier
2011-03-17 22:32 ` Sascha Silbe
2011-03-17 23:08 ` Philippe LeCavalier
2011-03-18 1:34 ` Philippe LeCavalier
2011-03-18 0:53 ` Tero Tilus
2011-03-18 1:31 ` Philippe LeCavalier
2011-03-17 22:42 ` Sean Escriva
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox