Re: Folders do not display in SideBar

[Philip Rhoades]

Akshay,


On 2022-03-06 13:25, Akshay Hegde wrote:

On 2022-03-06 13:09 +1100, Philip Rhoades wrote:



Adding mailboxes like that would not be viable - I have:

  705 primary Maildir folders

and:

  2,708 total Maildir folders

- and they are constantly changing - Mutt needs to autodetect ALL the
current folders somehow . .

Thanks,

Phil.


Well, you don't necessarily have to list them manually (although that's
what I do since I only have a few).

There are some tricks you can use to build them dynamically such as
these:
https://gitlab.com/muttmua/mutt/-/wikis/ConfigTricks#building-a-list-of-mailboxes-on-the-fly



Thanks!  I will have a look at that.

P.
--
Philip Rhoades

PO Box 896
Cowra  NSW  2794
Australia
E-mail:  p...@pricom.com.au

Re: vs. / vs.

[Will Yardley]

On Thu, Mar 24, 2022 at 11:43:46AM +1100, raf wrote:
> On Wed, Mar 23, 2022 at 06:23:19PM -0400, Kurt Hackenberg  
> wrote:
 
> > Procmail is badly outdated,
> 
> I might be the only person that thinks this, but...
> 
> If it's still in use and still usable, it's not "outdated".
> It's just "stable". :-)

You're not the only one.

w

Re: vs. / vs.

[raf]

On Wed, Mar 23, 2022 at 06:23:19PM -0400, Kurt Hackenberg  
wrote:

> Procmail is badly outdated,

I might be the only person that thinks this, but...

If it's still in use and still usable, it's not "outdated".
It's just "stable". :-)

> and it's a zombie, unmaintained for many years.

And yet, Linux distributions (and presumably OpenBSD)
manage to apply security patches and keep it compiling
on modern systems. That counts as maintenance to me.
It just isn't developed anymore.

> I suggest that you consider some other delivery agent.
> The program fdm looks promising, though I haven't used it.
> 
> Here's a Wikipedia article.
> 

Sieve might be another good one to look at. But I haven't
used it.

cheers,
raf

Re: vs. / vs.

[Kurt Hackenberg]

On 2022/03/23 17:29, Cameron Simpson wrote:


On 23Mar2022 15:01, Jon Brinkmann  wrote:

I'm working to extract the original message and send it back through
procmail
to be properly sorted into my mailboxes.  I've mapped this process to the
'E' key:

macro index E '5procmail;tail 
procmail.log' 'extract & process a message that Microsoft Exchange called undeliverable'

It works great, with one problem:  doesn't pass the mailbox
delimiting "From [email_address] [message_date]" to procmail, which sorts and
writes what it received to a file that's not recognized as a mailbox by mutt.
Is there some way to tell  to pass the delimiter line?  If not,
should this be a code change request?


Well, the poblem here is that the From_ line is not part of the message
itself, and won't be present in the attachment you have.

I'd be inventing one - it is broadly ignored by mail filters etc (again,
not being part of the message), so you just need a valid one to work as
the mbox delimiter line. Maybe something like this:

 ( echo "From nobody `date`"; cat ) | procmail


That might work, but it's not ideal.

The From_ line is part of mbox file format, a way to store multiple 
messages in a single file. Ideally, the From_ line should not exist 
anywhere but in an mbox file.


I would expect procmail to generate the From_ line and the other things 
that mbox format needs. If it can't do that, I'd call that a bug.


Procmail is badly outdated, and it's a zombie, unmaintained for many 
years. I suggest that you consider some other delivery agent. The 
program fdm looks promising, though I haven't used it.


Here's a Wikipedia article.

Re: vs. / vs.

[Cameron Simpson]

On 23Mar2022 15:01, Jon Brinkmann  wrote:
>I'm working to extract the original message and send it back through 
>procmail
>to be properly sorted into my mailboxes.  I've mapped this process to the
>'E' key:
>
>macro index E '5procmail;tail 
>procmail.log' 'extract & process a message that Microsoft Exchange 
>called undeliverable'
>
>It works great, with one problem:  doesn't pass the mailbox
>delimiting "From [email_address] [message_date]" to procmail, which sorts and
>writes what it received to a file that's not recognized as a mailbox by mutt.
>Is there some way to tell  to pass the delimiter line?  If not,
>should this be a code change request?

Well, the poblem here is that the From_ line is not part of the message 
itself, and won't be present in the attachment you have.

I'd be inventing one - it is broadly ignored by mail filters etc (again, 
not being part of the message), so you just need a valid one to work as 
the mbox delimiter line. Maybe something like this:

( echo "From nobody `date`"; cat ) | procmail

>FYI, it appears that  and  are identical.  At
>least they produce identical results.

The name distinction might be historic, one being from the top level 
(index) and one being from the attachment menu? Just guessing.

Cheers,
Cameron Simpson 

vs. / vs.

[Jon Brinkmann]

First the background:

I'm forced to use a Microsoft Exchange server for my email.  It's configured
(not by me) to tag SPF incorrectly authorized and other suspect messages
as "Undeliverable". It always attaches the original message with the full
original header as attachment 5.  Here's what the "v" command shows for a
typical message:

I   1   [multipa/alternativ, 7bit, nK]
I   2   [text/plain, quoted, us-ascii, nK]
I   3   [text/html, quoted, us-ascii, nK]
I   4   [message/delivery-s, 7bit, nK]
I   5 [message/rfc822, 7bit, nK]
I   6   [multipa/alternativ, 7bit, nK]
I   7   [text/plain, quoted, iso-8859-1, nK]
I   8   [text/html, quoted, iso-8859-1, nK]

I'm working to extract the original message and send it back through procmail
to be properly sorted into my mailboxes.  I've mapped this process to the
'E' key:

macro index E '5procmail;tail 
procmail.log' 'extract & process a message that Microsoft Exchange 
called undeliverable'

It works great, with one problem:  doesn't pass the mailbox
delimiting "From [email_address] [message_date]" to procmail, which sorts and
writes what it received to a file that's not recognized as a mailbox by mutt.
Is there some way to tell  to pass the delimiter line?  If not,
should this be a code change request?

FYI, it appears that  and  are identical.  At
least they produce identical results.

I could work around the problem by using  (and it appears
that  and  are also identical) which does pass
the delimiter line.  I'd have to save the attachment to a temporary file,
redirect it to procmail and then delete the file.  I'd prefer not to do this
if possible.

I also realize that  is a simpler operation than .
The latter has to deal with, among other things, a pre-existing file with
older messages, file locking, etc.

Thanks,

Jon