BUG: mhshow dumps core with bad content-type field

hi -- this may be fixed already, though i'm running nmh-1.1.

mhshow dumps core on the following headers (shifted right one space
for clarity):

 Subject: foo
 From: bar
 To: addressees
 Content-Type: text/plain; charset=
 Content-Transfer-Encoding: quoted-printable

note the missing "charset" value.

in contrast, the following header does not dump core, but
simply gives an appropriate error message:

 To: addressee
 Subject: some text
 Content-Type: text/plain; charset=
 From: someone

i don't know if i'll be able to look at this, but someone who's
in the mhshow guts might keep it in mind.

paul
=---------------------
 paul fox, pgf <at> foxharp.boston.ma.us (arlington, ma, where it's 22.5 degrees)

_______________________________________________
Nmh-workers mailing list

[Q] mhshow bug

I'm trying to modify my mhl.headers file so that show(1) and mhshow(1) simply
do not list any headers except the default ones:

Date:
To:
cc:
From:
Subject:

In exmh it works fine but at the terminal there's a problem.

$ mhlist 321
 msg part  type/subtype              size description                         
 321       multipart/mixed            10K
     1     text/plain                 566
     2     message/rfc822              9K

The initial message (part 0) only lists the five headers above; that's what I
want.  But when mhshow goes on to list part 2 (another rfc822 msg), those five
are shown as well as all the "extras" such as:

Return-path
Reply-to
MIME-version
X-Mailer
Content-MD5

I don't care about those extra fields and I'm not sure why mhshow shows them
for the embedded rfc message when it didn't show them for the first part.

Braindump: Extended MH Format

I posted this as my ~/.plan file on my website... my crappy
web-log-ish-thing.  I highly doubt anything I have to say is new, but it
helped me form my opinion about Maildir, that it's not really worth the
attention it's getting.

    http://wookimus.net/~chewie

After a long-winded examination of all things mail format, I conclude
with this little idea (again, probably not new):

    If the only compelling reason to switch to Maildir from MH is the
    file locking semantics, why not fix MH? Rather than storing index
    data as the file names themselves, why not leave it up to the email
    client or IMAP server to store sequences in meta-data files? Perhaps
    as an additional field in .mh_context or a separate file. Generate
    the file name with something like libuuid to create a "Universally
    Unique Id", either time-based or completely random. dot-files are
    metadata, files are email (perhaps with a ".msg" or ".mh" suffix),
    and directories are folders.  Simple. Let's call it "Extended MH
    Format".

Any merit to this idea?  I understand it would change the way sequences
would need to be handled, but we could hide that in a library call.  The
command-line utilities don't need to change the way they reference an
email.

(Pardon my use of mutt... *grin*)

--

-- 
Chad Walstrom <chewie <at> wookimus.net>           http://www.wookimus.net/

Re: Braindump: Extended MH Format

Chad Walstrom wrote:
>I posted this as my ~/.plan file on my website... my crappy
>web-log-ish-thing.  I highly doubt anything I have to say is new, but it
>helped me form my opinion about Maildir, that it's not really worth the
>attention it's getting.

While I'm not necessarily a fan of maildir, it does have some nice
locking semantics (and locking that works over NFS is a Hard Problem).

>    If the only compelling reason to switch to Maildir from MH is the
>    file locking semantics, why not fix MH? Rather than storing index
>    data as the file names themselves, why not leave it up to the email
>    client or IMAP server to store sequences in meta-data files? Perhaps
>    as an additional field in .mh_context or a separate file.

If you're going to change format, it might be nice to have something
with a separate overview index. I played around with adding threading
support to nmh a while ago but the trouble is that you wind up having
to read all the messages concerned to build up the thread tree before
you can start doing things, so "scan -threaded last:100" feels far
too slow... (GNUS already has a format like this, which it calls nnml,
which is nmh with a .overview file containing some headers from each
message. I haven't actually looked at the implementation, though.)

>Any merit to this idea?  I understand it would change the way sequences
>would need to be handled, but we could hide that in a library call.  The
>command-line utilities don't need to change the way they reference an
>email.

It makes it harder to do things like 'grep foo ~/Mail/inbox/3???', of

Re: Braindump: Extended MH Format

pmaydell <at> chiark.greenend.org.uk wrote:
> While I'm not necessarily a fan of maildir, it does have some nice
> locking semantics (and locking that works over NFS is a Hard Problem).

*nod*

> If you're going to change format, it might be nice to have something
> with a separate overview index.

Perhaps that's part of the key solution.  This type of meta-data is more
about helping the client be quicker at finding things.  I understand the
benefits of having standards so that all clients are on a level playing
field.  In any case, standardizing a way to create custom indexes that
don't rely upon the file name might be an useful step forward.
Obviously, you don't want to REQUIRE clients to update the file if it
works out better to have their own indexing mechanisms.  Sylpheed
doesn't rely upon .mh_sequences,GNUS' .overview files, or .xmhcache
files.

Note: my bad with regards to the non-existent .mh_context.  I meant to
refer to .mh_sequences. (I fixed this on my .plan file.)

If you re-sort the folder, the .mh_sequences file currently needs to be
updated anyway to reflect the change, right?  Well, rather than using
the index number to indicate members of a sequence, perhaps include the
actual file names and let the command line utilities enumerate the list.
The paradigm shifts from referencing the email name as the index itself
to referencing its enumerated index of the sequence.  We'ld have to give
mhpath a switch for specifying which sequence to use:

Re: Braindump: Extended MH Format

there is a school of thought that says if you have a *fast* full-text
database with good wild-carding, you just dump the message into
the full-text database and then what we call sequences and folders
become "views" of the database.  in a system like Plan 9 that
could even be elegant.

	-mo

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: Braindump: Extended MH Format

Chad Walstrom wrote:
> If we're no longer using filename for sort order, the server and
> client won't loose track of internal tracking indexes for seen and
> unseen might be building (not using .mh_sequences).

Wow, how's that for editing discontinuity?!  It should read, "...the
server and client won't lose track of seen and unseen messages as it
might be caching internally (not using .mh_sequences)"

--

-- 
Chad Walstrom <chewie <at> wookimus.net>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: Braindump: Extended MH Format

--- Chad Walstrom <chewie <at> wookimus.net> wrote:
> Let's call it "Extended MH Format".
> 
> Any merit to this idea?  I understand it would change the way
> sequences would need to be handled, but we could hide that in
> a library call.  The
> command-line utilities don't need to change the way they reference an
> email.

I'm traveling, so I haven't read the discussion in detail.  My main
concern about these changes is that a fair number of users still access
MH files and data structures directly -- that is, not through a
command-line utility.

Users who come from other MUAs -- where all of the internal data
structures and etc. are either impossible to parse or too difficult to
make it worth the work  -- may think that the sort of thing MH lets
us do is sort of pointless.  IMO, that may be because they haven't
learned how handy it is to be able to muck around and access email and
its metadata directly.  They may say that because some of the
structures aren't thoroughly documented, that no one should be
depending on them -- and should only use the CLI tools for access. 
Valid point, but MH does have long years of history...

I'm not saying that MH doesn't have problems in locking and some other
areas.  I'm just saying that this feels like a *major* change to me, an
old-timey MH user.  I hope that the implications will be discussed
thoroughly before anyone does too much coding.  MH/nmh is unique, and I
hope we'll do what we can to keep its useful parts as we (thanks,
Chad!) try to solve the outstanding problems.

Re: Braindump: Extended MH Format

Chad Walstrom wrote:
>Obviously, you don't want to REQUIRE clients to update the file if it
>works out better to have their own indexing mechanisms.  Sylpheed
>doesn't rely upon .mh_sequences,GNUS' .overview files, or .xmhcache
>files.

Um. If you don't require everybody to keep the index in step then there's
no point, because an index-aware client can't rely on the index being
in sync with the actual data.

Snip various. I'm afraid I've lost track of what the actual problem
you're trying to solve is; can you reexplain, please?

>> (GNUS already has a format like this, which it calls nnml, which is
>> nmh with a .overview file containing some headers from each message. I
>> haven't actually looked at the implementation, though.)
>
>Might be a good place to start.
>
>> It makes it harder to do things like 'grep foo ~/Mail/inbox/3???', of
>> course...

>    $ sed -ne '3000,3999p' ~/Mail/inbox/sequence.all | xargs -r grep foo

Er, that's harder 

>Again, my bad since we're probably referring to .mh_sequence rather than
>.mh_context.  Besides, how many IMAP servers do you know of that
>currently care about .mh_sequences?

Re: Braindump: Extended MH Format

pmaydell <at> chiark.greenend.org.uk wrote:
> Snip various. I'm afraid I've lost track of what the actual problem
> you're trying to solve is; can you reexplain, please?

I did forewarn you with the subject titled, "Braindump".  In any case,
the ideas that spewed out on to this list originated from trying to
incorporate some safer locking mechanisms for MH mail and preventing
IMAP servers (or clients) from loosing track of the emails in the
filesystem because of a folder re-sort, regardless of whether they
participate in using common meta-data files.

OK, just to bring RFC 2060 [2.3.1.1. Unique Identifier (UID) Message
Attribute]into discussion:

    Note: Unique identifiers MUST be strictly ascending in the mailbox
    at all times.  If the physical message store is re-ordered by a
    non-IMAP agent, this requires that the unique identifiers in the
    mailbox be regenerated,...

shell$ sortm -textfield subject -limit 4 +inbox 

    ...since the former unique identifers are no longer strictly
    ascending as a result of the re-ordering.  Another instance in which
    unique identifiers are regenerated is if the message store has no
    mechanism to store unique identifiers.  Although this specification
    recognizes that this may be unavoidable in certain server
    environments, it STRONGLY ENCOURAGES message store implementation
    techniques that avoid this problem.

Basically, the IMAP server needs to detect new emails and assign them