Re: [feature req] Configurable behaviour after MTA failure
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. Your are right, of course. Dan also pointed that out. But, using mailq still means that I must put mutt into the background and run some command, which is pretty different from knowing the Mail sent means ... well, exactly that! :-) True, there's a difference in your case. I wasn't suggesting that your method of working off line as any less valid than mine (it seems that I'm really off-line but you have some on-line version of off-line, dial on demand perhaps?). As for putting mutt into the background. No need for that at all. A quick mutt macro to run mailq would let you feel that the facility was part of mutt itself. I run all sorts of external tools from mutt to help me manage email. Point here being, there are far easier and far more integrated ways of doing this (that don't require mutt to be modified) than scanning logs. I know this doesn't make your environment as useful as you'd like but the current setup doesn't need to be as unwieldy as you've reported it is. -- Dave Pearson: | mutt.octet.filter - autoview octet-streams http://www.davep.org/ | mutt.vcard.filter - autoview simple vcards Mutt: | muttrc2html - muttrc - HTML utility http://www.davep.org/mutt/ | muttrc.sl - Jed muttrc mode
Re: [feature req] Configurable behaviour after MTA failure
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 hard-drive, awaiting my next connection to the Internet... probably established to download the replies to the emails I _thought_ I had sent! I actually think queueing is a *feature* on laptops. I frequently compose emails while I'm disconnected (say on a train or in a coffeeshop) and intentionally let the MTA queue them up. When I'm back online the MTA will take of sending them without my worrying about it. It's not just laptops. Any machine with a dial-up connection where that connection is dial-on-demand really needs queueing. I've had a net connection like this since 1995 and have been using sendmail to do the queue handling all that time. When I bring up the link the queue gets flushed. Nice and simple. -- Dave Pearson: | mutt.octet.filter - autoview octet-streams http://www.davep.org/ | mutt.vcard.filter - autoview simple vcards Mutt: | muttrc2html - muttrc - HTML utility http://www.davep.org/mutt/ | muttrc.sl - Jed muttrc mode
Re: [feature req] Configurable behaviour after MTA failure
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 - autoview octet-streams http://www.davep.org/ | mutt.vcard.filter - autoview simple vcards Mutt: | muttrc2html - muttrc - HTML utility http://www.davep.org/mutt/ | muttrc.sl - Jed muttrc mode
Re: [feature req] Configurable behaviour after MTA failure
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 something is already at the relay host, I have to dig in log files, wouldn't mailq still tell you the mail is in the queue, and hasn't been flush yet? not saying that the option not to store the fcc on failed delivery is a bad thing, just another way to check :) Dan
Re: [feature req] Configurable behaviour after MTA failure
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 mutt), I think they were flushed but they still are on my hard-drive. And to really make sure that mail got _sent_, I have to look at SMTP log files... :-( 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. 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 something is already at the relay host, I have to dig in log files, I've never needed to dig in the logs to see if anything has gone. I simple check the queue. Further to that, most of my net connections are done at timed intervals and are brought up via cron. Quite often I'm not even at my desk when this happens. As you might imagine any kind of manual intervention on my part, be it handling the queue by hand or reading logs, would be out of the question. -- Dave Pearson: | mutt.octet.filter - autoview octet-streams http://www.davep.org/ | mutt.vcard.filter - autoview simple vcards Mutt: | muttrc2html - muttrc - HTML utility http://www.davep.org/mutt/ | muttrc.sl - Jed muttrc mode
