On Sat, May 19, 2001 at 02:00:10AM +0530, Joane Lispton wrote:
Hi Dave,
Sounds like you're trying too hard here. With sendmail (insert your MTA
of choice here as I'm sure they all work in a similar way) all I simply
need to do is type mailq and I can see what's still in the queue and
why.
On Thu, May 17, 2001 at 11:49:15PM -0400, Walt Mankowski wrote:
On Thu, May 17, 2001 at 12:49:27PM +0530, Joane Lispton wrote:
So, if, e.g., the PPP link is down and I haven't noticed that, mutt will
tell me that my email has been sent, while it is actually stored in some
directory on my
On Fri, May 18, 2001 at 04:43:02PM +0100, Dave Pearson wrote:
It's not just laptops. Any machine with a dial-up connection where that
connection is dial-on-demand really needs queueing. [SNIP]
That should have read /isn't/ dial-in-demand.
--
Dave Pearson: | mutt.octet.filter -
On Fri, 18 May 2001, Joane Lispton wrote:
To sum it up, when it comes to the trade-off between
- doing all the queueing manually, and knowing (from within mutt) that mail
has been successfully relayed
and
- having a MTA do the queueing for me, yet, if I wish to make sure that
On Fri, May 18, 2001 at 11:48:23PM +0530, Joane Lispton wrote:
Hi Dave,
When I bring up the link the queue gets flushed. Nice and simple.
That's my problem with queueing MTAs: if the link goes down before the MTA
relays the emails (e.g., my connection is accidently dropped while I am in
