Re: mhonarc next release

1996-01-03 16:32:33
    1) message date and received header: As you could in this message
       Digital Unix sendmail places the date into
       (split(';',$received))[2] and not into 
       (split(';',$received))[1] as expected by mhonarc. My brute
       force patch appended below loops over the splice [1...2]
       to get the date. This patch fixes also the problem that
       if no date could be found in the received header then the date
       header is scanned. The current version assumes that the date
       could always be found/identified if received header is present.

The current version will look in the date field if no received fields
exist.  I guess it is not robust enough in dealing with non-standard
date specifications.  Ie.  It thinks it has a date, but it is
screwed up.

BTW, the whole date thing is ugly.  The rfcs have specified a date
format, but there are still implementations that do not follow them.

    2) The 'From ' header on an mbox is not an true header, it's

I know.

       the envelope address. I think mhonarc should ignore it
       or convert it into the 'Return-Path:' header as mh does
       (mhs compile option RPATH). In this case mbox and mh mails
       would be the same.

I assume you are talling about piped in messages, because mhonarc
does ignore "From " lines in mailbox files.  Technically, in piped
mode, mhonarc expects a rfc 822/1521 message.  The "From " line
is illegal.  I'll probably just modify the code to ignore lines
that do not conform to the rfcs.

    3) The default for the end of the thread index and bydate index
       are different. bydate gets


      o Some time ago you send me a stricter version of $FROM
          for mbox files. Could you make this the default? It
          would save a lot of time for people with wrong configured
        tools that don't escape the 'From ' in message bodies.

I'll probably mention the stricter form in the documentation.
It is possible that the stricter form I mentioned mail fail
under some MUAs.

      o Add an -listname option. This is useful for the index
        titles and URL 'button':

        mhonarc -listname FooBar

          gives the (new default?) title: FooBar Mail Index
                                          FooBar Mail Thread Index

          and button: [FooBar Index] and [FooBar Thread]

You can achive this effect with the -title, -ttitle, and other
resources.  I will not bother with -listname since the same effect
can be achieved by other means and there are plenty of other todo
items that are more important.

       o An option that allows that <LISTEND> <TFOOT> are only
         displayed if more that a given number of messages are
         in the archive. Mabe another index element name would
         be better. See the (modified) mhonarc archive as an
         example where an button row at the end of the list is
         not useful because there are to less messages.

Interesting idea.

       o Message customization: it would be nice if the buttons before
         the subject are full customizable as the footer and head of
         a message. 

I too would like full button customization.  This can cause some
compatibility problems, so I've delayed on implementing it.

 >    o Add to the documentation/WWW home page how to add a References:
 >           header (if possible at all with the MUA).
 >      I suggest using mh :-). For mh I use in replcomp:
 > ...
 > %<{message-id}References: \
 > %<{references}%(void{references})%(trim)%(putstr) %>
 >             %(void{message-id})%(trim)%(putstr)\n%>\
 > ...
 >      If not don't work as expected when there no References header
 >           present. Better Solution?
       Yeah :-). This handles a missing References: header better:

%<{message-id}References: \
%<{references}%(void{references})%(trim)%(putstr)\n            %>\
       Want is still missing: If no References: header is present
       try to extract the message id for the In-Reply-To: header.
       A fix would be welcome :-)

mhonarc already does this.  It checks the References and In-Reply-To

    o Possibility that error messages are send as email when mhonarc
      is used with a .forward file

    o X-face: header and PIcons (formerly faces database) support

Don't want much :-)  I'm not familiar with this.

         o Don't use the main package for mhonarc. Start mhonarc
             with (or something like that)

              package mhonarc;

             This is basic requirement to patch mhonarc to be used as a
           standalone script or a library call. (It's useful because
           I call mhonarc from other perl scripts several times).

Another release.  This will effect the filters and any user written


<Prev in Thread] Current Thread [Next in Thread>