> I wouldn't bother searching any further -- mailbox formats are generally
> (and IMO wrongly) regarded as outside the scope of RFCs and suchlike.
> ...
> I certainly agree that it should be documented, however.
qmail sites usually document quite particular. Their mbox(5) page speaks
of formats: m
>> mutt didn't need that header to operate well in the original folder.
>> In general, can't think of any reason to modify any Maildir message on disk
>> and view this as tainting the msgs with unecessary and un-asked-for mods.
>
> well, they don't really hurt, but may even help mutt and other too
I'm using Maildir.
mutt -R against folder A makes no mods as expected.
mutt -f against folder A moves new msgs to cur with no mods as expected.
But mutt -f against A, operation of tagging messages and 'C'opying
them to some other folder B causes Content-Length headers to be
added to each message.
>>> Why, when supplying 'LDFLAGS=-static' do these change
>>> from yes, to no?
>>>
>>> > checking for idna_to_unicode_8z8z... no
>>> > checking for idna_to_ascii_8z... no
>>> > checking for idna_to_ascii_lz... no
>>
>> I can only guess, but my guess is there's no static version of those
>> librarie
Why, when supplying 'LDFLAGS=-static' do these change
from yes, to no?
FreeBSD 8.3 i386
1.5.21hg
< checking for idna_to_unicode_8z8z... yes
> checking for idna_to_unicode_8z8z... no
< checking for idna_to_ascii_8z... yes
< checking for idna_to_ascii_lz... yes
> checking for idna_to_ascii_8z... n
> better tools. I've been here for nearly 15 years, and the arguments
Or maybe I've been here for over 20 and am forgetting this same wisdom
I already learned and am beginning to lose the good fight against the Borg.
EOF
> assume he's got a reason for wanting it
Maybe I'm lazy [2], or temporarily stuck in a crappy UI,
or to make the list friendlier to potential converts from Bill's
land of the GUI, or any number of things.
> I'm a sysadmin.
Or maybe I want to give those of us admins [1] who've mastered
filtering
Few things are 'absolute', trade offs are often involved.
Just as I might suggest maildrop over procmail, others
might suggest bashing their mail over the server wire,
or sieving it, instead of downloading it and filtering it locally.
As an occaisional subscriber with filter in hand, I recuse mysel
If at all possible I'd like to see the Subject: line for this list
updated from...
Subject: ...thread...
...to...
Subject: [mutt-users] ...thread...
I'm aware mail filters are readily available to some.
I'm suggesting it because the prefixed subject line model is very prevalent
these days, particu
>> I'm looking through the manual and I'm not seeing where I can:
>>
>> 1) Specify, in the fixed muttrc configuration, a sha1 certificate
>> fingerprint that must match on a per host basis before continuing
>> with the connection.
>
> This is not supported directly, but here is what you can do:
>
>
I'm looking through the manual and I'm not seeing where I can:
1) Specify, in the fixed muttrc configuration, a sha1 certificate
fingerprint that must match on a per host basis before continuing
with the connection.
2) Additionally, and optionally, validate the cert presented by any
ssl/tls (or s
11 matches
Mail list logo
