Re: [OT-ish] Want command line program to selectively delete emails

2023-09-17 Thread Sean Greenslade
On Mon, Aug 07, 2023 at 01:57:04AM +1000, Nemo Thorx wrote:
> Quoting Ed Blackman from 04 Aug (a Friday in 2023) at 1434 hours...
> > Any suggestions for a command line program to select emails for
> > deletion based on command line options?  I specifically want one that
> > can remove emails that were received more than X days ago, but can
> > also express "but don't delete if they're flagged".
> 
> 
> 
> > I could call mutt (see, kinda OT!) with "-e" to tag, delete, sync, and
> > quit, but that seems fiddly and heavyweight.
> 
> But if it's being run from cron overnight or something, are you ever
> going to notice? 
> 
> > I could give up on using the message headers to determine the message
> > date, learn how filenames are constructed in Maildir (to read the
> > flags) and use a shell script built around "find".
> 
> I'm reasonably confident that all filenames (before the ':') are only
> convention (I convert an nntp spool to maildir and name them according
> to my own naming convention which everything (well, mutt and dovecot)
> then honours), and mtime is unused by anything and/or not to be trusted. 
> 
> So honetsly, I'd suggest mutt's -e, since it gives you mutt's pattern
> matching which is much more powerful than archivemail (admittedly,
> I only used that for trivial stuff and only many years ago) and likely
> more than anything else available. 
> 
> eg, instead of just "received more than X days ago and not flagged",
> mutt can let you select/ignore whole threads based on those parameters,
> and others alike. eg, I once had archiving setup on a folder-hook thus: 
> 
> folder-hook !(Maildir$|archive|search|mfolder|.r.) 'push 
> "t~m 600- !~(~m -600) !~(~r <32d) !~(~N) !~(~F) 
> !~D^.archivet"'
> 
> To decode that: sort reverse threaded, select all messages after the
> first 600, but not if it's part of a thread within the first 600, not if
> it's in a thread with messages received in the last 32 days, not if it's
> in a thread with messages marked 'New' or 'Flagged', and not if it's
> a message already marked delete. Then save to the archive mailbox and
> established my desired sorting and thread collapse visibility. 
> 
> Basically - I wanted a thread-preserving archiving mechanism, and mutt's
> thread-aware pattern matching gave it to me. (I didn't include sync in
> that setup, preferring at the time to let that occur with mailbox
> closing)
> 
> In a delete scenario as you're seeking, I'd suggest a multi-step process
> which first archives threads you've contributed to - and only then
> deleting old ignorable threads. 
> 
> Sure It's fiddly - which is your argument against using mutt.
> 
> ...But it's powerful - which is my argument for using mutt!
> 
> Aside - I used folder-hook before because I didn't know of the "-e"
> option, and I stopped using it because I found I was often using mutt as
> a mailbox debug tool, and this was just getting in the way. I can see
> myself going down the rabbithole and reimplementing my old archiver now
> (where "now" is "sometime in the next few months, maybe" :)

Another very late reply to this thread, but I happen to have implemented
almost exactly the concept you're describing. It's a python3 script that
deletes whole threads that meet the criteria:
- All messages are markes as read
- No messages in the thread are unread
- No messages in the thread are flagged (starred)
- All messages in the thread are older than N days

It's been several years since I've looked at this code (which in my mind
is a good thing, since that means it hasn't broken), so definitely give
it a read-over to see if it's suitable for your purposes. In my case, I
run it directly on the mail server via a systemd service and timer.

https://seangreenslade.com/source-code/scripts/list-thread-pruner/listthreadpruner-v0.1.py

Happy to answer any questions about the code if anyone is curious or
wants to use it.

--Sean



Re: trouble with sending emails from alternate email account

2022-02-15 Thread Sean Greenslade
On February 12, 2022 9:58:50 PM PST, Ranjan Maitra  wrote:
>Hi,
>
>I am using the browser (sorry) to send this e-mail because I am no
>longer able to send email from mutt from anything other than my office
>account (which uses smtp and is delivered via postfix). 
>
>So, here is what I have in my .muttrc at the very end.
>
>
>folder-hook .  'unset smtp_url'
>folder-hook '(mutt|R|fedora|postfix|fetchmail|openbox|sylpheed)' 'set
>from = t...@email.com; set
>smtp_url="smtps://t...@email.com@smtp.mail.com:465/"; set
>smtp_pass="xxx"; set envelope_from_address="t...@email.com";
>set use_envelope_from=yes; set from = "t...@email.com"; set
>forward_format = "[FW frm %a:%s]"; set realname = ""; my_hdr Bcc: "";
>set ssl_force_tls = yes; set ssl_starttls = yes'
>
> 
>
>The password is correctly entered (and this configuration worked fine,
>in the sense that it delivered email from this account a few weeks ago.
>This has not worked for a few weeks and I finally decided to try and
>see if anyone had suggestions. 
>
> 
>
>I am on Mutt 2.1.5 and on a full up to date Fedora 35.
>
> 
>
>I tried debugging and get.
>
> 
>
>2022-02-12 23:18:26] External SSF: 256
>[2022-02-12 23:18:26] External authentication name: t...@email.com
>[2022-02-12 23:18:26] mutt_sasl_cb_authname: getting authname for
>smtp.mail.com:465
>[2022-02-12 23:18:26] mutt_sasl_cb_authname: getting user for
>smtp.mail.com:465
>[2022-02-12 23:18:26] mutt_sasl_cb_pass: getting password for
>mai...@email.com@smtp.mail.com:465
>[2022-02-12 23:18:26] Authenticating (PLAIN)...
>[2022-02-12 23:18:26] 5> AUTH PLAIN (removed)
>[2022-02-12 23:18:27] 5< 535 Authentication credentials invalid
>[2022-02-12 23:18:27] 5< 535 Authentication credentials invalid

One possibility is that your email provider may have disabled normal password 
auth. I know that both Office365 and GSuite offer a setting to enable or 
disable using your account password for authentication, with the desired 
alternative being oauth. I don't remember offhand if there is a way to use 
oauth with mutt, but these providers will often provide an "app-specific 
password" mechanism as an alternative.

Another thought is to switch to the submission port 587 if the provider offers 
it. Based on your error messages I doubt it's the issue, but it does provide a 
small security boost by removing the possibility of STARTTLS stripping attacks.

--Sean




Re: Creating HTML emails with mutt

2019-10-30 Thread Sean Greenslade
On October 30, 2019 7:41:34 AM PDT, Patrick Shanahan  wrote:
>* Sean Greenslade  [10-30-19 10:37]:
>> On October 30, 2019 5:29:01 AM PDT, Patrick Shanahan
> wrote:
>> >* Mark H. Wood  [10-30-19 08:26]:
>> >> On Wed, Oct 30, 2019 at 11:37:43PM +1300, martin f krafft wrote:
>> >> >I'd love to see some statistics about the age of mutt users.
>> >> 
>> >> 62
>> >
>> >78
>> 
>> Not sure if these are guesses at the average or reported data points.
>If
>> it's the latter, I'll offer my own:
>> 
>> 26
>
>since the request was rather non-specific and limited to only those
>interested in reading the thread, not sure it makes any difference. 
>almost like polling results related by politicians.

Of course there's massive selection bias in this list. No question about that. 
I just wanted to point out that there definitely are some younger Mutters out 
there. Though I tend to fall more on the grumpy about HTML mails side of this 
argument, so maybe age isn't that relevant.

--Sean



Re: Creating HTML emails with mutt

2019-10-30 Thread Sean Greenslade
On October 30, 2019 5:29:01 AM PDT, Patrick Shanahan  wrote:
>* Mark H. Wood  [10-30-19 08:26]:
>> On Wed, Oct 30, 2019 at 11:37:43PM +1300, martin f krafft wrote:
>> >I'd love to see some statistics about the age of mutt users.
>> 
>> 62
>
>78

Not sure if these are guesses at the average or reported data points. If it's 
the latter, I'll offer my own:

26

--Sean