On Fri, Feb 12, 2021 at 05:09:36PM -0000, Grant Edwards wrote: > On 2021-02-12, Derek Martin <inva...@pizzashack.org> wrote: > >>> as I would have to be monitoring the logs to make sure the e-mail > >>> was actually sent. > >> > >> You do (or you need to make sure that you receive bounce/retry/failure > >> notices properly). > > > > You don't... every major MTA has a tool for monitoring the outgoing > > mail queue. You just run it and it tells you if there is any pending > > outgoing e-mail. > > To me that seems pretty much equivalent to "monitorying the logs".
I think the difference is monitoring the logs is something you have to actively do, which means you also need to remember to do it... and most of the time it's a waste of your time. Instead, using this method, you don't actively need to do anything... when something noteworthy happens you'll be notified via a mechanism you're already using anyway. For me, that's a world of difference... not at all equivalent. > > If this is a concern, you can run it periodically from cron (or > > whatever), in such a way that it only e-mails you when there are > > issues (i.e. pending mail). If you find some messages are > > lingering, then you can go look at your logs to figure out why. > > Again, that's far more complicated that waiting one or two seconds > after you hit 'y', and seeing whether the message was sent or not. I don't really agree... it's something you set up once and mostly forget about. In today's well-connected internet, probably lots of people could do this and never interact with it ever again. TBH I don't bother doing even this anymore, because I just haven't had an issue with mail delivery in well over a decade... > > YMMV. I have maintained my own server for ~20+ years now and the only > > time I've had issues was when I was running it on consumer broadband > > and people started using blacklists that included essentially all > > known consumer broadband networks to block spam (whther it was or > > not), > > That is probably the main problem for most mutt users. The only > practical way for must of us to run an MTA is for it to always send > via one reliabe SMTP server with authentication. Sending mail directly > to recipients has been off the table for residential consumers. I definitely agree. It's an annoying problem. This really should be a lot simpler, but it's a case of a few bad actors ruining things for the rest. Yay. But anyway, IMO you can do this just as easily by setting up your local MTA to forward to your ISP's gateway as by using Mutt's SMTP support or some other mini-MTA, with the benefit that if you're writing e-mail on your laptop when you're not able to have internet connectivity, it will queue locally and still get delivered later once you can talk to your ISP's gateway again. This feature won't be impactful for everyone, but it is definitely useful. With most modern MTA software this is pretty trivial to configure, and tutorials on how to do it for your MTA of choice abound. > > It does have a down side though... if your recipient's mail gateway > > is down or unreachable, sending your mail will fail, and you'll have > > to try again manually, until it eventually succeeds. > > Maybe I'm just lucky, but I can't ever remember the last time that > happened. Right... Things have gotten a lot better / more reliable over time. This used to be a common problem, but no longer. If it's not clear I'm not saying what you're doing is garbage. :) But I am saying that both approaches have benefits, and I think the drawbacks to the MTA approach may not be as severe as you seem to suggest, in practice, for the majority of Mutt users. I would not suggest something like this to, say, my mom... ;-) -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
signature.asc
Description: PGP signature
