Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Mon, Feb 15, 2021 at 09:43:30AM +0300, Oleg A. Mamontov wrote: I think what you suggest -- an manual 'msmtp-queue -r' as needed -- is more than ample for my use case. For that matter, in most instances I don't even mind waiting until I send another email which will achieve the same effect. The same with me :) That's why I have no cronjob for `msmtp-queue -r` but just two additional mutt macroses: --- macro index q "!clear; msmtp-queue""show send queue" macro index Q "!clear; msmtp-queue -r" "re-send from queue" Fair enough! (I'm not sure this expression is appropriate in this case, but I always wanted to use it. Hehe) I'm adding those macros myself, too, they might come handy despite of having the crontab entry set. My reasoning would be that if I forget to flush the queue once for important mail and cron does it for me and saves the day, it'd be worth having the cron job trying every hour or so (doing nothing is computationally cheap). Cheers, Ángel
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Sun, Feb 14, 2021 at 06:39:10PM -0600, boB Stepp wrote: On 21/02/14 10:25AM, Angel M Alganza wrote: On Sun, Feb 14, 2021 at 01:10:41AM -0600, boB Stepp wrote: On 21/02/13 08:03PM, Sam Kuper wrote: A queue script is included with msmtp, so you can have the best of both worlds :) https://git.marlam.de/gitweb/?p=msmtp.git;a=blob_plain;f=scripts/msmtpq/README.msmtpq;hb=HEAD Is there an obvious way forward to check periodically for regaining the network connection and flushing the queue? From the URL above: msmtp-queue -r -- runs (flushes) all the contents of the queue Try running 'msmtp-queue -r' at your shell. It should trigger sending. Adding 'msmtp-queue -r' as a cron job should do it automatically. I saw that, but wanted to be sure I wasn't missing any functionality built-in due to my lack of understanding or ignorance. If there is built-in functionality to do this, I am not finding it. I haven't found one, but I think it'd go through cron or some other scheduling system. So it sounds like I wasn't missing anything from what you and Sam are saying. I don't send out very many emails; I read far more than I respond to. My Internet connection is usually very reliable. I am wondering if it is even worth the effort for a cron job on this. I think what you suggest -- an manual 'msmtp-queue -r' as needed -- is more than ample for my use case. For that matter, in most instances I don't even mind waiting until I send another email which will achieve the same effect. The same with me :) That's why I have no cronjob for `msmtp-queue -r` but just two additional mutt macroses: --- macro index q "!clear; msmtp-queue""show send queue" macro index Q "!clear; msmtp-queue -r" "re-send from queue" --- Thank you very much for everyone's suggestions! My Mutt installation is getting better and better and faster and faster! -- Wishing you only the best, boB Stepp -- Cheers, Oleg A. Mamontov mailto: o...@mamontov.net skype: lonerr11 cell: +7 (903) 798-1352
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Sun, Feb 14, 2021 at 06:39:10PM -0600, boB Stepp wrote: msmtp-queue -r -- runs (flushes) all the contents of the queue Try running 'msmtp-queue -r' at your shell. It should trigger sending. Adding 'msmtp-queue -r' as a cron job should do it automatically. So it sounds like I wasn't missing anything from what you and Sam are saying. I don't send out very many emails; I read far more than I respond to. My Internet connection is usually very reliable. I am wondering if it is even worth the effort for a cron job on this. Same here, most of the time, but I do mail on many different devices, some of which I take out with me (on travels, for walks to do some exercise and take some lithe sun bathe, for work to places I don't have any other connection than data on my phone, etc.). In any case, even when I am on the conditions you describe, the "effort for a cron job on this" is, of course, worth. The effort to set it up is a couple of minutes adding a line to the crontab, and the "computation effort" of running 'msmtp-queue -r' every hour, for example, or even much more often, is close to zero. And you probably are using cron to trigger downloading mail anyway already, right? As I also said before, in my case, I have a few lines to download different type of mail at different frequencies. I think what you suggest -- an manual 'msmtp-queue -r' as needed -- is more than ample for my use case. For that matter, in most instances I don't even mind waiting until I send another email which will achieve the same effect. Sure, if you remember do in it. In any case, I wasn't suggesting to always do it manually, but for you to try it out once to see its effect before adding it to your crontab. :-) In case you either had missed it in the documentation. Thank you very much for everyone's suggestions! My Mutt installation is getting better and better and faster and faster! Same here. As I said on a previous email in this thread, I had settled to wait for msmtp to deliver my outgoing mail when online, which was tolerable, but a little annoying some times, and to just flag mail I needed to reply while offline to reply them later, when online, which was much worse, since some times I forgot I had to do it. Now, both things are gone, which makes my set up much better. I wonder what other wonderful things are out there that could improve it further. The cool thing is that when I come across some of those, like in this case, it is so exiting and so much fun to discover, test, set up, and then enjoy using them... Cheers, Ángel (exited to hit 'y' to see this mail sent out of mutt as fast as it used to happen when I ran exim in all my boxes.)
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On 21/02/14 10:25AM, Angel M Alganza wrote: On Sun, Feb 14, 2021 at 01:10:41AM -0600, boB Stepp wrote: On 21/02/13 08:03PM, Sam Kuper wrote: A queue script is included with msmtp, so you can have the best of both worlds :) https://git.marlam.de/gitweb/?p=msmtp.git;a=blob_plain;f=scripts/msmtpq/README.msmtpq;hb=HEAD Is there an obvious way forward to check periodically for regaining the network connection and flushing the queue? From the URL above: msmtp-queue -r -- runs (flushes) all the contents of the queue Try running 'msmtp-queue -r' at your shell. It should trigger sending. Adding 'msmtp-queue -r' as a cron job should do it automatically. I saw that, but wanted to be sure I wasn't missing any functionality built-in due to my lack of understanding or ignorance. If there is built-in functionality to do this, I am not finding it. I haven't found one, but I think it'd go through cron or some other scheduling system. So it sounds like I wasn't missing anything from what you and Sam are saying. I don't send out very many emails; I read far more than I respond to. My Internet connection is usually very reliable. I am wondering if it is even worth the effort for a cron job on this. I think what you suggest -- an manual 'msmtp-queue -r' as needed -- is more than ample for my use case. For that matter, in most instances I don't even mind waiting until I send another email which will achieve the same effect. Thank you very much for everyone's suggestions! My Mutt installation is getting better and better and faster and faster! -- Wishing you only the best, boB Stepp
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Sun, Feb 14, 2021 at 10:25:21AM +0100, Angel M Alganza wrote: > msmtp-queue -r -- runs (flushes) all the contents of the queue > > Try running 'msmtp-queue -r' at your shell. It should trigger sending. > > Adding 'msmtp-queue -r' as a cron job should do it automatically. Exactly. If you want it to try regularly, that's the way to do it. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Sun, Feb 14, 2021 at 01:10:41AM -0600, boB Stepp wrote: On 21/02/13 08:03PM, Sam Kuper wrote: A queue script is included with msmtp, so you can have the best of both worlds :) https://git.marlam.de/gitweb/?p=msmtp.git;a=blob_plain;f=scripts/msmtpq/README.msmtpq;hb=HEAD Is there an obvious way forward to check periodically for regaining the network connection and flushing the queue? From the URL above: msmtp-queue -r -- runs (flushes) all the contents of the queue Try running 'msmtp-queue -r' at your shell. It should trigger sending. Adding 'msmtp-queue -r' as a cron job should do it automatically. I hope it helps. If there is built-in functionality to do this, I am not finding it. I haven't found one, but I think it'd go through cron or some other scheduling system. Cheers, Ángel
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On 21/02/13 08:03PM, Sam Kuper wrote: On Fri, Feb 12, 2021 at 01:30:04PM +0100, Angel M Alganza wrote: I did the same myself for years and also switched to ssmtp. But I belive ssmtp was discontinued, and now I'm using msmtp: https://marlam.de/msmtp/ I couldn't be happier! A queue script is included with msmtp, so you can have the best of both worlds :) https://git.marlam.de/gitweb/?p=msmtp.git;a=blob_plain;f=scripts/msmtpq/README.msmtpq;hb=HEAD I went ahead tonight and compiled msmtp from source to get version 1.8.14. I was previously on 1.8.8. I did the steps suggested in the link you provided. Everything worked well. Then I thought I would test this queuing functionality. I disconnected from my network and sent a test email. It promptly popped up in the queue directory. So far so good. I reconnected to my network and waited expectantly for the queued mails to be sent. They just sat there. I looked through the source of the msmtpq script and AFAICT queued emails will *not* be sent until the next attempt to send a mail. So I tested this and sure enough the queue flushed itself and my earlier queued email was sent. As I do not consider myself competent in shell scripting, am I reading the source correctly? Is there an obvious way forward to check periodically for regaining the network connection and flushing the queue? If there is built-in functionality to do this, I am not finding it. TIA! -- Wishing you only the best, boB Stepp
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Sun, Feb 14, 2021 at 02:43:32AM +0100, Angel M Alganza wrote: >On Sun, Feb 14, 2021 at 02:35:38AM +0100, Angel M Alganza wrote: >>On Sat, Feb 13, 2021 at 08:03:49PM +, Sam Kuper wrote: >>> On Fri, Feb 12, 2021 at 01:30:04PM +0100, Angel M Alganza wrote: On Mon, Feb 01, 2021 at 04:34:47PM -, Grant Edwards wrote: > I maintained a local queueing MTA for many years, but after > multiple screwups where mail wasn't getting sent (and I didn't > find out in a timely manner) I switched to a non-queueing MTA > (e.g. ssmtp) and later to mutt's SMTP support. I did the same myself for years and also switched to ssmtp. But I belive ssmtp was discontinued, and now I'm using msmtp: https://marlam.de/msmtp/ I couldn't be happier! >>> >>> A queue script is included with msmtp, so you can have the best of >>> both worlds :) >>> >>> https://git.marlam.de/gitweb/?p=msmtp.git;a=blob_plain;f=scripts/msmtpq/README.msmtpq;hb=HEAD >> >> You proved me wrong: I could be happier! >> And I am, since I'm sending this through the msmtp queue. Yay! >> >> Thanks a lot. > > I'm replying to myself to add: send is super-fast now, instant > actually, from Mutt! I love it! Yes, it's great :) I have CC'd Martin Lambers (author of msmtp). Thank you, Martin :) And thank you to Kevin as always, for Mutt :) -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Sun, Feb 14, 2021 at 02:35:38AM +0100, myself wrote: And I am, since I'm sending this through the msmtp queue. Yay! I'm replying to myself to add: send is super-fast now, instant actually, from Mutt! I love it! Cheers, Ángel
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On 21/02/14 10:52AM, Cameron Simpson wrote: On 12Feb2021 23:20, boB Stepp wrote: something I like working with notmuch. I wish I could use notmuch's tagging capabilities from within Mutt in the sense of adding multiple tags to a single email or a set of tagged emails. But the only example of an approach is to try to adapt the macro I cited earlier in this thread which deletes the inbox tag. I see how to modify this to do *one* tag, but that would be hard-coded and not very flexible or useful. I'm sure there must be a way to write a macro to allow for me to enter multiple tags for notmuch, but I don't know enough about Mutt macros to see a way forwards yet. "notmuch tag" itself accepts multiple tags. Write a small shell script to prompt for the tags to change (in the same form as notmuch expects i.e. +tag and -tag) which then invokes notmuch. If you mean this macro: macro index \ "set my_old_pipe_decode=\$pipe_decode my_old_wait_key=\$wait_key nopipe_decode nowait_key\ notmuch-mutt tag -- -inbox\ set pipe_decode=\$my_old_pipe_decode wait_key=\$my_old_wait_key" \ "notmuch: remove message from inbox" it: - saves the pipe_decode and wait_key settings, and turns them off - pipes the current message through notmuch-mutt to remove the "inbox" tag - restores the old pipe_decode and wait_key settings The $my_blah= is a standard mutt hack because there's no "push temporary setting or value", and there are no settings called my_*. So people use $my_blah for "user variables". Piping the whole message through notmuch lets notmuch-mutt get the message-id in order to know which item to tag or untag. The it passes "id:$mid" to notmuch, where $mid is the message id. That's the mechanism. This is all starting to make sense. With the suggestions below I think I might be able to attack this. Many thanks, Cameron! To tag things interactively you have 2 issues: - specifying the messages to tag - specifying the tag changes For the latter I'd have a shell script which prompted for that, then ran notmuch. For the former, from inside mutt, I'd think there are 2 ways forward. With a single message you can just pipe it straight into the script, like the above macro does. With multiple messages I think I would tag them, and pipe all of them _separately_ through the script. Now, there are some ways to make that more convenient, particularly these settings: set auto_tag=yes set pipe_split=yes auto_tag=yes causes mutt to apply commands to all tagged messages (if any) or just the current message (if nothing tagged). pipe_split=yes causes mutt to run separate pipes per message when it pipes multiple messages, instead of concatenating them and running one pipe. You want that for notmuch-mutt. The notmuch-mutt script in the example above expects exactly one message on its input, _entirely_ to grab its message-id. So we want pipe_split-yes to invoke the script once for each message. Regarding prompting, I'd write a script like this (untested): #!/bin/sh set -ue echo -n "Enter tags to change (-tag, +tag): " >/dev/tty read tags -- Wishing you only the best, boB Stepp
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Sat, Feb 13, 2021 at 08:03:49PM +, Sam Kuper wrote: On Fri, Feb 12, 2021 at 01:30:04PM +0100, Angel M Alganza wrote: I couldn't be happier! A queue script is included with msmtp, so you can have the best of both worlds :) You proved me wrong: I could be happier! And I am, since I'm sending this through the msmtp queue. Yay! Thanks a lot. Cheers, Ángel
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On 21/02/13 08:03PM, Sam Kuper wrote: A queue script is included with msmtp, so you can have the best of both worlds :) https://git.marlam.de/gitweb/?p=msmtp.git;a=blob_plain;f=scripts/msmtpq/README.msmtpq;hb=HEAD Thanks for this link! -- Wishing you only the best, boB Stepp
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Sun, Feb 14, 2021 at 11:00:45AM +1100, Cameron Simpson wrote: > On 13Feb2021 20:03, Sam Kuper wrote: >> A queue script is included with msmtp, so you can have the best of >> both worlds :) >> >> https://git.marlam.de/gitweb/?p=msmtp.git;a=blob_plain;f=scripts/msmtpq/README.msmtpq;hb=HEAD > > Ah, I missed that. Nice. > > Though I still like a local system MTA so that scripts and cron etc > etc can also send email natively. The two approaches can coexist happily on the same machine: - a local MTA for cron, etc.; and - msmtpq for use by Mutt for outbound mail. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On 13Feb2021 20:03, Sam Kuper wrote: >On Fri, Feb 12, 2021 at 01:30:04PM +0100, Angel M Alganza wrote: >> On Mon, Feb 01, 2021 at 04:34:47PM -, Grant Edwards wrote: >>> I maintained a local queueing MTA for many years, but after multiple >>> screwups where mail wasn't getting sent (and I didn't find out in a >>> timely manner) I switched to a non-queueing MTA (e.g. ssmtp) and >>> later to mutt's SMTP support. >> >> I did the same myself for years and also switched to ssmtp. But I >> belive ssmtp was discontinued, and now I'm using msmtp: >> >> https://marlam.de/msmtp/ >> >> I couldn't be happier! > >A queue script is included with msmtp, so you can have the best of both >worlds :) > >https://git.marlam.de/gitweb/?p=msmtp.git;a=blob_plain;f=scripts/msmtpq/README.msmtpq;hb=HEAD Ah, I missed that. Nice. Though I still like a local system MTA so that scripts and cron etc etc can also send email natively. Cheers, Cameron Simpson
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On 12Feb2021 23:25, boB Stepp wrote: >On 21/02/13 08:01AM, Cameron Simpson wrote: >>I pull everything from my c...@cskk.id.au inbox, deleting it. But my >>mail >>filing forwards a suite of messages to a separate account which is for >>my phone. So anything important sends a copy back out to the cloud. >>Well, a personal external server. Um, in the cloud :-( >> >>Likewise, any email I reply to sends the source message and the reply to >>that account. >> >>In this way my phone has access to a copy of the critical stuff and also >>any ongoing email discussions. > >So it seems you only concern yourself in keeping relatively current emails >accessible to your phone? Well I pretty much never purge it, so old stuff too. >You haven't had occasion to need something from a >while back to fetch on your phone that suddenly becomes needed? Well, the phone account is meant to have "relevant" stuff rather than the dross comprising most email. So my filer forwards: - everything it flags on arrival - everything I send/reply - the source message of anything I reply to Cheers, Cameron Simpson
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On 12Feb2021 23:20, boB Stepp wrote: >>Then tag messages in you inbox and ";s+folder" to move them in >>batches. >>Here I mean mutt's (t)ag keystroke, an in memory flag. Emphemeral, used >>entirely to do mutt things to an ad hoc batch of messages. > >Yeah, I just was playing around with this some earlier in the week. I'm now >doing this to tag and move emails into my Archive folder, which I have bound >"S" for this purpose. Which leads me to a question I have been meaning to >ask. This is what I am using right now: > >macro index,pager S "=Archive" "Send to >Archive" > >If I don't add then the email(s) sit there marked deleted >(Funny that the same 'D' label is used here as for a real deletion.) until I >manually >sync or it happens automatically. I just want the mail to be _immediately_ >moved to my >local Archive folder. Is there a better, more direct way to do this without >doing a sync operation? The message will be copied to Archive immediately (you can check that by opening it in another window). It is just the current folder where they're not yet removed until you sync; that lets you under the "delete" part of the "move" if you want. If you wanted the sync immediate, include "" in the macro? It is a whole mail folder sync of course. Personally, my (d)elete macro just archives :-) Cheers, Cameron Simpson
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On 12Feb2021 23:20, boB Stepp wrote: >Yeah, I think you have. I have kept those earlier emails from you >nicely >flagged in my inbox for reference. Currently I am trying to see if I can get >something I like working with notmuch. I wish I could use notmuch's tagging >capabilities from within Mutt in the sense of adding multiple tags to a single >email or a set of tagged emails. But the only example of an approach is to >try to adapt the macro I cited earlier in this thread which deletes the inbox >tag. I see how to modify this to do *one* tag, but that would be hard-coded >and not very flexible or useful. I'm sure there must be a way to write a >macro to allow for me to enter multiple tags for notmuch, but I don't know >enough about Mutt macros to see a way forwards yet. "notmuch tag" itself accepts multiple tags. Write a small shell script to prompt for the tags to change (in the same form as notmuch expects i.e. +tag and -tag) which then invokes notmuch. If you mean this macro: macro index \ "set my_old_pipe_decode=\$pipe_decode my_old_wait_key=\$wait_key nopipe_decode nowait_key\ notmuch-mutt tag -- -inbox\ set pipe_decode=\$my_old_pipe_decode wait_key=\$my_old_wait_key" \ "notmuch: remove message from inbox" it: - saves the pipe_decode and wait_key settings, and turns them off - pipes the current message through notmuch-mutt to remove the "inbox" tag - restores the old pipe_decode and wait_key settings The $my_blah= is a standard mutt hack because there's no "push temporary setting or value", and there are no settings called my_*. So people use $my_blah for "user variables". Piping the whole message through notmuch lets notmuch-mutt get the message-id in order to know which item to tag or untag. The it passes "id:$mid" to notmuch, where $mid is the message id. That's the mechanism. To tag things interactively you have 2 issues: - specifying the messages to tag - specifying the tag changes For the latter I'd have a shell script which prompted for that, then ran notmuch. For the former, from inside mutt, I'd think there are 2 ways forward. With a single message you can just pipe it straight into the script, like the above macro does. With multiple messages I think I would tag them, and pipe all of them _separately_ through the script. Now, there are some ways to make that more convenient, particularly these settings: set auto_tag=yes set pipe_split=yes auto_tag=yes causes mutt to apply commands to all tagged messages (if any) or just the current message (if nothing tagged). pipe_split=yes causes mutt to run separate pipes per message when it pipes multiple messages, instead of concatenating them and running one pipe. You want that for notmuch-mutt. The notmuch-mutt script in the example above expects exactly one message on its input, _entirely_ to grab its message-id. So we want pipe_split-yes to invoke the script once for each message. Regarding prompting, I'd write a script like this (untested): #!/bin/sh set -ue echo -n "Enter tags to change (-tag, +tag): " >/dev/tty read tags
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On 12Feb2021 22:53, boB Stepp wrote: >On 21/02/13 08:11AM, Cameron Simpson wrote: >>I would guess your PC does not have a mail system installed. So cron >>cannot deliver the cron job output by email. > >I was aware that a cron job could email its output, but I thought I would have >to explicitly set that up. Is this not the case? In any event I do not know >enough at this time to do this, so I haven't done so. But if your hypothesis >is correct and it is trying to email me, but finding no MTA to enable it to do >so, why don't I *always* get this message? Cron only sends email when the job's output is not empty. Silent jobs do not try to send email. Is that plausible? >>One of the benefits of have a local email system is getting stuff from >>cron et al. Also, you can use it for spooling - if mutt sends via the >>local email system you can send when offline - it will just queue. >> >>>One concern based on earlier discussion in this thread. I am now using >>>msmtp as my MTA client. What will happen if I send an email when, for >>>whatever reason, Gmail connectivity is broken? Will it get resent? >> >>I don't know. What does its manual say? [...] >reading the past few days! My head is spinning chock full of half-understood >information about multiple email software and topics!! [...] >As far as I have been able to tell from the man pages msmtp will attempt to >send me a notification email in the event of delivery failure. AFAICT, there >is no explicit mention of msmtp trying to resend the email. Also it is not >clear to me if delivery failure includes not being able to connect to the >Internet. It did say it uses standard exit codes, but I did not see how it >would act in this instance. Looks to me like it does not queue: % (echo To: c...@cskk.id.au; echo From: cs; echo Subject: msmtp test;echo;echo 1) | msmtp --host=bogushost.example.com --from=c...@cskk.id.au -t c...@cskk.id.au msmtp: cannot locate host bogushost.example.com: nodename nor servname provided, or not known msmtp: could not send mail Caveat: I have no msmtp config - that's a bare command line test. There's a package called "nullmailer" which can be used as your system MTA - it is intended for systems with a smarthost - upstream SMTP server, exactly what you msmtp setup will be using. But it has a queue. You could install it without changing your mutt/msmtp setup at all. If it works for you, you could then switch to having mutt use the local sendmail command (the default) instead of msmtp. Looks like its config lives in /usr/local/etc/nullmailer. Source: https://github.com/bruceg/nullmailer Install: https://github.com/bruceg/nullmailer/blob/master/INSTALL Man page for nullmailer-send, which describes the config settings: https://github.com/bruceg/nullmailer/blob/master/doc/nullmailer-send.8 Disclaimer: I've not used it. Cheers, Cameron Simpson
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Fri, Feb 12, 2021 at 01:30:04PM +0100, Angel M Alganza wrote: > On Mon, Feb 01, 2021 at 04:34:47PM -, Grant Edwards wrote: >> I maintained a local queueing MTA for many years, but after multiple >> screwups where mail wasn't getting sent (and I didn't find out in a >> timely manner) I switched to a non-queueing MTA (e.g. ssmtp) and >> later to mutt's SMTP support. > > I did the same myself for years and also switched to ssmtp. But I > belive ssmtp was discontinued, and now I'm using msmtp: > > https://marlam.de/msmtp/ > > I couldn't be happier! A queue script is included with msmtp, so you can have the best of both worlds :) https://git.marlam.de/gitweb/?p=msmtp.git;a=blob_plain;f=scripts/msmtpq/README.msmtpq;hb=HEAD Sam -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On 21/02/13 08:01AM, Cameron Simpson wrote: On 01Feb2021 03:32, ಚಿರಾಗ್ ನಟರಾಜ್ wrote: 12021/00/30 09:27.95 ನಲ್ಲಿ, boB Stepp ಬರೆದರು: 2) I would like to remove all email storage from the cloud, that is, whether Gmail or ProtonMail, once I have my mail on my local PC I want to delete it from those accounts. What would be the best way to do this? If you use a separate mail syncing program like fetchmail or mbsync or whatever, you can tell it to delete emails on the server after (successfully!) fetching them. Personally, I don't know that I would recommend that, simply because you never know when you might actually need access to your emails from e.g. your phone. I use a comprimise here. I pull everything from my c...@cskk.id.au inbox, deleting it. But my mail filing forwards a suite of messages to a separate account which is for my phone. So anything important sends a copy back out to the cloud. Well, a personal external server. Um, in the cloud :-( Likewise, any email I reply to sends the source message and the reply to that account. In this way my phone has access to a copy of the critical stuff and also any ongoing email discussions. So it seems you only concern yourself in keeping relatively current emails accessible to your phone? You haven't had occasion to need something from a while back to fetch on your phone that suddenly becomes needed? -- Wishing you only the best, boB Stepp
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On 21/02/13 07:56AM, Cameron Simpson wrote: On 31Jan2021 21:16, boB Stepp wrote: 1) I eventually want to migrate all of my Gmail to ProtonMail. I will probably never entirely get rid of Gmail. For one thing it makes a good honey pot for when I must supply an email, but do not want to give out my preferred email. Might I suggest mailinator.com for this? It's a free service which accepts email for _any_ address @mailinator.com (and a suite of other domains for when systems special case reject mailinator). Messages are kept for a short preriod of time and only the text component. You can look at them with a web browser interface. There are no passwords (so pick a random address to avoid collisions). It is handy for temporary-but-necessary addresses, or for "boring" addresses (vendor spam). Hmm. This is a good idea. I have heard of such services, but never have looked them up to see what they can do or if they cost anything. But I would like to at least minimize the data they collect on me. I forward all email from the GMail account which is "To:" the GMail address, to my real address c...@cskk.id.au. I do leave it behind (so archived, not deleted) at the GMail end. I see two routes towards this migration: (a) Forwarding all Gmail to ProtonMail and only have Mutt track ProtonMail. As I get time I will notify everyone to use my new email address. I do that (GMail -> c...@cskk.id.au). If nothing else, there will always be services with you GMail address (or whatever old address). I haven't yet reached my final decision on what I am going to do. I have been using the Gmail address for quite a long time, so I would hate to miss an email from someone I care about that sends me one years out of the blue. Currently I have been setting up mbsync, msmtp and Mutt for multiple accounts. If nothing else it is teaching me a lot. Currently I am puzzling over the "bridge" needed for ProtonMail to ensure I understand it well enough to configure everything properly. Hopefully I will be done with this sometime this weekend. I also want to try out Mutt's sidebar feature to see what I think of it and using two email accounts seems like it would give it a good testing. I can always drop down to one account and forward Gmail to ProtonMail. 2) I would like to remove all email storage from the cloud, that is, whether Gmail or ProtonMail, once I have my mail on my local PC I want to delete it from those accounts. What would be the best way to do this? I collect from my c...@cskk.id.au account using getmail with a setting which deletes collected messages. So the actual c...@cskk.id.au inbox is normally empty. Another one I am still pondering. What do I want to keep where? 3) I would like my local storage of my emails to allow for me to store certain content types in sensible folders. For example, Python Tutor emails that I want to keep I would like to store in a Python Tutor folder, Mutt emails in a Mutt folder, etc. Pretty sure I'm mentioned this before. My process is getmail from c...@cskk.id.au, and a separate programme to file messages. I have my own (mailfiler), but procmail and other tools are popular. Yeah, I think you have. I have kept those earlier emails from you nicely flagged in my inbox for reference. Currently I am trying to see if I can get something I like working with notmuch. I wish I could use notmuch's tagging capabilities from within Mutt in the sense of adding multiple tags to a single email or a set of tagged emails. But the only example of an approach is to try to adapt the macro I cited earlier in this thread which deletes the inbox tag. I see how to modify this to do *one* tag, but that would be hard-coded and not very flexible or useful. I'm sure there must be a way to write a macro to allow for me to enter multiple tags for notmuch, but I don't know enough about Mutt macros to see a way forwards yet. The other option is to install one of these notmuch user interfaces and do my tagging outside of Mutt. But that seems a bit of an awkward setup. Probably I would best be served by a manual, not an automatic, moving into desired folders as I will be picky as to those emails I would like to keep. What would be the best advice on this? Then tag messages in you inbox and ";s+folder" to move them in batches. Here I mean mutt's (t)ag keystroke, an in memory flag. Emphemeral, used entirely to do mutt things to an ad hoc batch of messages. Yeah, I just was playing around with this some earlier in the week. I'm now doing this to tag and move emails into my Archive folder, which I have bound "S" for this purpose. Which leads me to a question I have been meaning to ask. This is what I am using right now: macro index,pager S "=Archive" "Send to Archive" If I don't add then the email(s) sit there marked deleted (Funny that the same 'D' label is used here as for a real deletion.) until I manually sync or it happens automatically. I just want the mail to be
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On 21/02/13 08:11AM, Cameron Simpson wrote: On 08Feb2021 14:43, boB Stepp wrote: So I changed the command to: mbsync -a -qq and everything has been working. I was curious as to what would happen at 3 AM when my router would reboot. I got: Feb 8 03:00:01 Dream-Machine1 CRON[614314]: (bob) CMD (mbsync -a -qq ) Feb 8 03:00:24 Dream-Machine1 CRON[614312]: (CRON) info (No MTA installed, discarding output) Hmm. The same "No MTA installed, discarding output" as with the originally worded command. More information, but I still do not see why this message is generated. I would guess your PC does not have a mail system installed. So cron cannot deliver the cron job output by email. I was aware that a cron job could email its output, but I thought I would have to explicitly set that up. Is this not the case? In any event I do not know enough at this time to do this, so I haven't done so. But if your hypothesis is correct and it is trying to email me, but finding no MTA to enable it to do so, why don't I *always* get this message? One of the benefits of have a local email system is getting stuff from cron et al. Also, you can use it for spooling - if mutt sends via the local email system you can send when offline - it will just queue. One concern based on earlier discussion in this thread. I am now using msmtp as my MTA client. What will happen if I send an email when, for whatever reason, Gmail connectivity is broken? Will it get resent? I don't know. What does its manual say? You don't know how much documentation and search results I have been reading the past few days! My head is spinning chock full of half-understood information about multiple email software and topics!! As far as I have been able to tell from the man pages msmtp will attempt to send me a notification email in the event of delivery failure. AFAICT, there is no explicit mention of msmtp trying to resend the email. Also it is not clear to me if delivery failure includes not being able to connect to the Internet. It did say it uses standard exit codes, but I did not see how it would act in this instance. I am doing some online searching, but the answer I desire isn't coming up with my current search terms. But I will persist. I always seem to do... -- Wishing you only the best, boB Stepp
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Fri, Feb 12, 2021 at 10:20:09PM -, Grant Edwards wrote:
> On 2021-02-12, Derek Martin wrote:
> > On Fri, Feb 12, 2021 at 05:09:36PM -, Grant Edwards wrote:
> >> On 2021-02-12, Derek Martin 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...
>
> Ah, I see. I assumed that that "monitoring logs" was something one
> would do with an automated tool/script.
I mean I suppose so... but that seems much more involved than just
numreqs=`mailq |grep 'Total' | awk '{ print $3 }'`; if [ $numreqs -ne 0 ];
then echo "mail queue has $numreqs requests queued"; fi
[Exact details may vary from system to system, but should be pretty
similar to this one-liner in general.]
You'd have to figure out what your logs actually look like when queued
mail isn't getting delivered, then install and configure your tool to
monitor for those logs... which might be prone to break if your MTA
gets upgraded. Still not quite equivalent--it wouldn't be my choice.
Then I'm not sure but IIRC some MTAs don't log about queued mail not
getting delivered until it has failed to deliver for some time. If so
you would not get timely results, not like what the OP is looking for,
so in that case it wouldn't be an adequate solution anyway.
--
Derek D. Martinhttp://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
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On 01Feb2021 16:03, ಚಿರಾಗ್ ನಟರಾಜ್ wrote: > sending emails might well be time-sensitive, and I _need_ to know > that it went through (or get immediate feedback if it fails). So let's be clear: If you have time-sensitive communications that need to be delivered immediately, reliably, you should almost certainly not be using e-mail for them. Just becaue your mail client is able to hand off your message to your outgoing mail gateway in no way means that it is guaranteed to be delivered quickly, or even at all... Delivery may still fail or be delayed due to intervening mail servers' load, connectivity, hardware failures, botched configuration changes, etc., and in all likelihood you won't know anything about it. If you can not accept this, you must not use e-mail to deliver your message. If you can accept this, then having the message queue locally on your machine is less of a risk than having it queue on any other SMTP node along the way, because you can actively detect such problems and potentially do something to fix them, whereas in all other cases you simply can not. And the reality is, once your networking and your MTA is configured correctly, as long as your internet connection is working, your mail will go out, and will continue to go out so long as you don't muck with things and subsequently botch them. If you do make subsequent changes, of course you will need to test them... -- Derek D. Martinhttp://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
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On 2021-02-12, Derek Martin wrote: > On Fri, Feb 12, 2021 at 05:09:36PM -, Grant Edwards wrote: >> On 2021-02-12, Derek Martin 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... Ah, I see. I assumed that that "monitoring logs" was something one would do with an automated tool/script. -- Grant
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On 01Feb2021 16:03, ಚಿರಾಗ್ ನಟರಾಜ್ wrote: >I tend to think similarly. It's okay if receiving emails is a bit >delayed or runs into problems, but sending emails might well be >time-sensitive, and I _need_ to know that it went through (or get >immediate feedback if it fails). If it didn't leave my box the "mailq" command shows it. Cheers, Cameron Simpson
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On 08Feb2021 14:43, boB Stepp wrote: >So I changed the command to: > >mbsync -a -qq > >and everything has been working. I was curious as to what would happen at >3 AM when my router would reboot. I got: > >Feb 8 03:00:01 Dream-Machine1 CRON[614314]: (bob) CMD (mbsync -a -qq ) >Feb 8 03:00:24 Dream-Machine1 CRON[614312]: (CRON) info (No MTA installed, >discarding output) > >Hmm. The same "No MTA installed, discarding output" as with the originally >worded command. More information, but I still do not see why this message >is generated. I would guess your PC does not have a mail system installed. So cron cannot deliver the cron job output by email. One of the benefits of have a local email system is getting stuff from cron et al. Also, you can use it for spooling - if mutt sends via the local email system you can send when offline - it will just queue. >One concern based on earlier discussion in this thread. I am now using >msmtp as my MTA client. What will happen if I send an email when, for >whatever reason, Gmail connectivity is broken? Will it get resent? I don't know. What does its manual say? Cheers, Cameron Simpson
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On 01Feb2021 03:32, ಚಿರಾಗ್ ನಟರಾಜ್ wrote: >12021/00/30 09:27.95 ನಲ್ಲಿ, boB Stepp ಬರೆದರು: >> 2) I would like to remove all email storage from the cloud, that is, >> whether Gmail or ProtonMail, once I have my mail on my local PC I want to >> delete it from those accounts. What would be the best way to do this? > >If you use a separate mail syncing program like fetchmail or mbsync or >whatever, you can tell it to delete emails on the server after >(successfully!) fetching them. Personally, I don't know that I would >recommend that, simply because you never know when you might actually >need access to your emails from e.g. your phone. I use a comprimise here. I pull everything from my c...@cskk.id.au inbox, deleting it. But my mail filing forwards a suite of messages to a separate account which is for my phone. So anything important sends a copy back out to the cloud. Well, a personal external server. Um, in the cloud :-( Likewise, any email I reply to sends the source message and the reply to that account. In this way my phone has access to a copy of the critical stuff and also any ongoing email discussions. Cheers, Cameron Simpson
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On 31Jan2021 21:16, boB Stepp wrote: >1) I eventually want to migrate all of my Gmail to ProtonMail. I will >probably never entirely get rid of Gmail. For one thing it makes a good >honey pot for when I must supply an email, but do not want to give out my >preferred email. Might I suggest mailinator.com for this? It's a free service which accepts email for _any_ address @mailinator.com (and a suite of other domains for when systems special case reject mailinator). Messages are kept for a short preriod of time and only the text component. You can look at them with a web browser interface. There are no passwords (so pick a random address to avoid collisions). It is handy for temporary-but-necessary addresses, or for "boring" addresses (vendor spam). >But I would like to at least minimize the data they collect on me. >My distant end goal is to separate from Google software entirely, but doing >that seems >difficult until I determine how to solve my Android phone dilemmas. But that >is not a >concern for Mutt! I forward all email from the GMail account which is "To:" the GMail address, to my real address c...@cskk.id.au. I do leave it behind (so archived, not deleted) at the GMail end. >I see two routes towards this migration: (a) Forwarding all Gmail to >ProtonMail and only have Mutt track ProtonMail. As I get time I will >notify everyone to use my new email address. I do that (GMail -> c...@cskk.id.au). If nothing else, there will always be services with you GMail address (or whatever old address). >2) I would like to remove all email storage from the cloud, that is, >whether Gmail or ProtonMail, once I have my mail on my local PC I want to >delete it from those accounts. What would be the best way to do this? I collect from my c...@cskk.id.au account using getmail with a setting which deletes collected messages. So the actual c...@cskk.id.au inbox is normally empty. >3) I would like my local storage of my emails to allow for me to store >certain content types in sensible folders. For example, Python Tutor emails >that I want to keep I would like to store in a Python Tutor folder, Mutt >emails in a Mutt folder, etc. Pretty sure I'm mentioned this before. My process is getmail from c...@cskk.id.au, and a separate programme to file messages. I have my own (mailfiler), but procmail and other tools are popular. >Probably I would best be served by a manual, >not an automatic, moving into desired folders as I will be picky as to those >emails I would like to keep. What would be the best advice on this? Then tag messages in you inbox and ";s+folder" to move them in batches. Here I mean mutt's (t)ag keystroke, an in memory flag. Emphemeral, used entirely to do mutt things to an ad hoc batch of messages. >5) I would like to be able to auto-backup locally stored emails on my >PC to another hard drive on my local network. I guess this would be >facilitated by a sensible organization of my PC's email storage? Yes. Though I keep all my email in a large "mail" directory (with many Maildir subdirectories). I back up that whole directory to local another server every so often. I do that with an external shell script, as I also back up other stuff. Cheers, Cameron Simpson
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Fri, Feb 12, 2021 at 05:09:36PM -, Grant Edwards wrote: > On 2021-02-12, Derek Martin 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. Martinhttp://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
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On 2021-02-12, Derek Martin 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". > 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. >>> How does it work when the remote e-mail server is not available or >>> it returns some kind of error. Can one receive local messages that >>> notify of a problem? >> >> If you set up your local MTA properly, yes. > > In practice you probably won't do this, unless you have the luxury of > operating a relay that is purely for outgoing messages that can't > receive mail from the internet. Otherwise the reality is you'll get > tons of bogus bounce messages that are just spam. Or perhaps you'll > use some spam filtering to figure out which bounce messages actually > matter... There are better alternatives, like what I described above. > >> My internet connection is reliable enough that the benefits of knowing >> that each email has actually been sent _far_ outweigh the >> inconvienience of having to manually resend something once every 5-6 >> years. > > 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. > 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. > If you use an outgoing mail relay it fixes this for you by > periodically retrying the message. This is pretty rare these days > though so it probably won't matter to you very much, unless you have > frequent recipients with proven unreliable mail gateways.
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Mon, Feb 01, 2021 at 04:34:47PM -, Grant Edwards wrote: > On 2021-02-01, José María Mateos wrote: > > I was thinking about this. I have offlineimap running, so I have a > > local copy of all my mail, but the SMTP connection still goes > > through my mail provider, not locally. While I can appreciate the > > increase in speed that a local rely can offer, I wonder if it > > doesn't add another layer of complexity In terms of the delivery process, it doesn't add a layer of complexity, it just adds a hop. SMTP is designed to work this way... If you look at the headers of all of your incoming messages, you might see half a dozen or more Recieved: headers on them. Each one which isn't your senders' outgoing mail gateways or your incoming mail server represents an MTA your message travels through to get from them to you. The only control over this which you have is which server your own outgoing messages hit first: A local MSA/MTA, your ISP's or organization's outgoing mail relay, or your recipients' first-hop MX mail server. If your connection to the internet is reliable, it makes very little difference which one, in almost all cases. No added complexity--just potentially additional hops. There may be extra complexity in the software you have to manage, for your outgoing mail to work, though. > > 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. 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. > > How does it work when the remote e-mail server is not available or > > it returns some kind of error. Can one receive local messages that > > notify of a problem? > > If you set up your local MTA properly, yes. In practice you probably won't do this, unless you have the luxury of operating a relay that is purely for outgoing messages that can't receive mail from the internet. Otherwise the reality is you'll get tons of bogus bounce messages that are just spam. Or perhaps you'll use some spam filtering to figure out which bounce messages actually matter... There are better alternatives, like what I described above. > My internet connection is reliable enough that the benefits of knowing > that each email has actually been sent _far_ outweigh the > inconvienience of having to manually resend something once every 5-6 > years. 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), and when I had a connectivity outage. For the most part the mail system will automatically recover from outages, so that wasn't a big deal... mail got delivered the first time the queue was run after connectivity was restored. Moving to inexpensive hosting solved the other problem--I haven't had any issues for well over 10 years... If you're using your ISP's gateway, you should likewise not have any issues, unless they are just bad at it. > > So far I like my current solution because it avoid this: sending an > > e-mail takes a few seconds (very few, 2 - 3 tops) but when the process > > is done on mutt I know the remote server has the e-mail. 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. If you use an outgoing mail relay it fixes this for you by periodically retrying the message. This is pretty rare these days though so it probably won't matter to you very much, unless you have frequent recipients with proven unreliable mail gateways. -- Derek D. Martinhttp://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
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On 21/02/12 01:40PM, Angel M Alganza wrote: On Mon, Feb 08, 2021 at 02:43:48PM -0600, boB Stepp wrote: killall mbsync &>/dev/null; /usr/bin/mbsync -a -qq Maybe it's an stupid idea, but perhaps mbsync is starting to run so fast that the killall kills it? You could try replacing the semicolon wich a couple of ampersand signs to make sure that mbsync is started only after killall has exited? killall mbsync &>/dev/null && /usr/bin/mbsync -a -qq Hmm. Worth a try. Thanks! -- Wishing you only the best, boB Stepp
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Thu, Feb 11, 2021 at 06:51:33AM -0500, David J. Weller-Fahy wrote: * * * * * flock -nx ~/.mbsync-lock-fast mbsync google-fast-cycle */5 * * * * flock -nx ~/.mbsync-lock-medium mbsync google-medium-cycle */15 * * * * flock -nx ~/.mbsync-lock-slow mbsync google-slow-cycle I do the same, but I call them new, day, old instead: - inbox run */5 8-0 * * * (every 5 minutes from 8am to midnight; I don't need a faster cycle) - inbox run 30 0-8 * * * (every hour from midnight to 8am) - "new" run @hourly - "day" run @daily - "old" run @weekly (no new mail ever, just there in case I delete some) I didn't know flock, and I have just added it in. It's great! Thanks. Cheers, Ángel
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Mon, Feb 08, 2021 at 02:43:48PM -0600, boB Stepp wrote: killall mbsync &>/dev/null; /usr/bin/mbsync -a -qq Maybe it's an stupid idea, but perhaps mbsync is starting to run so fast that the killall kills it? You could try replacing the semicolon wich a couple of ampersand signs to make sure that mbsync is started only after killall has exited? killall mbsync &>/dev/null && /usr/bin/mbsync -a -qq Cheers. Ángel
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Mon, Feb 01, 2021 at 04:34:47PM -, Grant Edwards wrote: I maintained a local queueing MTA for many years, but after multiple screwups where mail wasn't getting sent (and I didn't find out in a timely manner) I switched to a non-queueing MTA (e.g. ssmtp) and later to mutt's SMTP support. I did the same myself for years and also switched to ssmtp. But I belive ssmtp was discontinued, and now I'm using msmtp: https://marlam.de/msmtp/ I couldn't be happier!
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On 21/02/11 06:51AM, David J. Weller-Fahy wrote: I recently revamped my mbsync crontab jobs, and now have three separate jobs (fast, medium, and slow). I used an article about converting from offlineimap to mbsync [1] as inspiration. [1]: https://people.kernel.org/mcgrof/replacing-offlineimap-with-mbsync Actually this article is quite helpful. Thanks! -- Wishing you only the best, boB Stepp
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
* boB Stepp [2021-02-08 15:44 -0500]: ... I have setup a crontab job (My first ever!) to run mbsync every five minutes. Mutt checks the local mail much more frequently. Probably should make this a similar time interval to the crontab interval. I was concerned that if there were to be a network interruption or when my router reboots at 3 AM that mbsync would hang, but after one day of this it did not. I do have a question about this though. The original crontab command to run was: killall mbsync &>/dev/null; /usr/bin/mbsync -a -qq ... mbsync -a -qq and everything has been working. ... I recently revamped my mbsync crontab jobs, and now have three separate jobs (fast, medium, and slow). I used an article about converting from offlineimap to mbsync [1] as inspiration. [1]: https://people.kernel.org/mcgrof/replacing-offlineimap-with-mbsync For your information, my crontab looks like the following: #v+ * * * * * flock -nx ~/.mbsync-lock-fast mbsync google-fast-cycle */5 * * * * flock -nx ~/.mbsync-lock-medium mbsync google-medium-cycle */15 * * * * flock -nx ~/.mbsync-lock-slow mbsync google-slow-cycle #v- I hope that helps! Regards, -dave signature.asc Description: PGP signature
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Mon, Feb 08, 2021 at 02:43:48PM -0600, boB Stepp wrote: > Today's task is to understand and install/configure "notmuch" to > search through this locally stored mail. Notmuch is quite nice in some ways, but (as Dan Bernstein kindly pointed out to me a couple of years ago), it probably isn't necessary for most people because Mutt's "limit" feature is powerful enough. If you can live with the latter, then you can avoid notmuch altogether, which helps to keep your setup simple and your TCB small. >> 2) I would like to remove all email storage from the cloud, that is, >> whether Gmail or ProtonMail, ... > > For now I am abandoning this goal as it was pointed out that I might > want to access certain archived emails from my phone or some other > device outside of my PC. Some people do this by sync'ing their PC's mailboxes with their phone. This can be done various ways, including: - Unison (or rsync, but Unison is safer): https://www.cis.upenn.edu/~bcpierce/unison/ - Hosting your own IMAP server using Dovecot. >> 5) I would like to be able to auto-backup locally stored emails on >> my PC to another hard drive on my local network. I guess this would >> be facilitated by a sensible organization of my PC's email storage? > > Remains to be implemented. The above folder structure should make > this trivial to accomplish. If you use ZFS as your file system, look into Jim Salter's duo of helpful scripts: Sanoid and Syncoid. If you don't use ZFS (or at least another checksumming filesystem like btrfs), then maybe you should. Good luck in your quest! -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
I thought I would update folks on what I have done and solicit feedback as indicated. On 21/01/31 09:16PM, boB Stepp wrote: 1) I eventually want to migrate all of my Gmail to ProtonMail. I will probably never entirely get rid of Gmail... Based on previous advice here I am in the process of setting up my local Mutt infrastructure to be able to handle multiple email accounts. My local mail file structure is now: ~ / Mail / Gmail / Archive / Drafts / Inbox / Sent / Spam / Trash / ProtonMail Contents are Maildir format. I have eliminated all of the labeling/nested labeling I had applied to my Gmail account and reduced the IMAP accessibility to only see the above labels with the caveat that "Archive" is on the Gmail side "All Mail". I hope I don't regret the labeling removal! Today's task is to understand and install/configure "notmuch" to search through this locally stored mail. 2) I would like to remove all email storage from the cloud, that is, whether Gmail or ProtonMail, ... For now I am abandoning this goal as it was pointed out that I might want to access certain archived emails from my phone or some other device outside of my PC. I still wonder, though, if I should pare down what is stored in the Gmail cloud to the absolute minimum necessary, but retain the full archive on my PC? But this may be too hard and time-intensive and would appear to violate the bidirectional syncing between my PC and Gmail. 3) I would like my local storage of my emails to allow for me to store certain content types in sensible folders... Hopefully "notmuch" will make this goal unnecessary. 4) I would like to be able to quickly search through all locally stored emails... "notmuch" 5) I would like to be able to auto-backup locally stored emails on my PC to another hard drive on my local network. I guess this would be facilitated by a sensible organization of my PC's email storage? Remains to be implemented. The above folder structure should make this trivial to accomplish. Using the above folder structure I have installed isync/mbsync and msmtp. Both programs can easily handle multiple email accounts. Currently I only have Gmail setup, but once I have worked out all of the details, I will add my ProtonMail account and start the transition from Gmail to ProtonMail. I have setup a crontab job (My first ever!) to run mbsync every five minutes. Mutt checks the local mail much more frequently. Probably should make this a similar time interval to the crontab interval. I was concerned that if there were to be a network interruption or when my router reboots at 3 AM that mbsync would hang, but after one day of this it did not. I do have a question about this though. The original crontab command to run was: killall mbsync &>/dev/null; /usr/bin/mbsync -a -qq The thought was that if mbsync hung up due to a connectivity issue then the "killall mbsync" would solve this and reissue the command afresh. But I could never get this to work. When I checked my crontab logs I saw: Feb 8 01:35:01 Dream-Machine1 CRON[612121]: (bob) CMD (killall mbsync &>/dev/null; /usr/bin/mbsync -a -qq ) Feb 8 01:35:01 Dream-Machine1 CRON[612119]: (CRON) info (No MTA installed, discarding output) I never got this to work and I do not understand why it does not work. Can anyone shed any light on this? So I changed the command to: mbsync -a -qq and everything has been working. I was curious as to what would happen at 3 AM when my router would reboot. I got: Feb 8 03:00:01 Dream-Machine1 CRON[614314]: (bob) CMD (mbsync -a -qq ) Feb 8 03:00:24 Dream-Machine1 CRON[614312]: (CRON) info (No MTA installed, discarding output) Hmm. The same "No MTA installed, discarding output" as with the originally worded command. More information, but I still do not see why this message is generated. Anyway, so far, results-wise, I am extremely pleased with the improved responsiveness of Mutt. I thought Mutt was fast when it was doing all of the IMAP/smtp stuff itself. Now it is crazy instantaneous access to the local mail stores! Really like it!! One concern based on earlier discussion in this thread. I am now using msmtp as my MTA client. What will happen if I send an email when, for whatever reason, Gmail connectivity is broken? Will it get resent? Will I get a notification? I do not understand msmtp well enough (yet) to answer this. I suppose I could experiment and disconnect from my network, send an email and see what happens... Now on to "notmuch" and see what I can do about searching through my currently unlabeled/untagged email store. Any further guidance is always both solicited and welcome! Thanks for all of the help to date. -- Wishing you only the best, boB Stepp
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Sun, Jan 24, 2021 at 10:04:50PM -0600, boB Stepp wrote: > 1) Mutt erratically loses connection with Gmail and I have to > manually reconnect. Sometimes this happens rather frequently as in > multiple instances within an hour. I am confident it is not my > Internet connection, which is normally quite stable and fast. For > instance my streaming music is never interrupted, the family's TV > shows continue unimpeded, etc., but my connectivity to Gmail is > interrupted randomly. If I have both Mutt and the web interface open, > Mutt has its interruptions while the Gmail web interface appears to be > updating normally. Had the same problem, tried lowering imap_keepalive which didn't fix it but apparently the combination set imap_keepalive=180 set timeout=180 fixed it for me. Have one remaining problem - if sending an mail using builtin SMTP takes long the imap connection is lost anyway. However I use external SMTP programs most of the times. Richard
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Mon, Feb 01, 2021 at 04:34:47PM -, Grant Edwards wrote: If you set up your local MTA properly, yes. However, that's not trivial. I maintained a local queueing MTA for many years, but after multiple screwups where mail wasn't getting sent (and I didn't find out in a timely manner) I switched to a non-queueing MTA (e.g. ssmtp) and later to mutt's SMTP support. Been there, done that. I was running my own Postfix server back when you could get a dyndns domain name and no one really cared if you sent e-mails from your cable IP; and when that started to return too many errors I just started using Yahoo! SMTP servers as a relay. I'm amazed at how reckless I was back then :-) Cheers, -- José María (Chema) Mateos || https://rinzewind.org
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On 2021-02-01, José María Mateos wrote: > I was thinking about this. I have offlineimap running, so I have a > local copy of all my mail, but the SMTP connection still goes > through my mail provider, not locally. While I can appreciate the > increase in speed that a local rely can offer, I wonder if it > doesn't add another layer of complexity It definitely does. > 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). > How does it work when the remote e-mail server is not available or > it returns some kind of error. Can one receive local messages that > notify of a problem? If you set up your local MTA properly, yes. However, that's not trivial. I maintained a local queueing MTA for many years, but after multiple screwups where mail wasn't getting sent (and I didn't find out in a timely manner) I switched to a non-queueing MTA (e.g. ssmtp) and later to mutt's SMTP support. My internet connection is reliable enough that the benefits of knowing that each email has actually been sent _far_ outweigh the inconvienience of having to manually resend something once every 5-6 years. > So far I like my current solution because it avoid this: sending an > e-mail takes a few seconds (very few, 2 - 3 tops) but when the process > is done on mutt I know the remote server has the e-mail. Exactly. -- Grant
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
12021/00/31 04:49.41 ನಲ್ಲಿ, José María Mateos ಬರೆದರು: > > On Mon, Feb 01, 2021 at 06:32:41AM -0800, Andrew Marks wrote: > >Primarily speed, not waiting for mutt to establish an SMTP connection > >and authenticate to a remote MTA. The mail is sent to the local MTA > >instantly, and the local MTA is working to relay the mail appropriately > >while I continue working in mutt. > > I was thinking about this. I have offlineimap running, so I have a local > copy of all my mail, but the SMTP connection still goes through my mail > provider, not locally. While I can appreciate the increase in speed that > a local rely can offer, I wonder if it doesn't add another layer of > complexity as I would have to be monitoring the logs to make sure the > e-mail was actually sent. How does it work when the remote e-mail server > is not available or it returns some kind of error. Can one receive local > messages that notify of a problem? > > So far I like my current solution because it avoid this: sending an > e-mail takes a few seconds (very few, 2 - 3 tops) but when the process > is done on mutt I know the remote server has the e-mail. > > Cheers, > > -- > José María (Chema) Mateos || https://rinzewind.org I tend to think similarly. It's okay if receiving emails is a bit delayed or runs into problems, but sending emails might well be time-sensitive, and I _need_ to know that it went through (or get immediate feedback if it fails). - Chiraag -- ಚಿರಾಗ್ ನಟರಾಜ್ Pronouns: he/him/his publickey - mailinglist@chiraag.me - b0c8d720.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Mon, Feb 01, 2021 at 06:32:41AM -0800, Andrew Marks wrote: Primarily speed, not waiting for mutt to establish an SMTP connection and authenticate to a remote MTA. The mail is sent to the local MTA instantly, and the local MTA is working to relay the mail appropriately while I continue working in mutt. I was thinking about this. I have offlineimap running, so I have a local copy of all my mail, but the SMTP connection still goes through my mail provider, not locally. While I can appreciate the increase in speed that a local rely can offer, I wonder if it doesn't add another layer of complexity as I would have to be monitoring the logs to make sure the e-mail was actually sent. How does it work when the remote e-mail server is not available or it returns some kind of error. Can one receive local messages that notify of a problem? So far I like my current solution because it avoid this: sending an e-mail takes a few seconds (very few, 2 - 3 tops) but when the process is done on mutt I know the remote server has the e-mail. Cheers, -- José María (Chema) Mateos || https://rinzewind.org
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Mon, Feb 01, 2021 at 06:32:41AM -0800, Andrew Marks wrote: > On Sun, Jan 31, 2021 at 09:06:23AM +0100, Claus Assmann wrote: > > On Sun, Jan 31, 2021, Chinmaya Nagpal wrote: > > > > > I have a similar setup as yours, except I use the built-in SMTP. What > > > advantages are there to using an external sendmail program? > > Primarily speed, not waiting for mutt to establish an SMTP connection > and authenticate to a remote MTA. The mail is sent to the local MTA > instantly, and the local MTA is working to relay the mail appropriately > while I continue working in mutt. > > > > > Queueing. > > Yes, similar to the behavior of some GUI mail clients, your > online/offline use of mutt would be identical, you wouldn't have to save > messages as draft if you were offline, just send them out and the local > MTA will handle the queue, relaying when internet becomes available. Thank you both!
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Sun, Jan 31, 2021 at 09:06:23AM +0100, Claus Assmann wrote: > On Sun, Jan 31, 2021, Chinmaya Nagpal wrote: > > > I have a similar setup as yours, except I use the built-in SMTP. What > > advantages are there to using an external sendmail program? Primarily speed, not waiting for mutt to establish an SMTP connection and authenticate to a remote MTA. The mail is sent to the local MTA instantly, and the local MTA is working to relay the mail appropriately while I continue working in mutt. > > Queueing. Yes, similar to the behavior of some GUI mail clients, your online/offline use of mutt would be identical, you wouldn't have to save messages as draft if you were offline, just send them out and the local MTA will handle the queue, relaying when internet becomes available. (I don't know that I am properly setup with this, would have to read more about timeout/bouncing rules for my current MTA)
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
12021/00/30 09:27.95 ನಲ್ಲಿ, boB Stepp ಬರೆದರು: *snip* > > 1) I eventually want to migrate all of my Gmail to ProtonMail. I will > probably never entirely get rid of Gmail. For one thing it makes a good > honey pot for when I must supply an email, but do not want to give out my > preferred email. But I would like to at least minimize the data they collect > on me. > My distant end goal is to separate from Google software entirely, but doing > that seems > difficult until I determine how to solve my Android phone dilemmas. But that > is not a > concern for Mutt! > > I see two routes towards this migration: (a) Forwarding all Gmail to > ProtonMail and only have Mutt track ProtonMail. As I get time I will > notify everyone to use my new email address. (b) Track both accounts with > Mutt while doing the transition. What would your advice be? I have done exactly this, actually. I would connect Mutt to both accounts, simply because (as I found out) email migration is a giant PITA (pain in the a**). While you will be able to switch most of your accounts over quite quickly (if you have a record somewhere of where you have accounts open), there will be a 'long tail' of email addresses that simply won't update, and having quick access to both addresses, even if you mostly use the ProtonMail one, is quite useful. > > 2) I would like to remove all email storage from the cloud, that is, > whether Gmail or ProtonMail, once I have my mail on my local PC I want to > delete it from those accounts. What would be the best way to do this? If you use a separate mail syncing program like fetchmail or mbsync or whatever, you can tell it to delete emails on the server after (successfully!) fetching them. Personally, I don't know that I would recommend that, simply because you never know when you might actually need access to your emails from e.g. your phone. Also, unless you have impeccable backup practices (I know I don't!), having an extra copy always available on the server is useful. This is especially true if the mailbox isn't being monetised as in the case of ProtonMail. > > 3) I would like my local storage of my emails to allow for me to store > certain content types in sensible folders. For example, Python Tutor emails > that I want to keep I would like to store in a Python Tutor folder, Mutt > emails in a Mutt folder, etc. Probably I would best be served by a manual, > not an automatic, moving into desired folders as I will be picky as to those > emails I would like to keep. What would be the best advice on this? I would suggest tagging (using e.g. notmuch) over physically moving emails. This allows labelling one email with more than one tag and doesn't mess with the Maildir structure (you _can_ have subfolders and such within Maildir, but there are some differences of opinion over how this should be implemented and I personally recommend sticking with the regular "official" Maildir format - i.e. no sub-folders besides cur, new, and tmp). > > 4) I would like to be able to quickly search through all locally stored > emails. I think Andrew has already offered a good solution. Does anyone > have different thoughts on this from his? notmuch, period. > > 5) I would like to be able to auto-backup locally stored emails on my PC > to another hard drive on my local network. I guess this would be > facilitated by a sensible organization of my PC's email storage? Yes, backing up your emails should be part of your regular backup routine. I store all of my emails under ~/.local/mail/ with subdirectories for each account. HTH! - Chiraag -- ಚಿರಾಗ್ ನಟರಾಜ್ Pronouns: he/him/his publickey - mailinglist@chiraag.me - b0c8d720.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Sat, Jan 30, 2021 at 07:44:52AM -0800, Andrew Marks wrote: 1) Mutt erratically loses connection with Gmail and I have to manually reconnect. Sometimes this happens rather frequently as in multiple instances within an hour. I am confident it is not my Internet connection, which is normally quite stable and fast. For instance my streaming music is never interrupted, the family's TV shows continue unimpeded, etc., but my connectivity to Gmail is interrupted randomly. If I have both Mutt and the web interface open, Mutt has its interruptions while the Gmail web interface appears to be updating normally. I'd recommend using an separate IMAP-maildir sync tool like isync/mbsync. (https://isync.sourceforge.io). Waiting for IMAP (and even SMTP) operations in mutt is slow (not because of mutt, but because you are waiting for network transactions to occur). This type of setup also enables working with mail while offline. I'll never go back after switching to isync and a local postfix or ssmtp instance. I no longer compile mutt with IMAP, POP, or SMTP support.(Nothing against mutt or the devs for including this support, I recognize including support for these protocols is good and lowers the barrier to entry for most users.) Your response has caused me to ponder. The whole Mutt experience has been a very educational one in that it is teaching me piecemeal more about how email actually works, at least within my time constraints to explore/research. So most of my pondering is centered around my end goals. For instance, your post makes me aware that I have never considered the need for offline access to my emails. Your advice makes a lot of sense. Unsolicited advice: Mail (that you are through with) left on the IMAP server is mail-debt you will have to eventually pay. I delete or archive mail off-IMAP the moment there is no action. Combine your off-IMAP archive with notmuch, mairix, mu, or some other indexer so you can quickly find what you need in your vast archives. I think I am already paying! I have accumulated a large amount of email in my Gmail account, a fair amount I actually want to keep. I think I have been going about this wrong. I will state my end goals and perhaps I will get better advice for how to achieve them than my initial approach. 1) I eventually want to migrate all of my Gmail to ProtonMail. I will probably never entirely get rid of Gmail. For one thing it makes a good honey pot for when I must supply an email, but do not want to give out my preferred email. But I would like to at least minimize the data they collect on me. My distant end goal is to separate from Google software entirely, but doing that seems difficult until I determine how to solve my Android phone dilemmas. But that is not a concern for Mutt! I see two routes towards this migration: (a) Forwarding all Gmail to ProtonMail and only have Mutt track ProtonMail. As I get time I will notify everyone to use my new email address. (b) Track both accounts with Mutt while doing the transition. What would your advice be? 2) I would like to remove all email storage from the cloud, that is, whether Gmail or ProtonMail, once I have my mail on my local PC I want to delete it from those accounts. What would be the best way to do this? 3) I would like my local storage of my emails to allow for me to store certain content types in sensible folders. For example, Python Tutor emails that I want to keep I would like to store in a Python Tutor folder, Mutt emails in a Mutt folder, etc. Probably I would best be served by a manual, not an automatic, moving into desired folders as I will be picky as to those emails I would like to keep. What would be the best advice on this? 4) I would like to be able to quickly search through all locally stored emails. I think Andrew has already offered a good solution. Does anyone have different thoughts on this from his? 5) I would like to be able to auto-backup locally stored emails on my PC to another hard drive on my local network. I guess this would be facilitated by a sensible organization of my PC's email storage? I think that is the gist of my objectives. I do wish to point out that my upgrade to Mutt 2.0.5 has greatly enhanced the stability of my Mutt sessions. The only glitch so far is not really Mutt's fault -- I auto-reboot my router at 3 AM each day, which, of course, interrupts Mutt's connection to my Gmail account. But sometimes in the morning it has still managed to reconnect, which it never did previously under the older Mutt version I was using. Also, I seem to have solved my issues with cleverly embedded links not being accessible from within Mutt. A combination of better understanding on my part and urlview has gotten me around this. However, I am currently researching extract_url.pl as a better replacement for urlview. And, finally, getting Mutt to notify me of new emails via a beep still has me scratching my head. Apparently I need to
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Sun, Jan 31, 2021, Chinmaya Nagpal wrote: > I have a similar setup as yours, except I use the built-in SMTP. What > advantages are there to using an external sendmail program? Queueing.
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Sat, Jan 30, 2021 at 07:44:52AM -0800, Andrew Marks wrote: > I'd recommend using an separate IMAP-maildir sync tool like > isync/mbsync. (https://isync.sourceforge.io). Waiting for IMAP (and even > SMTP) operations in mutt is slow (not because of mutt, but because you > are waiting for network transactions to occur). This type of setup also > enables working with mail while offline. I'll never go back after > switching to isync and a local postfix or ssmtp instance. I no longer > compile mutt with IMAP, POP, or SMTP support.(Nothing against mutt or > the devs for including this support, I recognize including support for > these protocols is good and lowers the barrier to entry for most users.) I have a similar setup as yours, except I use the built-in SMTP. What advantages are there to using an external sendmail program? Chin
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
> 1) Mutt erratically loses connection with Gmail and I have to > manually reconnect. Sometimes this happens rather frequently as in > multiple instances within an hour. I am confident it is not my > Internet connection, which is normally quite stable and fast. For > instance my streaming music is never interrupted, the family's TV > shows continue unimpeded, etc., but my connectivity to Gmail is > interrupted randomly. If I have both Mutt and the web interface open, > Mutt has its interruptions while the Gmail web interface appears to be > updating normally. I'd recommend using an separate IMAP-maildir sync tool like isync/mbsync. (https://isync.sourceforge.io). Waiting for IMAP (and even SMTP) operations in mutt is slow (not because of mutt, but because you are waiting for network transactions to occur). This type of setup also enables working with mail while offline. I'll never go back after switching to isync and a local postfix or ssmtp instance. I no longer compile mutt with IMAP, POP, or SMTP support.(Nothing against mutt or the devs for including this support, I recognize including support for these protocols is good and lowers the barrier to entry for most users.) Unsolicited advice: Mail (that you are through with) left on the IMAP server is mail-debt you will have to eventually pay. I delete or archive mail off-IMAP the moment there is no action. Combine your off-IMAP archive with notmuch, mairix, mu, or some other indexer so you can quickly find what you need in your vast archives. -Andrew
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Sun, Jan 24, 2021 at 08:40:25PM -0800, Felix Finch wrote: On 20210124, boB Stepp wrote: 1) Mutt erratically loses connection with Gmail and I have to manually reconnect. Sometimes this happens rather frequently as in multiple instances within an hour. I am confident it is not my Internet connection, which is normally quite stable and fast. For instance my streaming music is never interrupted, the family's TV shows continue unimpeded, etc., but my connectivity to Gmail is interrupted randomly. If I have both Mutt and the web interface open, Mutt has its interruptions while the Gmail web interface appears to be updating normally. I had this problem after my ex-employer switched to a Lookout mail system. Sometimes mutt would stay connected for several days, then disconnect within seconds or minutes on every re-open until I gave up and waited an hour or two before connecting again, stable for hours. This was a pretty constant pattern for several years for various versions of both mutt and neomutt under Ubunto 18.04 and 20.04. I have been experimenting. I wondered if I went to a more recent version of Mutt if any of my issues would go away, particularly this one. I don't have much experience with snap packages, but found that they had Mutt 2.0.3 available, so I gave it a go. After two days of use this issue did not happen. Nor did the issue of read Gmail messages being displayed as unread rear its head. But the snap package is a confined snap, which led to a bunch of irritations since I could not escape from its confines to do "normal" things. Research did not reveal any workarounds, so I searched for an "easy" way to get the latest, greatest Mutt, v. 2.0.5. Heavy sigh. Compiling from source seemed to be the only way. I tried this once before with mixed results. Cameron was right! It gets easier with practice. I now have Mutt 2.0.5 successfully running. And so far things seem to be working very well indeed! Still looking into how to best handle some of these html emails, but I think I now have that nuked out, too. Thanks to everyone that offered suggestions! -- Wishing you only the best, boB Stepp
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Sun, Jan 24, 2021 at 11:46 PM ಚಿರಾಗ್ ನಟರಾಜ್ wrote: > I wrote up a blog post a while back on dealing with multiple inboxes in Mutt > (in fact, I'm writing this from Mutt and sending it through ProtonMail, so it > *is* possible!): > https://chiraag.me/blog/2019/08/21/managing-multiple-email-accounts-with-mutt-and-fetchmail/ > > My setup involves two moving parts (mutt and fetchmail+getmail_maildir), but > I have never run into this issue. However, because fetchmail uses the unread > status as a flag of which emails to fetch, all downloaded emails are marked > as 'read' on the server, which can make things a bit annoying. Possibly > another mail retrieval agent (like getmail, for example) would solve that > issue. This will be helpful once I attempt to transition to ProtonMail. Thanks! boB Stepp
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Mon, Jan 25, 2021 at 09:07:29PM +1100, Cameron Simpson wrote: > On 24Jan2021 22:04, boB Stepp wrote: > >5) I am able to view HTML emails via w3c, but I get weekly (and some > >daily) emails from news aggregation services like Pycoders Weekly, > >TLDR, etc., that have embedded links that never show up in the w3c > >display. > > I'm using "lynx -stdin -dump"; you could see if that is better rendered. > It tends to fill things in as a footnote style, with the link text > followed by, say, "[1]" and at the bottom a: > > [1] https://url/here > > >If I find I want to view an interesting article I have to > >fire up the Gmail interface and click on it there. I have not been > >able to resolve this one and it is quite annoying to seemingly have to > >leave Mutt to access these articles in my browser. > > My terminal emulator (iTerm on a Mac) highlights URLs and lets me click > on them; that pops up the URL in my web browser directly. Maybe your > terminal emulator has such a feature? Otherwise there's the traditional > copy/paste provided the URLs is visible in the terminal. > > Also, if w3m or lynx is better for some article you could maybe switch > depending on where the article came from or something. That's getting > pretty fiddly. There's also pandoc; you could use "pandoc -f html -t > plain" and see what sort of rendering it does. > > Cheers, > Cameron Simpson I do it this way (under Ubuntu): In .mailcap I have text/html; store_html %s; needsterminal; copiousoutput; and the script store_html contains: : SAVE=/tmp/elinks_save.html cp $1 $SAVE elinks -dump -dump-charset UTF-8 -default-mime-type text/html $SAVE opera file://$SAVE exit 0 Now, when I select a message in html-format, I see it immediately in the browser. Best, ulrich
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On 24Jan2021 22:04, boB Stepp wrote: >5) I am able to view HTML emails via w3c, but I get weekly (and some >daily) emails from news aggregation services like Pycoders Weekly, >TLDR, etc., that have embedded links that never show up in the w3c >display. I'm using "lynx -stdin -dump"; you could see if that is better rendered. It tends to fill things in as a footnote style, with the link text followed by, say, "[1]" and at the bottom a: [1] https://url/here >If I find I want to view an interesting article I have to >fire up the Gmail interface and click on it there. I have not been >able to resolve this one and it is quite annoying to seemingly have to >leave Mutt to access these articles in my browser. My terminal emulator (iTerm on a Mac) highlights URLs and lets me click on them; that pops up the URL in my web browser directly. Maybe your terminal emulator has such a feature? Otherwise there's the traditional copy/paste provided the URLs is visible in the terminal. Also, if w3m or lynx is better for some article you could maybe switch depending on where the article came from or something. That's getting pretty fiddly. There's also pandoc; you could use "pandoc -f html -t plain" and see what sort of rendering it does. Cheers, Cameron Simpson
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
Hi boB, I wrote up a blog post a while back on dealing with multiple inboxes in Mutt (in fact, I'm writing this from Mutt and sending it through ProtonMail, so it *is* possible!): https://chiraag.me/blog/2019/08/21/managing-multiple-email-accounts-with-mutt-and-fetchmail/ My setup involves two moving parts (mutt and fetchmail+getmail_maildir), but I have never run into this issue. However, because fetchmail uses the unread status as a flag of which emails to fetch, all downloaded emails are marked as 'read' on the server, which can make things a bit annoying. Possibly another mail retrieval agent (like getmail, for example) would solve that issue. HTH! - Chiraag -- ಚಿರಾಗ್ ನಟರಾಜ್ Pronouns: he/him/his publickey - mailinglist@chiraag.me - b0c8d720.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On 20210124, boB Stepp wrote: 1) Mutt erratically loses connection with Gmail and I have to manually reconnect. Sometimes this happens rather frequently as in multiple instances within an hour. I am confident it is not my Internet connection, which is normally quite stable and fast. For instance my streaming music is never interrupted, the family's TV shows continue unimpeded, etc., but my connectivity to Gmail is interrupted randomly. If I have both Mutt and the web interface open, Mutt has its interruptions while the Gmail web interface appears to be updating normally. I had this problem after my ex-employer switched to a Lookout mail system. Sometimes mutt would stay connected for several days, then disconnect within seconds or minutes on every re-open until I gave up and waited an hour or two before connecting again, stable for hours. This was a pretty constant pattern for several years for various versions of both mutt and neomutt under Ubunto 18.04 and 20.04. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman & wood chipper / fe...@crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o
