On December 17, 2002 at 02:11, Tomasz Ostrowski wrote: > > > I needed to archive sent mail with MHonArc and I needed to put > > > contents of To: header to mesage index. It was not possible with > > > MHonArc-2.5.13 so I wrote a small patch that added rc-variable $TO$. > > > > The preferable method is to allow for arbitrary message header > > variables instead of just To:. Otherwise, you end up replicating > > code when people want 'cc' or other fields. > > Of course. But to make it right you have to had a lot of time and > know a language you work with rather well. Lacking both of it I > choose the ugly one.
Side note: You should check out the mha-preview program in the examples/ directory of the distribution as an example on how to add in support for "To:" without making changes to the base MHonArc code itself. > I just hope somebody will pick up this and make it the right way. I > just think this is better than nothing. I'm the person to pick up most things. I'll see about getting something done for v2.6.0. Since you are on the dev list, you can monitor the CVS commit messages to see when it shows up. Of course, contributions to the author always speed up the development of certain features :-) > > > 2. Attachmants with non-ascii names > > > > > > I had problems with accessing attachments extracted with MHonArc from > > > Windows if they had non-ascii characters in name or characters > > > forbidden for file names: \/:*?"<>| (when using m2h_external::filter; > > > usename). > > > > Probably more efficient would be just exclude whitespace and non-ascii > > characters in one tr// operation: > > > > $fname =~ tr/\0-\40\t\n\r\177-\377/_/; > > I think characters mentioned earlier, not allowed in Windows > environment, should also not be used in filenames. I don't know if > MHonArc allows '/' or '\' in filenames but at least these cound make > directory traversal vunerabilities possible. / and \ are handled beforehand by the caller. readmail::MAILget_content_disposition removes any pathname components for security reasons. You're right about the other ones (at least for Windows). It is easy to add them in the tr/// operator. > > As for the un-grepable utf-8, I think people will eventually have > > to dealing with it if they want to have archives that are > > multi-lingual. > > I think one chosen by configuration iso character set plus numeric > unicode entities for undisplayable in it characters would be perfect > solution. This already exists in the snapshot builds. MHonArc::CharEnt has been enhanced to handle many more character sets (including multibyte sets like Japanese and Chinese), and all SGML-based entity names have been removed with the exception of those specified in the HTML 4.0 standard. > > Unfortunately, HTML does not allow mixed-character encodings is > > the same document, making things problematic when trying to > > convert MIME mail into HTML. > > Again - numeric unicode entities. Also some character sets are > convertable to another (for example us-ascii to just about any). > UTF-8 would be more proper solution, chosen character set would be > more practical (yet). Try the snapshot build, <http://www.mhonarc.org/release/MHonArc/tar/>. If iso-8859-2 is the default charset for your locale, and you do not want 8-bit characters to be converted to entity references, but left in raw form, try the following: <DecodeHeads> <CharsetConverters> iso-8859-2; -decode- </CharsetConverters> (btw, the above works for v2.5.13, but *other* charsets will still be converted to SGML-based entities. the snapshot build fixes this). Of course, you will need to change the *PGBEGIN resources to set the content-type meta tag to denote iso-8859-2 for all your pages. The limitation is that only encoded message header fields and text/plain messages are affected. The other text-based filters (like mhtxthtml.pl for text/html) do not use CHARSETCONVERTERS. The higher level text encoding processing I am current working on should address that. --ewh --------------------------------------------------------------------- To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
