MHonArc Release: 2.5.5
Release 2.5.5 made in /mnt/WWW/customers/mhonarc.org/htdocs/release/MHonArc. http://www.mhonarc.org/release/MHonArc/ 2002/05/28 (2.5.5) * Bug Fixes: See http://savannah.gnu.org/bugs/index.php?group_id=1968 set=customadvsrch=0msort=0report_id=105go_report=Go fix_release=2.5.5chunksz=50 * Incorporated format=flowed support into mhtxtplain.pl contributed by Ken Hirsch, with some minor improvements. * MODTIME resource is set to off if setting modification date on files is not supported for given platform. A warning message will be generated. * Added mha-preview program in examples/: A front-end program to MHonArc that provides support for the resource variable $X-MSG-PREVIEW$ that expands to first part of a message body. This program illustrated the usage of the callback API. NOTE: It is probable that support for message preview text may become a supported feature within the standard mhonarc program. There are no guarantees that when implemented, it will be compatible with how mha-preview does it. * Added blog.mrc in examples/: A resource file that generates a page containing the content of all messages. This example is also listed in the resource file examples appendix. * Some documentation updates and enhancements. - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
mharc Release: 0.5.1
Release 0.5.1 made in /mnt/WWW/customers/mhonarc.org/htdocs/release/mharc. http://www.mhonarc.org/release/mharc/tar/ === 2002/07/31: v0.5.1 * cgi-bin/extract-mesg.cgi.in.dist: . Changed returned media-type from message/rfc822 to text/plain. message/rfc822 is nice since some browsers can render it directly, but it does open potential XSS HTML email attacks. IMPORTANT NOTE: User upgrading are encouraged to delete cgi-bin/extract-mesg.cgi.in and run 'make configure' after extracting this release. If you really want the message/rfc822 behavior, you can edit cgi-bin/extract-mesg.cgi.in and redefine the $message_media_type variable. * bin/mk-procmailrc: . Added -final-dest option: The destination of messages that make it to the end of the procmailrc. Generally, this option can be ignored. Run mk-procmailrc program with -man option to view the manpage to get more information about this option. * etc/apache.conf.in.dist: . Security related comments added. Users are encourage to read if using etc/apache.conf. * lib/config.sh.dist: . Added FINAL_MSG_DESTINATION variable to repesent destination mailbox for end rule in procmailrc (checked by mk-procmailrc if -final-dest not specified). === - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
mharc Release: 0.6.1
Release 0.6.1 made in /mnt/WWW/customers/mhonarc.org/htdocs/release/mharc. http://www.mhonarc.org/release/mharc/tar/ === 2002/09/04: v0.6.1 * bin/extract-mesg-date: . Added check for new MSG_DATE_FIELDS config.sh variable denoting the message header fields to extract the date from. The value of MSG_DATE_FIELDS is used if -datefields is not specified. * bin/filter-spool: . If there is no mail in the spool, but .newmail exists, filter-spool will still process .newmail. .newmail is the messages copied from the spool when filter-spool is executing. In the past, even if .newmail exists, no mail in the spool will cause filter-spool to exit. * bin/web-archive: . Added check for MSG_DATE_FIELDS config.sh variable. If set, its value will passed to MHonArc via the DATEFIELDS resource. . Define $MESG-CGI$ resource variable for use within MHonArc resource files. * cgi-bin/extract-mesg.cgi.in.dist: . Internal changes so its uses new MHArc::CGI utility routines. . POD added. * cgi-bin/mesg.cgi.in.dist: . NEW: New CGI program to extract a message from an archive based upon message-id. This allows for persistent URLs to messages that are immune to archive rebuilds that could change MHonArc message numbers. This CGI is referenced in the updated lib/common.mrc.in.dist resource file via the $MESG-CGI$ resource variable. It is used for the new [Bookmark Link] on message pages. * cgi-bin/mnav.cgi.in.dist: . Added some sanity checks to argument input. . Internal changes so its uses new MHArc::CGI utility routines. . POD added. * lib/common.mrc.in.dist: . Added [Bookmark Link] to message page layout to provide a persistent link to the message. The link provided makes use of the new mesg.cgi CGI script. * lib/config.sh.dist: . Added MSG_DATE_FIELDS: List of message header fields to extract the date for a message. . Added MESG_CGI: URL to persistent message reference CGI program (mesg.cgi). * lib/MHArc/CGI.pm: . NEW: Shared CGI utility routines for mharc CGI scripts. * lib/MHArc/MailUtil.pm: . extract_date() routine changed to handle indexed header fields in date fields argument. CAUTION: Only use indexed field specification if you are using a version of MHonArc *newer than* 2.5.11. MHonArc v2.5.11, and earlier versions, do not support indexed fields for the DATEFIELDS resource. * lib/MHArc/Namazu.pm: . NEW: Collection of routines related to Namazu. === - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: Suggestions for improving MHA's i18n support
On September 13, 2002 at 02:55, Mooffie wrote:
This relates to the TODO item of having
chained filters.
Chained? You mean that they'll run one after the other?
If you examine a filter in HSMA, you'll see that its structure is:
sub my_new_HTML_filter {
# 1. do some processing...
# 2. call MHA's HTML filter
# 3. do some more processing...
}
And this looks more usefull than a simple chain.
What you have is kind of a chain, but nothing prevents what you
currently have. The chain filters would be something similiar
to how the Apache API works. Therefore, you could register pre-
and post-filter. For example, I could register a pre-filter for
text/* types that converts all text to a single character encoding,
or does some input error correction before the data is passed to the
main filter.
--ewh
-
To sign-off this list, send email to [EMAIL PROTECTED] with the
message text UNSUBSCRIBE MHONARC-DEV
mharc Release: 0.6.4
Release 0.6.4 made in /mnt/WWW/customers/mhonarc.org/htdocs/release/mharc. http://www.mhonarc.org/release/mharc/tar/ === 2002/09/19: v0.6.4 * bin/web-archive: . BUG FIX: Changes to fix backdoor to raw mail messages for archives with No-Raw-Link enabled. For archives with No-Raw-Link enabled, a file called .noraw will appear for the archives under the raw mailbox data. This file is used by extract-mesg.cgi to determine if retrieval of original messages is allowed. Also, a .htaccess file will be created to deny access via direct HTTP access by a client for those that are using the Apache HTTP server with .htaccess support enabled. If .htaccess is not supported (or you are using a non-Apache web server), you will need to modify the server configuration file directly to deny access. . Added support for localizing labels in all-lists archive listing table via new lib/config.sh variables. * cgi-bin/extract-mesg.cgi.in.dist: . BUG FIX: Changes to fix backdoor to raw mail messages for archives with No-Raw-Link enabled. In order to enable the new fixed version, you MUST do the following: prompt rm cgi-bin/extract-mesg.cgi.in prompt make configure . BUG FIX: Fixed regex pattern checking for valid period argument. Extraction of yearly-based archives should now work properly. * lib/config.sh.dist: . Added the following variables to support localization of all-lists page (default values shown): ALL_LISTS_LABEL_NAME='Name' ALL_LISTS_LABEL_INDEXES='Currentnbsp;Index' ALL_LISTS_LABEL_LAST_UPDATED='Lastnbsp;Updated' ALL_LISTS_LABEL_INFO='[info]' ALL_LISTS_LABEL_DATE='[Date]' ALL_LISTS_LABEL_THREADS='[Thread]' ALL_LISTS_DATE_FORMAT='%Y-%m-%d %H:%M:%S' * lib/mrc/_lang_da.mrc.in.dist: . NEW: Danish localization file. Thanks goto Lars Jorgensen for the contribution. * lib/mrc/_nospam.mrc.in.dist: . Added definition of FIELDORDER to provide a minimal message header. This is to minimize the potential of addresses showing up in unexpected header fields. * bin/config-check: . NEW: New script to dump expanded variable values of lib/config.sh to standard output. * lib/MHArc/Config.pm: . A Perl cache file is now created to make subsequent loads faster. Hence, you will see a file called lib/config.sh.cache.pl appear. This file should not be edited. The module auto-detects when lib/config.sh is modified. * doc/: . Some documentation fixes and enhancements. === - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
mharc Release: 0.7.0
Release 0.7.0 made in /mnt/WWW/customers/mhonarc.org/htdocs/release/mharc. http://www.mhonarc.org/release/mharc/tar/ === 2002/09/28: v0.7.0 * Extracting the mharc distribution will now generate a directory called mharc-X.X.X, where X.X.X is the version of mharc. A new install script (see next change item) is now provided to install mharc into the location you desire. Existing users should be aware of that you no longer just extract a distribution in the location of your existing mharc installation to perform upgrades. You will now extract in a temporary location, and then use the install script provided (see next change item) to upgrade an existing installation. * install.pl: . New Perl installation program for mharc. It should make the installation easier and more automated, and for new installations, it will preset some config.sh variables. NOTE: Not all installation steps can be automated, like crontab editing, web server configure, etc. See the installation document for more information on the new installation process. * bin/apply-config: . BUG FIX: Fixed handling of case when no directories are supplied on the command-line. Cases where HTML_DIR, or other directory variables, are defined to pathnames not under $SW_ROOT are now handled. Thanks to Eugene Eric Kim for spotting this problem. * bin/filter-spool: . Updated to use new PROCMAIL, FORMAIL, and LOCKFILE variables representing the pathnames to the respective programs used by filter-spool. * bin/web-archive: . BUG FIX: The ALL_LISTS_FILE variable in config.sh was not supported. web-archive was looking up the wrong variable name. * lib/config.sh.dist: . Added CGI_DIR variable to represent pathname to CGI bin directory (default value is $SW_ROOT/cgi-bin). Various CGI variables now reference this variable in the default values. CGI_DIR exists mainly for use by the new install.pl script. . Added PROCMAIL variable to represent pathname to procmail program. . Added LOCKFILE variable to represent pathname to lockfile program. . Added FORMAIL variable to represent pathname to formail program. === - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
mharc Release: 0.7.1
Release 0.7.1 made in /mnt/WWW/customers/mhonarc.org/htdocs/release/mharc. http://www.mhonarc.org/release/mharc/tar/ === 2002/10/02: v0.7.1 * lib/lists.def, bin/mk-procmailrc, bin/web-archive: . Added support for Check-No-Archive for lists.def. The author can request no archiving should be done by defining one of the the following header fields: Restrict: no-external-archive X-no-archive: yes If Check-No-Archive is enabled, a message to the list with either field defined will not be archived. * lib/mk-procmailrc: . Can now specify a mail address to receive all unmatched messages via the CATCH_ADDRESS config.sh variable. This serves as a (better?) alternative to the .catch archive. * bin/logcmd: . New script to help provide better logging of crontab commands. * etc/crontab.in.dist: . Entries changed to use new logcmd script for dumping any command output to @@SW_ROOT@@/log/cron.log. * lib/config.sh.in.dist: . Added CATCH_ADDRESS: Specify mail address to receive all unmatched messages. If defined, it supercedes $CATCH_ARCHIVE. === - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: Security vulnerabilities in MHonArc 2.5.12
On October 20, 2002 at 02:34, Steven M. Christey wrote:
(I'm assuming this makes it to mhonarc-dev too)
If not subscribed, it will eventually get manually approved by
the list administrator.
I think the requirement of the ':' should prevent scripting markup.
Before that, I think you would get what you are describing, but I
do not know if a real vulnerability existed.
I don't either. There have been reports that a {javascript}
sequence would work on some Netscape versions, but I didn't test that.
This is for Netscape 4, and was previously reported awhile back
by another user related to XSS attacks for text/html messages,
but I believe Netscape 4 only does it for attribute values of
HTML tags. Hence, I do not know off-hand if {} can be sneaked in
within message headers since the '' will get converted to 'amp;'.
I cannot see a real vulnerability unless mhonarc is executed as root
(or more importantly, suid, but mhonarc is known to not past Perl's
taint checks).
I believe that the implicit opinion of people who report security
issues is that user-to-user exploits are a legitimate security
concern. It may be academic in most environments, but there is some
area of concern.
Agreed.
Of course, since symlinks are a Unix-thing, than only a Unix-specific
solution is required.
This isn't quite the case, in general. Windows systems have .LNK
files (shortcuts) that have received very little attention by security
researchers, but they are a possibility. That may not be a factor in
this instance, due to .LNK issues being relatively unknown, they are
not well understood (e.g. could someone rename a .LNK file to not use
the extension and still get .LNK behavior? Before you reject this
notion out of hand, stick some HTML into a .TXT file and view it in
Internet Explorer; you get HTML, not text.)
From my understanding of .lnk files, they do not function like real
symbolic links. I agree with you that .lnk files could have potential
security problems, but since they do not function like Unix symlinks,
they probably have a different set of problems.
As for IE reading text files as HTML, I know about this extreme
annoyance. The problem also occurs when an HTTP server sends a
text/plain content-type, but IE does a peek at the content, and if
it thinks it looks like HTML, it renders the data as HTML.
Maybe the best option would be to increase the randomness of the
filename so much that it becomes extremely difficult to predict. This
involves having a filename whose random portion is long enough to
avoid brute force attacks (which is why the process ID can be
ineffective even if it's assigned randomly by the OS). Some
programmers assume that the time-of-day is sufficiently random, but
not if something is run out of at or crontab...
Would utilizing Perl's rand() operator be sufficient?
--ewh
-
To sign-off this list, send email to [EMAIL PROTECTED] with the
message text UNSUBSCRIBE MHONARC-DEV
MHonArc Release: 2.5.13
Release 2.5.13 made in /mnt/WWW/customers/mhonarc.org/htdocs/release/MHonArc. http://www.mhonarc.org/release/MHonArc/ 2002/10/21 (2.5.13) * Bug Fixes: See http://savannah.gnu.org/bugs/index.php?group_id=1968 set=customadvsrch=0msort=0report_id=105go_report=Go fix_release=2.5.13chunksz=50 * DBFILE resource can now be set to an absolute pathname. This allows the database file to be located in a separate location than in the archive directory. If not an absolute pathname, then value is treated relative to OUTDIR. * readmail.pl updated to handle MHTML messages better. mhtxthtml.pl changed accordingly. * readmail.pl handling of malformed multipart messages improved. Cases were a the terminating boundary delimiter did not exist would generate a warning message in the converted message body that data could not be converted. This case should now be handled so that end of entitiy implies a terminating boundary delimiter, (Thanks goto Randy Blaustein for providing real-world test cases). * Fixed problem where some message attachments were lost. This mainly occurs when using mha-decode with the -dcd-digest option, or if you have registered the m2h_external::filter for message/* data types. (Thanks goto Steve Johnson for finding this problem.) * m2h_external::filter will now include the subject of a message in the attachment link if saving message/* data to a file. * m2h_external::filter properly escapes the filename parameter when displaying it in the attachment link. This is done to avoid any possible XSS exploits. Note, no exploits have been reported by using the filename parameter in messages, so this change is more of a preemptive measure. * m2h_external::filter will fall back to a txt extension for unknown text types instead of a bin extension. * m2h_text_plain::filter: Removed hardcoded 'as-is' for US-ASCII data. This is so a user could define a converter if having to deal with mislabeled character data. (Thanks goto Mooffie for finally finding a real-world case to not hardcode us-ascii). - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: July 31st shown as July 30th twice
On October 28, 2002 at 18:40, Jeff Breidenbach wrote: Possible mhonarc bug reported by Debian users. Details at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=155305repeatmerged=yes Not a bug. See the USELOCALTIME resource. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: Format=flowed
On October 29, 2002 at 03:31, Gunnar Hjalmarsson wrote: Single line paragraphs are ambiguous as to whether they are fixed or flowed. I think that it is a little startling to have a fixed-width font line in betw een two variable-width paragraphs. Granted, it's not a capital crime, but it i s less than ideal. As I wrote in my recent CVS commit to mhtxtplain.pl, I think the fixed font rendering is correct according to RFC 2646. However, I changed the filter to render in non-fixed. I do agree that there is some ambiguity, but the conversion table they provide implies that it should be fixed. Maybe the authors of RFC 2646 should be notified about this. I should note that Mozilla renders flowed data all in a fixed font (but flowed text where required) so it ignores the problem. It also seems that your latest code has a bug. It does not show a blank line between two flowed paragraphs. I agree on both those comments, and have attached some modifications that resolve the issues. To see the difference, please compare http://www.gunnar.cc/misc/archive/msg5.html, converted with revision 2.25 of mhtxtplain.pl, with http://arc.ringlink.org/ringlink-open/msg02452.html, converted with my (latest) modified version. Also, I noticed that v2.25 never converts to more than one blank line. I think that 2 or 3 blank lines between paragraphs should be recognized, since the use of additional blank lines may be part of a message's disposition. The attached code takes care of that as well. Thanks for the patches, but I hopefully just committed more optimal fixes to the problems. Also, I had to make some other changes to get the correct rendering. Take the following example: This is some flowed text that is quoted. This is not quoted and appears without an extra line break. Previous to my committed changes, the converted page would have a line break between the two chunks (including both flowed conversion and fancyquote conversion), an error. To fix it, I modified the inline style to blockquote and added one to pre elements to suppress the automatic line space after the end of blockquote and pre elements. Therefore, if using the quoteclass option, the user will need to take this into account to get proper rendering sematics. I also changed the handling of line breaks to get the correct rendering. I checked IE 6 and Mozilla with my test page, and the page appears to be rendered properly in both. I used Mozilla's native rendering of flowed data to compare that line breaks were handled properly. Since proper rendering does require a CSS-enabled browser, this provides a good reason for the existence of the disabledflowed option. Converted messages may not look that good in non-CSS-enabled browsers and text browsers, so disabling flowed conversion may be needed for users that want to cater to this usage base. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: Format=flowed
On November 2, 2002 at 15:36, Gunnar Hjalmarsson wrote: I don't understand how that would be possible. For quoted paragraphs, yes, but not for unquoted. Please have a look at http://arc.ringlink.org/ringlink-open/msg02452.html to see what I mean (and also have fixed via resource-settings, so I'm not asking for my own sake). I now get it. I thought you were only refering to blockquote elements. If the nonfixed option is specified, then proportional font will be used, Not necessarily, i.e. not if you do as I did. :) Correct. To be more technical, the PRE element will not be used, so the default font will be in effect. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: mhastart.pl
On November 5, 2002 at 16:58, Gunnar Hjalmarsson wrote: * The initial BEGIN block is probably not needed. Fatal messages should be sent a log file to avoid any potential sensitive information showing up in someone's browser. Error messages the user see should not be some Perl error message, IMHO. Please note that the script is intended to be password protected in some way, and the user can be assumed to have at least FTP access. (I made a change, so that the 'fatalsToBrowser' routine is not imported when running the refresh() routine, which anybody can do.) I have tried to make the installation easy, and error messages in the browser is undoubtedly convenient when you are installing a CGI script. I could of course import the 'carpout' routine instead of 'fatalsToBrowser', or do something similar, but I don't understand the reason for your concern. All this sounds reasonable. I was just considering the case where something was misconfigured, so errors could happen before any password checks were performed. This could allow someone else to see error messages from the CGI. I do not think it is anything major. Maybe for a later version of your script, you could have an option that allows errors to the browser or to a log file. True. I didn't use password protection here, since I wanted to make a simple pipe from for instance a .forward file possible. I'd then make it configurable. By default, password check is done, but then a configuration variable can be set for those that want to bypass it. Generally, try to go with the more secure approach, but allow configurability for those who are willing, and conscience, to take the risk. This appears to allow someone to do a DoS against the the popserver ($pophost) Not sure what you mean by that. DoS = Denial of Service. A malicious hacker could pound the CGI script with archive update request. This would then cause alot of traffic to the POP server, which could cause denial of service problems and disable any archive updates. You may think I'm naive, but to some extent I simply rely on hackers/crackers/whatever having more exciting things to do than causing some minor inconvenience for somebody who maintains a mailing list archive. ;-) This is a common mistake made by everyone (including myself). Most people think they are not worth hacking, but it happens all the time. You may not care about your archives, but someone else using your script may. There are alot of script kiddies out there that like to screw with stuff, just cuz. * The updatembox() could be written to prevent a large amount of memory getting used. At a mimimum, store the passed in message data into a single scalar ... Note, an array containing each line of a message takes up more memory than a single scalar containing the entire message text. So far I understand, and now STDIN is stored in a scalar. But I haven't used the code you suggested in this respect, since I'm not comfortable with references in Perl, and I avoid using code I don't understand. If you can explain what the point would be, I'd be happy to do some reading. :) The main reason is to reduce memory usage by not storing the complete data in memory and references could be used to avoid unnecessay copying of data (references are also required for complex data structures like an array of hashes or a hash of arrays). Reference usage could also protect from a DoS where a hacker uploads megabytes of data to the script. You may want to consider adding a max upload size parameter to check against CONTENT_LENGTH, and abort the request if CONTENT_LENGTH is too large (I'd add this feature independent of using references or not). References in Perl are not that complicated. They are much better than dealing with pointers in C, since in C, you can really screw yourself. If you have time, read the perlreftut and perlref manpages. They should help you in getting started with references. * In the shell() routine, you may want to use shellwords.pl. ... I'm not sure if anyone has bothered to make a module out of it. Did that. I found Text::Shellwords in CPAN, but it seems totally redundant to me, since shellwords.pl only includes one subroutine. On the other hand, it was Lincoln Stein who wrote it, so I guess there is a sensible reason for its existence... My guess is that Text::Shellwords would replace shellwords.pl at sometime. However, Text::Shellwords is not included with the standard Perl distribution while shellwords.pl is. I do know why Lincoln didn't just copy the shellwords.pl implementation in Text::Shellwords. I'm slowly working on v2.6.0 of MHonArc. When I think I am getting near a release date, I will post a message to the dev list. You can then remind me about your mhastart.pl and insure I get the latest copy before the release is made. I recommend that you run pod2html on your script and make the output available on your site. This way, people can read the
Re: Procmail problem?
(This is dev stuff, so I'm cc'ing mhonarc dev since it is the
forum for discussing mharc development also.)
On November 20, 2002 at 21:38, Christopher P. Lindsey wrote:
I'm not sure I understand the question, but I'll try to answer.
There is one procmailrc for all list archives. It's role is to
filter incoming mail and file it into the various raw mailbox archives.
Hence, the recipe above is replicated in the procmailrc for each
list defined in the lists.def file (lists.def is a control file
that tells mharc what lists are to be archived):
I guess I'm not sure how the messages get into the procmailrc file.
If one copy of the message is sent per list that is being archived,
then you don't need to create a carbon copy of the mail message. In
fact, you could even simplify things to
:0
* ^TO_\/([EMAIL PROTECTED]|[EMAIL PROTECTED]|mhonarc-users@mho
narc.org)
{
ADDRESS=$MATCH
:0
* ADDRESS ?? ^()\/[^@]+
{ LISTNAME = $MATCH }
HAVEMATCH=`echo yes`
:0 Wi
MKDIR=`mkdir -m 755 -p $MBOXROOT/$LISTNAME`
:0 Wih
MESGDATE_=| /mnt/WWW/customers/mhonarc.org/htdocs/archive/bin/extract-m
esg-date -fmt '%Y-%m'
:0:
$MBOXROOT/$LISTNAME/$MESGDATE_
}
This will not work. First, a cross-posted message may contain multiple
lists addresses in the message header, so if the one rule above was
used, all versions of the message would goto the mharc-users archive.
Incoming mail is processed from a single mailbox that can contain a
variety of messages to multiple lists. Something like the following
is used to process the mailbox:
formail -s procmail procmailrc.mharc .newmail
.newmail is the messages in the spool directory that have been
copied over.
Now, for a cross-post, I will get the same message more than once.
However, how do I know which list archive has already got a copy if I
use something like you provided? BTW, I use the formail message-id
caching trick as the first rule in the procmailrc to drop any dups.
Hence, I will only get the chance to filter a message properly once.
Another thing to note is that LISTNAME is not dependent on the
mail address, but is logical label defined in lists.def. This is
done since there is no guarantee that a list address will not change
(like the mhonarc user's list has done). Plus, an archive can be
used to archive multiple lists. I do this with my private archives.
I have have generic archives like newsletters and security where
multiple lists are being fed into them.
I know I'm being a pain here... And let me know when to shut up. :)
Keep blabbing. I definitely want criticism about the procmail and
filtering stuff. The procmail manpages do not always contain the
exact information I need, so what you see is due to trial-n-error.
One other question... How come you do
HAVEMATCH=`echo yes`
instead of
HAVEMATCH=yes
to save the system call?
I'm not sure. I may have thought you could not do it or it did not
work when I tried it. I'll have to try it again.
Feel free to forward this to the list if you
want, but I wasn't sure how far off-topic I'd veered. :)
CC'ed the mhonarc-dev list (so excuse the dups).
I appreciate your feedback,
--ewh
-
To sign-off this list, send email to [EMAIL PROTECTED] with the
message text UNSUBSCRIBE MHONARC-DEV
Re: mhastart.pl
On November 28, 2002 at 00:20, Gunnar Hjalmarsson wrote: I think that the script is now ready to be added to the repository. This is the POD output at my site: http://www.gunnar.cc/mhonarc/mhastart.pl.html I have stated that questions or bug reports should preferrably be reported to the MHonArc Users mailing list. Let me know if you object. Nope, but be prepared to field any questions related to it. Basically all the comments at http://www.mhonarc.org/archive/html/mhonarc-dev/2002-11/msg7.html have been taken into consideration. I have also added a 'feature', i.e. now you can remove the latest message from the mbox file by clicking a button. ;-) I've added the script to CVS. Unfortunately, the $Id$ has been rewritten. I think there is way to get CVS to not do that, but I cannot remember off-hand what is. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: mhastart.pl
On November 29, 2002 at 12:46, Gunnar Hjalmarsson wrote: Earl, maybe it would be a good idea, after all, to remove the file and re-add it with the -ko option. Done. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: CVS: mhonarc/MHonArc/examples def-mime.mrc,1.19,1.20
On December 10, 2002 at 15:57, Takashi P.KATOH wrote: From: Earl Hood [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: CVS: mhonarc/MHonArc/examples def-mime.mrc,1.19,1.20 Date: Tue, 10 Dec 2002 01:44:22 -0500 *** *** 93,97 iso-8859-15;MHonArc::CharEnt::str2sgml; MHonArc/CharEnt.pm iso-8859-16;MHonArc::CharEnt::str2sgml; MHonArc/CharEnt.pm ! iso-2022-jp;iso_2022_jp::str2html; iso2022jp.pl iso-2022-kr;MHonArc::CharEnt::str2sgml; MHonArc/CharEnt.pm euc-jp; MHonArc::CharEnt::str2sgml; MHonArc/CharEnt.pm --- 93,97 iso-8859-15;MHonArc::CharEnt::str2sgml; MHonArc/CharEnt.pm iso-8859-16;MHonArc::CharEnt::str2sgml; MHonArc/CharEnt.pm ! iso-8859-jp;MHonArc::CharEnt::str2sgml; MHonArc/CharEnt.pm iso-2022-kr;MHonArc::CharEnt::str2sgml; MHonArc/CharEnt.pm euc-jp; MHonArc::CharEnt::str2sgml; MHonArc/CharEnt.pm This is iso-2022-jp (not iso-8859-jp), isn't it? Doh! The code and CHARSETCONVERTERS resource page have the correct values. Thanks for catching this, --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: [Bug #2051] Query string including 'action=' not handled properly
On December 29, 2002 at 00:21, Gunnar Hjalmarsson wrote: Content-Type: multipart/mixed; boundary=X --X Content-Type: text/html img --X Content-Type: text/html src=http://www.mhonarc.org/MHonArc/logo/mhastampw_t.png; --X-- The final HTML message page will contain the following: img src=http://www.mhonarc.org/MHonArc/logo/mhastampw_t.png; I.e. An auto-loaded URL got by the filtering. I tested the above, and it got by the filtering also with the original code. Would suggest that you take a closer look at it. Can you provide your test case? The above did get filtered from my tests. Of course, if allownoncidurls is in effect, the above will pass through. I am reluctant to loosen up the filtering code at this time due to XSS issues since I am not confident that any kind of loosening cannot be exploited Okay, I respect that, and I admit that the example I posted in the bug isn't very common... I'll refrain from further suggestions for a while. ;-) Suggestions are always good along with others examining the code. The limitation you cite has been brought up before by a different user a long time ago. Since the best solution would require real HTML parsing, dealing with the limitation has been a back burner item. It is a limitation that I would like to address at sometime since valid content data can be magically deleted. For example, say you included some sample code in your message that includes strings like src=... the text will be removed since the filtering does not descriminate what is and is not in a tag. The example you provided, action=, is more complex since it requires knowing context within a tag: an attribute name vs an attribute value. Due to the inherent security problems with HTML in email, keeping the limitation around may encourage users to exclude HTML mail from their archives :-) The limitation is probably worth noting in the documentation. --ewh P.S. If people want fonts and all that jazz in their messages, the text/enriched media-type has existed for a long time, and it does not introduce the security problems that text/html does. - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: [Bug #2080] Redundant substitution
. Level 1 text. A short quoted paragraph. The End. --ewh -- Earl Hood, [EMAIL PROTECTED] Web: http://www.earlhood.com/ PGP Public Key: http://www.earlhood.com/gpgpubkey.txt ---end test data--- - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: Archive Conditional Site Initialization?
On January 4, 2003 at 12:19, W3Hosts Development Team wrote:
Some option processing occurs after site initialization which requires
registered callbacks in site initialization for conditional processing by
archive. Please don't tell me wrapper is the answer...
It may be 6 of one or half dozen of another to some but is it preferable to
expose a variable, i.e. $mhonarc::OUTDIR vs. MHonArc code, i.e.
$mhonarc::opt{archive} to perform archive conditional processing without
registering a callback? I loathe the idea of registering a callback to
register callbacks.
So... I beg your indulgence and please enlighten me. Can we do and is it a
minor change to do site initialization after option processing?
I'm having problems parsing the above in determing exactly what
your goal is. Can you tell us what the ultimate goal is? I.e. What
exactly are you trying to achieve?
mhasiteinit.pl is kind of a hack, so mucking with it may not be
the best long term solution to your problem.
Plus, what is the objection to a wrapper script? Providing a
custom front-end would allow you to execute custom code after
option processing but before input is processed. Example:
require 'mhamain.pl';
mhonarc::initialize();
mhonarc::open_archive();
## ...custom code here...
mhonarc::process_input();
--ewh
-
To sign-off this list, send email to [EMAIL PROTECTED] with the
message text UNSUBSCRIBE MHONARC-DEV
Re: Archive Conditional Site Initialization?
On January 6, 2003 at 00:38, W3Hosts Development Team wrote: Normally, I have no problem with wrappers with a well-defined API. I want to stay away from implementing undocumented MHonArc calls. Will 2.6 preserve 2.5x API or will we have to re-write our apps to upgrade? 2.6 will be compatible with 2.5. The MIMEFILTERS API change that occured in the past is an exception, but I think a needed one. I'm considering making the callback API more robust by allow multiple callbacks for the same event, including defining callbacks via a resource file, but try to maintain compatibility with the existing model. Also, I think more callbacks should be added for the different phases of archive processing (like one when all options and resources have been loaded). I'm unsure if such a change will make it in 2.6.0, but may be included in a 2.6.x release. Since I have other things that will be on my plate soon, I'd like to get v2.6.0 out before I am too bogged down with other priorities. (which could delay its release). Any real changes to the core will probably indicate a major version change (v3.x). I.e. Using things like $mhonarc::OUTDIR will still be valid for 2.x releases. 3.x is still an amorphous concept. Since mharc, and other scripts I have written leverage MHonArc internals, I'm directly aware of compatibility issues for scripts that use the documented API and some internals, so I will not leisuring change things. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: Requeueing messages processed by mharc?
On January 8, 2003 at 23:59, Christopher P. Lindsey wrote: # CHANGE: tests if directory exists; saves a system call :0 Wic * ? test ! -d $MBOXROOT/mhonarc-users `mkdir -m 755 -p $MBOXROOT/mhonarc-users` But isn't the call to 'test' a system call or does procmail handle it specially. If not, calling mkdir always uses a single system call while your method uses one or two system calls. Boy, we can't put anything past you. :) Traditionally, 'test' has been a less expensive call than 'mkdir', so you only have an expensive call when both need to be run. I guess the comment should have been I'm unsure about the expense. Both will at least do a stat(). Hence, mkdir -p does an implicit stat first to see if the pathname exists. If so, it quietly exits. Unfortunately, this will not work. The message-id cache will cause the message to be quietly dropped when delivered back to the archive account. I.e. There is an initial formail rule that checks the message-id cache, and if the id exists, the message is quietly dropped. Ahh. I suppose a way around that is to check if the message-id is in the cache before adding it, and only adding it after successful delivery. A gotcha is that if it is a cross-posted message and it gets delivered to one archive, but fails for another (probably and improbable event). Does formail support an action of check, but do not add? And then just an add to the cache? I'm not sure, so a custom script would be needed. Something really screwing has to happen for an delivery error to occur, but of course, anything can happen (like out-of-disk space). I'm unsure that requeuing (ignore the message-id cache issue) is the best solution, with one reason due to the existence of different MTAs. OK. Just thought I'd ask. :) It's a good question, but the answer is not clear. Something to consider is if delivery error does occur, is the system in a state that any kind of error recovery is hopeless? It could be possible if that all I/O is over NFS, and the NFS server is down, some kind of error recovery could occur, like bouncing messages to an admin address, or queuing the messages to a local temp file to be processed later. In sum, I think robust error handling would require some work, and of course, it would be for rare cases. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Getting ready for MHonArc v2.6.0 release
mhonarc-dev, Since I have other priorities coming down the pike, I have decided to freeze any new functionality development for v2.6.0 and only concentrate on bug fixes and refinements. I would like to release v2.6.0 as soon as possible, but would like to have others test things out before the release. The snapshot builds at http://www.mhonarc.org/release/MHonArc/tar/ can be used to download the latest code and test things. I've installed the latest code at mhonarc.org for use with the mhonarc.org mail archives and I'm running the latest code on my private archives. mhonarc.org archives use Perl 5.8 and my private archives use Perl 5.6.1. I'd definitely like feedback from anyone who can test things under older versions of Perl. Also, I would like new character conversion support tested: the updated to MHonArc::CharEnt for CHARSETCONVERTERS, and the new TEXTENCODE resource. I may still do some updates to the documentation, if time and motivation exists. I'm thinking of adding sections related to localization/internationalization and on performance. With the updated character encoding support and the more secure temp file usage, performance is slower than earlier versions. Improvements to performance can be done by changing the default CHARSETCONVERTERS resource for specific locales. For example, if an archive just contains messages for a single locale (like latin1), then the following can be done: CHARSETCONVERTERS override default; mhonarc::htmlize /CHARSETCONVERTERS --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: invalid link label for a message attachment if file name is MIME encoded.
On February 6, 2003 at 10:29, Tomohiko Sugihara wrote: My explanation was not enough... I tried 2003-02-05 snapshot build and I found the same issue. Normally it's good . If attachment file name contains x??24 (ex. x2524), file name is converted to unexpected string. Is it caused by Perl ? Now I'm using Perl 5.005_03 and I'll try to test Perl 5.8 in the near future. Can you provide me with a sample message and any resource file you are using? Plus, provide what command-line options you are using. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: wrong @ conversion in iso-2022-jp text
On February 19, 2003 at 13:52, Takashi P.KATOH wrote: reported to me that v2.6.0 with iso2022jp.pl converts Japanese text improperly. ... The following diff should fix the problem: ... Please test out the fix. Umm, this patch seems inappropriate. ... Otherwise, `@' will be disappeared. Doh! You are right. I just commited a better fix that will make it easier to maintain html specials. Please test. By the way, I have a question concerning this. I thought `@'s have been converted to #x40; to avoid address collecting (SPAM), haven't it? I added this in v2.6.0 as a default form of obfsucation. Previous versions did not do this. So, it doesn't seem for me that this patch provides fundamental solution. Yes and no. There are resources (SPAMMODE, ADDRESSMODIFYCODE) that can be used to do obfsucation if it is really needed, so I see leaving @ alone by default as okay. You are correct with the respect of being iso-2022-jp-aware. However, I do not see a simple solution to this, so I think reverting back to past behavior of leaving '@' alone is sufficient. Of course, I don't mean the patch is not acceptable. I just want to confirm the reason why you converted `@' to #x40;. You are right about the reasons. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
MHonArc Release: 2.6.1
Release 2.6.1 made in /mnt/WWW/customers/mhonarc.org/htdocs/release/MHonArc. http://www.mhonarc.org/release/MHonArc/ 2003/02/22 (2.6.1) * Bug Fixes: See http://savannah.nongnu.org/bugs/index.php?group_id=1968 set=customadvsrch=0msort=0report_id=105go_report=Go fix_release=2.6.1chunksz=50 * Corrected character mapping tables for VISCII based on a message to the perl-unicode mailing list. * Added FASTTEMPFILES resource which causes MHonArc to use non-random temporary files. This is less secure, but provides a little bit of speed improvement. - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
MHonArc List Archives Not Updating
(Sorry for those that receive this message twice) MHonArc Users, The system that performs updates to the mhonarc.org list archives is down. The archives are still accessible (the web server runs on a separate system), but recent messages are still queued to be archived. The downed system is also used to generate snapshot builds and to perform official releases. The 2.6.4 bug fix release is ready to go once the system is back up or other arrangments are made. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
install.me Release: 1.1.1
Release 1.1.1 made in /mnt/WWW/customers/mhonarc.org/htdocs/release/install.me. http://www.mhonarc.org/release/install.me/ === 2003/07/191.1.1 * Added -root path option to set the root file hierarchy that all installation paths will be relative to. For example, if -root is set to /tmp and -binpath is set to /usr/bin, bin files will be copied to /tmp/usr/bin. The option mainly exists for helping create alternate installation bundles, like rpms, and it should not be confused with the -prefix option. === - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
MHonArc Release: 2.6.5
Release 2.6.5 made in /mnt/WWW/customers/mhonarc.org/htdocs/release/MHonArc. http://www.mhonarc.org/release/MHonArc/ 2003/07/19 (2.6.5) * Bug Fixes: Bug ID Summary -- 4126 Typo in mhopt.pl causes error message for big5 character set 4315 allowcomments' directive to filter() is ignored -- http://savannah.nongnu.org/bugs/index.php?group_id=1968 set=customadvsrch=0msort=0report_id=105go_report=Go fix_release=2.6.5chunksz=50 * An architecture independent RPM package is now provided for installation. Because of this, the package name format has slightly changed to be consistent RPM, and other, package managers: Old format New Format - - MHonArcX.X.XMHonArc-X.X.X Installation document has been updated to reflect this change. If you create third-party distribution bundles for MHonArc, you may need to update your bundling process to take account of this change, mainly because the directory created when extracting the tar or zip bundles now include the hyphen. - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: [PATCH] fix for multipart boundary detection
On July 31, 2003 at 11:10, Sean Dague wrote: Attached is a patch which fixes boundary detection for multipart mime encoding. As a mutt user, I found all my messages going through mhonarc that were pgp signed ended up not being properly detected as the multipart mime messages that they were. Last night, I finally went on a quest to find out why. The solution isn't mine, I stumbled upon it in SpamAssassin when doing greps trying to track down what was actually doing the boundary detection. I'm hoping I preserved spacing properly for the patch, if not, please let me know. Please consider this for inclusion in your next release, as I *really* don't like seeing the mail archives of my messages look like this: http://www.mail-archive.com/mhvlug%40lists.dague.net/msg00112.html. :) Can you tar up a sample message that illustrates the problem your patch tries to address? --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: Enhancement request/suggestion/offer
(I'm following-up to the mhonarc-dev list since this is appropriate for that list. The author of the original message is being bcc'ed in this reply. The original author is free to only correspond with me in private if they choose to not subscribe to mhonarc-dev.) (BTW, feature requests can be formally submitted at http://savannah.nongnu.org/support/?func=addsupportgroup=mhonarc) On August 1, 2003 at 13:10, someone wrote: The e-mail content typically submitted to the lists often contains simple attachments. My users asked me to add links to the attachments to the archive index page. I have done so and would like to see this feature become a standard part of MHonArc so I don't have to keep adding it back in every time I upgrade MHonArc. Though the solution I currently have is a bit of a hack, I have a pretty good idea of how to incorporate the functionality in a more structured way. ... The purpose of my e-mail to you, is to find out if you are interested in an enhancement like this. I am a veteran software engineering professional and I would be willing to do the work and contribute it if you will provide design and code review assistance. Please let me know what you think. This type of feature has been on the TODO list for some time: = Provide attachment listing at top of each messages page (suggested by Lars Aronsson). This can be tricky since filters have ultimate control of how parts are treated, including overriding attachment disposition. Would also require changes to how base parsing cooperates with content filters. It is not exactly what you are asking for, but the idea is the same along with subsequent design and implementation. There are two main issues with adding such a feature: 1. Preserving the existing MIMEFILTER API for backward compatibility. 2. Providing resource customization flexibility on how attachment are listed in an index (or elsewhere). I.e. A fixed format would not be acceptable in the standard distribution. (1) could be addressed by allowing an alternate data structure as the return value. For example, a return of a hash reference can be used for the newer style of return value that explicity provides attachment information. The mail parsing library (readmail.pl) can examine the return value by using ref() to determine if new style or old style return value is being used. A slight variation is to keep the traditional list-style return value of filters, but for each derived file listed, a hash could be used as an alternative to a scalar string, where the hash will contain meta-information about the file (along with denoting that it should be considered an attachment). Right now, I am favoring this approach verses the first, but that could change as more details arise. Note, with enhanced attachment info, changes to the database file format may have to be done and to insure such changes with preserve (upward) compatibility with older archives. (2) will require some additional resource variables to represent attachment info: filename, description, content-type, etc. A particular tricking part is how to handle the referencing of multiple attachments of a single message. It will require that a new layout resource, or resources, will be needed to facilitate this. And, of course, documentation will need to be updated to reflect all changes made :-) I have had no real incentive in the past to add attachment listing support, and there is some work involved (as described above). Therefore, I have not bothered implementing it, yet. It looks like it is definitely doable, but all bases need to be covered in order for it to become part of the standard MHonArc distribution. So the ultimate question is if you would like me to do the work vs you trying to take a stab at yourself. If the latter, you should subscribe to the mhonarc-dev list and at least get familiar with accessing the CVS source tree, http://savannah.nongnu.org/cvs/?group=mhonarc. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: [bug #4622] Duplicate entries in database if .html files not created
On August 6, 2003 at 14:27, Vicki Brown wrote: I'm afraid I don't understand... the database gets correupted and somehow allows itself to create 15 entries for the same named html file (though the file is never created) and this is consistent behaviour and somehow not a valid bug? As was said, this is the behavior when MSGPGS resource is disabled. When disabled, HTML filenames are meaningless, so the %IndexNum hash is irrelevant. I.e. The database is not corrupted. The key question is, What caused MSGPGS to be disabled? _I_ certainly didn't disable anything... Whatever caused this to become disabled was _not_ correct behaviour. Well, you have not provided information that allows one to reproduce the behavior you are experiencing. Therefore, it is unknown if it is a MHonArc problem or a usage or an environment problem (like something wrong with perl itself). And since you are the only user that has reported this problem, it appears you are the one who will have to investigate what it may be, and if it is MHonArc, you can report back and/or submit a patch. I'm sure your 20 years of *nix experience and programming will help you figure it out. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
MHonArc Re-release: 2.6.8
Re-release 2.6.8 made in /mnt/WWW/customers/mhonarc.org/htdocs/release/MHonArc. http://www.mhonarc.org/release/MHonArc/ 2003/08/12 (2.6.8) * Bug Fixes: Bug ID Summary -- 4719 Spurious read_fmt_file call -- https://savannah.nongnu.org/bugs/?group=mhonarc - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
MHonArc Release: 2.6.7
Release 2.6.7 made in /mnt/WWW/customers/mhonarc.org/htdocs/release/MHonArc. http://www.mhonarc.org/release/MHonArc/ 2003/08/07 (2.6.7) * Bug Fixes: Bug ID Summary -- 4569 Problem with unfolding can mess up boundary processing in multipart messages. 4594 Initial space on lines removed when using fancyquote. -- https://savannah.nongnu.org/bugs/?group=mhonarc * Added LANG resource to define locale. Affects resource filename resolution and message subject and author sorting. * readmail.pl updated to define the following special header field keys passed to filter routines: x-mha-content-typeThe media type of the entity extracted from content-type entity header x-mha-part-number The relative part number of the entity with respect to parent entity. To get the absolute part number, use readmail::get_full_part_number($fields). x-mha-parent-header Reference to parent header fields hash. This, and other data structures, are now mentioned in the MIMEFILTERS resource page. * Text/richtext tag, samepage, is quietly dropped in mhtxtenrich.pl. - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
RFC: Planned changes to attachment filenaming
Once the problems with MHonArc CVS tree are fixed, I plan on committing some changes that affect attachment filenaming. Currently, attachments are given filenames like: doc0.doc jpg00123.jpg I.e. Similiar in format as message pages. However, with planned support for the new ATTACHMENTDIR resource and to improve performance, attachment filenames will have more random-type filenames. For example: binFph3Yy9EEe.bin jpgA416IQrbTV.jpg ps2RUzzPb4Pa.ps Technical reasons for change: * The (yet to fully implemented) ATTACHMENTDIR resource would allow one to have a single directory to contain all attachments for multiple archives. Therefore, a method must exist for creating filenames that avoids race conditions (the current numerical method would experience race conditions). * The random approach avoids the overhead of scanning the directory each time to compute the next number. Although I have not done any tests yet, it seems that the scanning method can incur some significant overhead of large archives with many files since the algorithm is O(n^2). These changes will probably lead to a different behavior for filters that support the subdir option. Currently, the sub-directory is named msgprefixmsgnum, but if a shared attachment directory is used, such naming can cause conflicts. Therefore, subdir should become deprecated, or -- since there is uses to isolate the attachments of individual messages -- the subdir filename will have to change, maybe keyed off the message-id. However, if message-id-based directory names are used, having a shared attachment directory can still cause a problem when using subdir since you can have a message that is in more than one archive. If the message is removed from one archive, deleting the attachment files will cause the attachments to disappear from the message in other archives. Possible solutions are to ignore the problem and warn the user about such usage or develop a reference count system. I think I will do the former initially and only do the latter if there is any real incentive. Objections and/or comments are welcome, --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
MHonArc development status
Things have been quiet for awhile. As many of you probably know, Savannah was cracked awhile back and the GNU folks have been busy cleaning things up a revising their security policies. I have several modifications pending before the crack-in. Unfortunately, due to some new CVS restrictions, I have put on holding commiting them. Add to that, that I am involved with some regular work, things have been going slow. I knew I should have commited things months ago. I am seriously considering moving MHonArc off of savannah. I understand some of there security restrictions, but the inability to modify CVSROOT admin files of the mhonarc source tree may make using savannah no longer practical. I'm unsure if trying to host things on mhonarc.org will work or if I should go with a site like SourceForge. I like the bug tracking facilities savannah provides, and I do not know if I want to hassle with maintaining my own bug tracking system. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
MHonArc CVS Tree Moved
The CVS repository for MHonArc has been moved over to another non-savannah system. Once, if ever, the savannah folks are able to allow CVSROOT updates, the repository will be moved back. But until then, it is in a location that allows me to do what I require for MHonArc development. With the move, the CVS repository that is accessible from savannah is now stale. I tried to disable CVS via the project admin screen, but it appears to have no effect. The bug tracking system will still be used. Since the new CVS location does not provide anonymous access, I have re-enabled nightly snapshot builds. This way, those who want to play view the latest source can goto http://www.mhonarc.org/release/MHonArc/snapshot/. If you want to download it in distribution form, go to http://www.mhonarc.org/release/MHonArc/tar/. Things should be ready for a new release (2.6.9). For those that are adventurous, please test out the latest snapshot. 2.6.9 release has been delayed for months due to the problems with Savannah, so I hope to release it soon, and will appreciate any usage feedback from anyone that decides to try out the latest snapshot. The following is the current list of changes available in the latest snapshot: * Bug Fixes: Bug ID Summary -- 5473 directory separator for attachments on W2K 5643 New ressource - newsserver 5758 MULTIPG and NOSAVERESOURCES cause archive to be rewritten 5905 Modification of non-creatable array value attempted -- https://savannah.nongnu.org/bugs/?group=mhonarc * New resources: ATTACHMENTDIR Directory to save attachments. ATTACHMENTURL Web URL to attachment directory. NEWSURL URL template for linking to newsgroups. * Attachment filenames have changed from the numeric-style ext#.ext to extXX.ext where XX is a random string. The change corresponds with a change to the API to mhonarc::write_attachment() function in mhmimetypes.pl. * m2h_text_plain::filter: . Changed default quoting styles: Left rule changed from 0.1em to 0.2em and the color changed from #FF to #EE. . Minor changes to flowed formatting in order to provide consistancy with how Mozilla's Gecko engine renders flowed text. * base64.pl will use MIME::Base64 module if present. MIME::Base64 uses an underly C implementation for decoding, so it is noticably faster than the pure-Perl approach. --ewh P.S. The file download area at savannah has also been disabled. - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: RFC3676 - The Text/Plain Format and DelSp Parameters
On April 4, 2004 at 13:49, Ken Hirsch wrote: The Text/Plain Format and DelSp Parameters. It adds an extra parameter, Del sp, to Content-type: text/plain. ... All keep this in mind for a future release. The next release of MHonArc has been in the queue for too long and I have yet to make the release. I initially planned to do a release at the end of last year, but the security compromise of Savannah delayed it. CVS tree has been moved off of savannah and everything looks okay. I've been busy with work related matters, so the next release has been sidelined. I'll see if I can push one out this weekend so requests like yours can be worked on. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bugs #8982] Can't use global $1 in my at base64.pl
This mail is an automated notification from the bugs tracker of the project: MHonArc. /**/ [bugs #8982] Latest Modifications: Changes by: Earl Hood [EMAIL PROTECTED] 'Date: Mon 05/17/04 at 06:14 (US/Central) What | Removed | Added --- Status | Open | Closed Fixed Release | CVS | 2.6.10 /**/ [bugs #8982] Full Item Snapshot: URL: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=8982 Project: MHonArc Submitted by: Earl Hood On: Mon 05/17/04 at 04:15 Category: None Severity: 7 - Major Item Group: Crash Error Resolution: Fixed Assigned to: None Status: Closed Platform Version: All Perl Version: =5.005 Component Version: 2.6.9 Fixed Release: 2.6.10 Summary: Can't use global $1 in my at base64.pl Original Submission: Older versions of perl will error out with something like the following message: Can't use global $1 in my at /usr/perl5/site_perl/5.005/base64.pl line 55, Follow-up Comments -- --- Date: Mon 05/17/04 at 04:18 By: ehood Stupid haste error. Apparently new versions of perl only generate a warning while older version will error out. Reason the error was not caught during the release process. Bogus my operators in base64.pl removed. Changes checked into CVS. For detailed info, follow this link: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=8982 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bugs #8866] spammode doesn't hide all addresses
This mail is an automated notification from the bugs tracker of the project: MHonArc. /**/ [bugs #8866] Latest Modifications: Changes by: Earl Hood [EMAIL PROTECTED] 'Date: Mon 05/17/04 at 04:36 (US/Central) What | Removed | Added --- Resolution | None | Fixed Status | Open | Closed Fixed Release | | 2.6.9 -- Additional Follow-up Comments Mail-followup-to is recognized in 2.6.9, and later. /**/ [bugs #8866] Full Item Snapshot: URL: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=8866 Project: MHonArc Submitted by: 0 On: Mon 05/10/04 at 20:59 Category: None Severity: 5 - Average Item Group: None Resolution: Fixed Assigned to: None Status: Closed Platform Version: All Perl Version: 5.8.4 Component Version: 2.6.8 Fixed Release: 2.6.9 Summary: spammode doesn't hide all addresses Original Submission: It doesn't hide for example Mail-followup-to header, see: http://lists-archive.pld-linux.org/html/pld-devel-pl/2004-05/msg1.html Follow-up Comments -- --- Date: Mon 05/17/04 at 04:36 By: ehood Mail-followup-to is recognized in 2.6.9, and later. For detailed info, follow this link: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=8866 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bugs #8183] wrong url parse
This mail is an automated notification from the bugs tracker of the project: MHonArc. /**/ [bugs #8183] Latest Modifications: Changes by: Earl Hood [EMAIL PROTECTED] 'Date: Mon 05/17/04 at 04:29 (US/Central) What | Removed | Added --- Severity | 5 - Average | 1 - None Resolution | None | Later Platform Version | Linux | All Component Version | none | All -- Additional Follow-up Comments [Limitation] Not sure if I will fix this. The occurence of the ']' characters is allowed within a URL, so the auto-linking is working as designed. To fix, would require per scheme-based detection checks. And for email, since '[' and ']' are legal characters in an email address (if the domain portion is an IP address), then per scheme checks would have to have some smarts. Not sure it is worth the effort. /**/ [bugs #8183] Full Item Snapshot: URL: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=8183 Project: MHonArc Submitted by: 0 On: Thu 03/18/04 at 09:26 Category: Mail Parsing Severity: 1 - None Item Group: Incorrect Behavior Resolution: Later Assigned to: None Status: Open Platform Version: All Perl Version: 5.6.1 Component Version: All Fixed Release: Summary: wrong url parse Original Submission: http://www.mhonarc.org/archive/html/mhonarc-users/2004-03/msg00063.html [mailto:[EMAIL PROTECTED] Behalf Of Lyle Schofield create wrong href tag Follow-up Comments -- --- Date: Mon 05/17/04 at 04:29 By: ehood [Limitation] Not sure if I will fix this. The occurence of the ']' characters is allowed within a URL, so the auto-linking is working as designed. To fix, would require per scheme-based detection checks. And for email, since '[' and ']' are legal characters in an email address (if the domain portion is an IP address), then per scheme checks would have to have some smarts. Not sure it is worth the effort. For detailed info, follow this link: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=8183 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bugs #8982] Can't use global $1 in my at base64.pl
This mail is an automated notification from the bugs tracker of the project: MHonArc. /**/ [bugs #8982] Latest Modifications: Changes by: Earl Hood [EMAIL PROTECTED] 'Date: Mon 05/17/04 at 04:19 (US/Central) What | Removed | Added --- Resolution | None | Fixed /**/ [bugs #8982] Full Item Snapshot: URL: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=8982 Project: MHonArc Submitted by: Earl Hood On: Mon 05/17/04 at 04:15 Category: None Severity: 7 - Major Item Group: Crash Error Resolution: Fixed Assigned to: None Status: Open Platform Version: All Perl Version: =5.005 Component Version: 2.6.9 Fixed Release: CVS Summary: Can't use global $1 in my at base64.pl Original Submission: Older versions of perl will error out with something like the following message: Can't use global $1 in my at /usr/perl5/site_perl/5.005/base64.pl line 55, Follow-up Comments -- --- Date: Mon 05/17/04 at 04:18 By: ehood Stupid haste error. Apparently new versions of perl only generate a warning while older version will error out. Reason the error was not caught during the release process. Bogus my operators in base64.pl removed. Changes checked into CVS. For detailed info, follow this link: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=8982 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bugs #8982] Can't use global $1 in my at base64.pl
This mail is an automated notification from the bugs tracker of the project: MHonArc. /**/ [bugs #8982] Latest Modifications: Changes by: Earl Hood [EMAIL PROTECTED] 'Date: Mon 05/17/04 at 04:18 (US/Central) What | Removed | Added --- Fixed Release | | CVS -- Additional Follow-up Comments Stupid haste error. Apparently new versions of perl only generate a warning while older version will error out. Reason the error was not caught during the release process. Bogus my operators in base64.pl removed. Changes checked into CVS. /**/ [bugs #8982] Full Item Snapshot: URL: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=8982 Project: MHonArc Submitted by: Earl Hood On: Mon 05/17/04 at 04:15 Category: None Severity: 7 - Major Item Group: Crash Error Resolution: None Assigned to: None Status: Open Platform Version: All Perl Version: =5.005 Component Version: 2.6.9 Fixed Release: CVS Summary: Can't use global $1 in my at base64.pl Original Submission: Older versions of perl will error out with something like the following message: Can't use global $1 in my at /usr/perl5/site_perl/5.005/base64.pl line 55, Follow-up Comments -- --- Date: Mon 05/17/04 at 04:18 By: ehood Stupid haste error. Apparently new versions of perl only generate a warning while older version will error out. Reason the error was not caught during the release process. Bogus my operators in base64.pl removed. Changes checked into CVS. For detailed info, follow this link: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=8982 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bugs #8982] Can't use global $1 in my at base64.pl
This mail is an automated notification from the bugs tracker of the project: MHonArc. /**/ [bugs #8982] Full Item Snapshot: URL: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=8982 Project: MHonArc Submitted by: Earl Hood On: Mon 05/17/04 at 04:15 Category: None Severity: 7 - Major Item Group: Crash Error Resolution: None Assigned to: None Status: Open Platform Version: All Perl Version: =5.005 Component Version: 2.6.9 Fixed Release: Summary: Can't use global $1 in my at base64.pl Original Submission: Older versions of perl will error out with something like the following message: Can't use global $1 in my at /usr/perl5/site_perl/5.005/base64.pl line 55, For detailed info, follow this link: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=8982 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[bugs #9050] Errors converting single MH messages
This mail is an automated notification from the bugs tracker of the project: MHonArc. /**/ [bugs #9050] Latest Modifications: Changes by: Earl Hood [EMAIL PROTECTED] 'Date: Sat 05/22/04 at 16:50 (US/Central) What | Removed | Added --- Resolution | None | Fixed Fixed Release | | CVS -- Additional Follow-up Comments Looks like problem is only for Windows systems. I committed changed to mhmimetypes.pl into CVS that should fix this problem. /**/ [bugs #9050] Full Item Snapshot: URL: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=9050 Project: MHonArc Submitted by: 0 On: Fri 05/21/04 at 18:59 Category: MIME Filter Severity: 5 - Average Item Group: Incorrect Behavior Resolution: Fixed Assigned to: None Status: Open Platform Version: Win32 Perl Version: 5.8.3 Component Version: 5.8.3 Fixed Release: CVS Summary: Errors converting single MH messages Original Submission: I use a text-based mail reader, but run MHonArc -single on individual mail messages that require a more robust HTML display. This had been working very well with MHonArc 5.6.8, but when I recently upgraded to 5.6.10, I started seeing this error for many of the messages I tried to display: Trailing in regex m// at C:Perlsitelib/mhmimetypes.pl line 366, GEN0 line 40. I've attached the Perl script I use to pass the message to MHonArc and to start a browser window. Thanks, -pd Follow-up Comments -- --- Date: Sat 05/22/04 at 16:50 By: ehood Looks like problem is only for Windows systems. I committed changed to mhmimetypes.pl into CVS that should fix this problem. --- Date: Fri 05/21/04 at 19:04 By: None Here's an example mail message that exhibits the problem. This fails from the command line also. -pd File Attachments --- --- Date: Fri 05/21/04 at 19:04 Name: 18660 Size: 36KB By: None Sample message which fails with MHonArc 5.6.10 http://savannah.nongnu.org/bugs/download.php?item_id=9050amp;item_file_id=1332 --- Date: Fri 05/21/04 at 18:59 Name: scmshow.pl Size: 904KB By: None Perl script to run selected message through MHonArc http://savannah.nongnu.org/bugs/download.php?item_id=9050amp;item_file_id=1331 For detailed info, follow this link: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=9050 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[bugs #9050] Errors converting single MH messages
This mail is an automated notification from the bugs tracker of the project: MHonArc. /**/ [bugs #9050] Latest Modifications: Changes by: Earl Hood [EMAIL PROTECTED] 'Date: Wed 08/18/2004 at 18:18 (US/Central) -- Additional Follow-up Comments The CVS repository on Savannah is not currently being used due to funtional limitations imposed after the security breach months ago. Snapshot distributions are available at http://www.mhonarc.org/release/MHonArc/dist/ /**/ [bugs #9050] Full Item Snapshot: URL: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=9050 Project: MHonArc Submitted by: 0 On: Fri 05/21/2004 at 18:59 Category: MIME Filter Severity: 5 - Average Item Group: Incorrect Behavior Resolution: Fixed Assigned to: None Status: Open Platform Version: Win32 Perl Version: 5.8.3 Component Version: 5.8.3 Fixed Release: CVS Summary: Errors converting single MH messages Original Submission: I use a text-based mail reader, but run MHonArc -single on individual mail messages that require a more robust HTML display. This had been working very well with MHonArc 5.6.8, but when I recently upgraded to 5.6.10, I started seeing this error for many of the messages I tried to display: Trailing in regex m// at C:Perlsitelib/mhmimetypes.pl line 366, GEN0 line 40. I've attached the Perl script I use to pass the message to MHonArc and to start a browser window. Thanks, -pd Follow-up Comments -- --- Date: Wed 08/18/2004 at 18:18 By: ehood The CVS repository on Savannah is not currently being used due to funtional limitations imposed after the security breach months ago. Snapshot distributions are available at http://www.mhonarc.org/release/MHonArc/dist/ --- Date: Tue 06/29/2004 at 09:07 By: None The patch is also archived here: http://www.mhonarc.org/archive/html/mhonarc-commits/2004-05/msg5.html --- Date: Tue 06/29/2004 at 07:01 By: None I've encountered the same error converting mboxes with various attachments. I'd appreciate the patch but I only see up to 1.19 in the CVS :( --- Date: Tue 06/22/2004 at 17:23 By: None I check the cvs repository and the version with the change does not appear there... --- Date: Sat 05/22/2004 at 16:50 By: ehood Looks like problem is only for Windows systems. I committed changed to mhmimetypes.pl into CVS that should fix this problem. --- Date: Fri 05/21/2004 at 19:04 By: None Here's an example mail message that exhibits the problem. This fails from the command line also. -pd File Attachments --- --- Date: Fri 05/21/2004 at 19:04 Name: 18660 Size: 36.62KB By: None Sample message which fails with MHonArc 5.6.10 http://savannah.nongnu.org/bugs/download.php?item_id=9050amp;item_file_id=1332 --- Date: Fri 05/21/2004 at 18:59 Name: scmshow.pl Size: 904B By: None Perl script to run selected message through MHonArc http://savannah.nongnu.org/bugs/download.php?item_id=9050amp;item_file_id=1331 For detailed info, follow this link: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=9050 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[bugs #9050] Regex abort error in mhmimetypes.pl under Win32
This mail is an automated notification from the bugs tracker of the project: MHonArc. /**/ [bugs #9050] Latest Modifications: Changes by: Earl Hood [EMAIL PROTECTED] 'Date: Wed 11/17/2004 at 19:51 (US/Central) What | Removed | Added --- Summary | Errors converting single MH messages | Regex abort error in mhmimetypes.pl under Win32 /**/ [bugs #9050] Full Item Snapshot: URL: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=9050 Project: MHonArc Submitted by: 0 On: Fri 05/21/2004 at 18:59 Category: MIME Filter Severity: 5 - Average Item Group: Incorrect Behavior Resolution: Fixed Privacy: Public Assigned to: None Status: Open Platform Version: Win32 Perl Version: 5.8.3 Component Version: 5.8.3 Fixed Release: CVS Summary: Regex abort error in mhmimetypes.pl under Win32 Original Submission: I use a text-based mail reader, but run MHonArc -single on individual mail messages that require a more robust HTML display. This had been working very well with MHonArc 5.6.8, but when I recently upgraded to 5.6.10, I started seeing this error for many of the messages I tried to display: Trailing in regex m// at C:Perlsitelib/mhmimetypes.pl line 366, GEN0 line 40. I've attached the Perl script I use to pass the message to MHonArc and to start a browser window. Thanks, -pd Follow-up Comments -- --- Date: Wed 08/18/2004 at 18:18 By: Earl Hood ehood The CVS repository on Savannah is not currently being used due to funtional limitations imposed after the security breach months ago. Snapshot distributions are available at http://www.mhonarc.org/release/MHonArc/dist/ --- Date: Tue 06/29/2004 at 09:07 By: 0 None The patch is also archived here: http://www.mhonarc.org/archive/html/mhonarc-commits/2004-05/msg5.html --- Date: Tue 06/29/2004 at 07:01 By: 0 None I've encountered the same error converting mboxes with various attachments. I'd appreciate the patch but I only see up to 1.19 in the CVS :( --- Date: Tue 06/22/2004 at 17:23 By: 0 None I check the cvs repository and the version with the change does not appear there... --- Date: Sat 05/22/2004 at 16:50 By: Earl Hood ehood Looks like problem is only for Windows systems. I committed changed to mhmimetypes.pl into CVS that should fix this problem. --- Date: Fri 05/21/2004 at 19:04 By: 0 None Here's an example mail message that exhibits the problem. This fails from the command line also. -pd File Attachments --- --- Date: Fri 05/21/2004 at 19:04 Name: 18660 Size: 36.62KB By: None Sample message which fails with MHonArc 5.6.10 http://savannah.nongnu.org/bugs/download.php?item_id=9050amp;item_file_id=1332 --- Date: Fri 05/21/2004 at 18:59 Name: scmshow.pl Size: 904B By: None Perl script to run selected message through MHonArc http://savannah.nongnu.org/bugs/download.php?item_id=9050amp;item_file_id=1331 For detailed info, follow this link: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=9050 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[bugs #11187] incorrectly parsing UTF-8 encoded messages
This mail is an automated notification from the bugs tracker of the project: MHonArc. /**/ [bugs #11187] Latest Modifications: Changes by: Earl Hood [EMAIL PROTECTED] 'Date: Thu 12/02/2004 at 00:36 (US/Central) -- Additional Follow-up Comments Can submitter please zip up sample message and send it to the author's address for evaluation? Or you can attach the bundle to this bug report if it is okay that the email message is readable by the public. Please also provide sample correct and incorrect conversion of the message. /**/ [bugs #11187] Full Item Snapshot: URL: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=11187 Project: MHonArc Submitted by: Egmont Koblinger On: Thu 12/02/2004 at 00:04 Category: Character Sets Severity: 5 - Average Item Group: Incorrect Behavior Resolution: None Privacy: Public Assigned to: None Status: Open Platform Version: Linux Perl Version: 5.8.5 Component Version: 2.6.10 Fixed Release: Summary: incorrectly parsing UTF-8 encoded messages Original Submission: I use mhonarc without any configuration file, just simply the command mhonarc -outdir outdir indir whereas indir only contains one file with one single message encoded in UTF-8. (Both the subject and the body contain UTF-8 encoded accented letters, the subject uses quoted-printable, the body's transfer encoding is 8-bit). The output html files are quite strange. For each UTF-8 byte sequence only the first byte is taken into account and it is converted to a html escape. For example, the Euro sign (U+20AC, UTF-8: E2 82 AC) will appear in the html output as #E2; and then 82 and AC are skipped, processing goes on with the next Unicode character. In MHonarc/CharEnt.pm line 153 there's a switch to check whether perl is new enough to support UTF-8. If it isn't, then manual processing of UTF-8 character takes place. Forcing the non-UTF-8-aware perl branch of the if statement (that is, changing the if ($] = 5.006) to if (0) repairs the problem, in this case the output will be the expected #20AC;. I don't think it matters, but I have LANG=hu_HU (latin2 locale) and no other LC_* variables set. However, UTF-8 locales are also available on my system. Follow-up Comments -- --- Date: Thu 12/02/2004 at 00:36 By: Earl Hood ehood Can submitter please zip up sample message and send it to the author's address for evaluation? Or you can attach the bundle to this bug report if it is okay that the email message is readable by the public. Please also provide sample correct and incorrect conversion of the message. For detailed info, follow this link: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=11187 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[bugs #9050] Regex abort error in mhmimetypes.pl under Win32
This mail is an automated notification from the bugs tracker of the project: MHonArc. /**/ [bugs #9050] Latest Modifications: Changes by: Earl Hood [EMAIL PROTECTED] 'Date: Thu 12/02/2004 at 00:37 (US/Central) What | Removed | Added --- Component Version | 5.8.3 | 2.6.10 /**/ [bugs #9050] Full Item Snapshot: URL: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=9050 Project: MHonArc Submitted by: 0 On: Fri 05/21/2004 at 18:59 Category: MIME Filter Severity: 5 - Average Item Group: Incorrect Behavior Resolution: Fixed Privacy: Public Assigned to: None Status: Open Platform Version: Win32 Perl Version: 5.8.3 Component Version: 2.6.10 Fixed Release: CVS Summary: Regex abort error in mhmimetypes.pl under Win32 Original Submission: I use a text-based mail reader, but run MHonArc -single on individual mail messages that require a more robust HTML display. This had been working very well with MHonArc 5.6.8, but when I recently upgraded to 5.6.10, I started seeing this error for many of the messages I tried to display: Trailing in regex m// at C:Perlsitelib/mhmimetypes.pl line 366, GEN0 line 40. I've attached the Perl script I use to pass the message to MHonArc and to start a browser window. Thanks, -pd Follow-up Comments -- --- Date: Wed 08/18/2004 at 18:18 By: Earl Hood ehood The CVS repository on Savannah is not currently being used due to funtional limitations imposed after the security breach months ago. Snapshot distributions are available at http://www.mhonarc.org/release/MHonArc/dist/ --- Date: Tue 06/29/2004 at 09:07 By: 0 None The patch is also archived here: http://www.mhonarc.org/archive/html/mhonarc-commits/2004-05/msg5.html --- Date: Tue 06/29/2004 at 07:01 By: 0 None I've encountered the same error converting mboxes with various attachments. I'd appreciate the patch but I only see up to 1.19 in the CVS :( --- Date: Tue 06/22/2004 at 17:23 By: 0 None I check the cvs repository and the version with the change does not appear there... --- Date: Sat 05/22/2004 at 16:50 By: Earl Hood ehood Looks like problem is only for Windows systems. I committed changed to mhmimetypes.pl into CVS that should fix this problem. --- Date: Fri 05/21/2004 at 19:04 By: 0 None Here's an example mail message that exhibits the problem. This fails from the command line also. -pd File Attachments --- --- Date: Fri 05/21/2004 at 19:04 Name: 18660 Size: 36.62KB By: None Sample message which fails with MHonArc 5.6.10 http://savannah.nongnu.org/bugs/download.php?item_id=9050amp;item_file_id=1332 --- Date: Fri 05/21/2004 at 18:59 Name: scmshow.pl Size: 904B By: None Perl script to run selected message through MHonArc http://savannah.nongnu.org/bugs/download.php?item_id=9050amp;item_file_id=1331 For detailed info, follow this link: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=9050 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[bugs #11187] incorrectly parsing UTF-8 encoded messages
This mail is an automated notification from the bugs tracker of the project: MHonArc. /**/ [bugs #11187] Latest Modifications: Changes by: Earl Hood [EMAIL PROTECTED] 'Date: Fri 12/03/2004 at 18:42 (US/Central) -- Additional Follow-up Comments The sample patch provided is not applicable for 5.6.x since the Encode module is only available for 5.8.x and later. After some searching, it appears that adding the U0 specifier to unpack makes things work. I do not know fully understand why unpack requires this to get things to work, but it appears to fix the problem. I've attached a patch to this report. It will be checked into CVS after I can resolve some connectivity problems with the CVS server. /**/ [bugs #11187] Full Item Snapshot: URL: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=11187 Project: MHonArc Submitted by: Egmont Koblinger On: Thu 12/02/2004 at 00:04 Category: Character Sets Severity: 5 - Average Item Group: Incorrect Behavior Resolution: None Privacy: Public Assigned to: None Status: Open Platform Version: Linux Perl Version: 5.8.5 Component Version: 2.6.10 Fixed Release: Summary: incorrectly parsing UTF-8 encoded messages Original Submission: I use mhonarc without any configuration file, just simply the command mhonarc -outdir outdir indir whereas indir only contains one file with one single message encoded in UTF-8. (Both the subject and the body contain UTF-8 encoded accented letters, the subject uses quoted-printable, the body's transfer encoding is 8-bit). The output html files are quite strange. For each UTF-8 byte sequence only the first byte is taken into account and it is converted to a html escape. For example, the Euro sign (U+20AC, UTF-8: E2 82 AC) will appear in the html output as #E2; and then 82 and AC are skipped, processing goes on with the next Unicode character. In MHonarc/CharEnt.pm line 153 there's a switch to check whether perl is new enough to support UTF-8. If it isn't, then manual processing of UTF-8 character takes place. Forcing the non-UTF-8-aware perl branch of the if statement (that is, changing the if ($] = 5.006) to if (0) repairs the problem, in this case the output will be the expected #20AC;. I don't think it matters, but I have LANG=hu_HU (latin2 locale) and no other LC_* variables set. However, UTF-8 locales are also available on my system. Follow-up Comments -- --- Date: Fri 12/03/2004 at 18:42 By: Earl Hood ehood The sample patch provided is not applicable for 5.6.x since the Encode module is only available for 5.8.x and later. After some searching, it appears that adding the U0 specifier to unpack makes things work. I do not know fully understand why unpack requires this to get things to work, but it appears to fix the problem. I've attached a patch to this report. It will be checked into CVS after I can resolve some connectivity problems with the CVS server. --- Date: Thu 12/02/2004 at 19:28 By: 0 None Sample patch follows that fixes the problem. It's just a case study to show what the problem is, depending on the Encode module may not be nice and I have no idea whether it's supported in older perls. (Note that I'm absolute beginner in perl.) The problem is that when unpack is executed in line 159 (according to the original 2.6.10 source) then its parameter ($1) is just a sequence of bytes and perl has no idea that it should be interpreted as utf8. Hence I guess it interprets it according to latin1 and that's why unpack doesn't do what we need. Before using unpack we have to tell perl hey that's an utf8 string. --- Date: Thu 12/02/2004 at 00:58 By: Egmont Koblinger egmont I attach a test case. This doesn't only happen for one particular message but rather for every message I write with mutt using UTF-8 encoding so it's not a problem to generate a publicly visible test case. Both the subject and the body contain the following string: asdf then e acute (both latin1 and 2) then e grave (only latin1) then o doubleacute (only latin2) then an euro sign (neither latin1 nor latin2) followed by jkl;. The input directory contains the message. The output-actual directory was generated with mainstream mhonarc 2.6.10 using mhonarc -outdir output-actual input. Similarly output-expected was generated with mhonarc patched as described above. All this packed into a single tarball. --- Date: Thu 12/02/2004 at 00:36 By: Earl Hood ehood Can submitter please zip up sample message and send it to the author's address for evaluation? Or you can attach
[bugs #11207] usenameext option to m2h_external::filter has no effect
This mail is an automated notification from the bugs tracker of the project: MHonArc. /**/ [bugs #11207] Full Item Snapshot: URL: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=11207 Project: MHonArc Submitted by: Earl Hood On: Fri 12/03/2004 at 19:44 Category: MIME Filter Severity: 5 - Average Item Group: Incorrect Behavior Resolution: None Privacy: Public Assigned to: None Status: Open Platform Version: All Perl Version: All Component Version: 2.6.10 Fixed Release: Summary: usenameext option to m2h_external::filter has no effect Original Submission: Problem reported by Dave Shepherd to mhonarc-users list. See http://www.mhonarc.org/archive/cgi-bin/mesg.cgi?a=mhonarc-usersi=81A95FFFB8332F468D948BBD7AD9B9602501BB%40xbt.ad.emulex.com for original post. A patch for mhexternal.pl that addresses this problem has been attached to this bug report. File Attachments --- --- Date: Fri 12/03/2004 at 19:44 Name: mhexternal-usenameext-fix.patch Size: 770B By: ehood mhexternal.pl patch to fix usenameext bug http://savannah.nongnu.org/bugs/download.php?item_id=11207amp;item_file_id=1939 For detailed info, follow this link: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=11207 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[bugs #11207] usenameext option to m2h_external::filter has no effect
This mail is an automated notification from the bugs tracker of the project: MHonArc. /**/ [bugs #11207] Latest Modifications: Changes by: Earl Hood [EMAIL PROTECTED] 'Date: Fri 12/03/2004 at 20:38 (US/Central) What | Removed | Added --- Resolution | None | Fixed Fixed Release | | CVS -- Additional Follow-up Comments Fix committed into CVS. /**/ [bugs #11207] Full Item Snapshot: URL: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=11207 Project: MHonArc Submitted by: Earl Hood On: Fri 12/03/2004 at 19:44 Category: MIME Filter Severity: 5 - Average Item Group: Incorrect Behavior Resolution: Fixed Privacy: Public Assigned to: None Status: Open Platform Version: All Perl Version: All Component Version: 2.6.10 Fixed Release: CVS Summary: usenameext option to m2h_external::filter has no effect Original Submission: Problem reported by Dave Shepherd to mhonarc-users list. See http://www.mhonarc.org/archive/cgi-bin/mesg.cgi?a=mhonarc-usersi=81A95FFFB8332F468D948BBD7AD9B9602501BB%40xbt.ad.emulex.com for original post. A patch for mhexternal.pl that addresses this problem has been attached to this bug report. Follow-up Comments -- --- Date: Fri 12/03/2004 at 20:38 By: Earl Hood ehood Fix committed into CVS. File Attachments --- --- Date: Fri 12/03/2004 at 19:44 Name: mhexternal-usenameext-fix.patch Size: 770B By: ehood mhexternal.pl patch to fix usenameext bug http://savannah.nongnu.org/bugs/download.php?item_id=11207amp;item_file_id=1939 For detailed info, follow this link: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=11207 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[bugs #11187] incorrectly parsing UTF-8 encoded messages
This mail is an automated notification from the bugs tracker of the project: MHonArc. /**/ [bugs #11187] Latest Modifications: Changes by: Earl Hood [EMAIL PROTECTED] 'Date: Fri 12/03/2004 at 20:41 (US/Central) What | Removed | Added --- Resolution | None | Fixed Fixed Release | | CVS -- Additional Follow-up Comments Fix checked into CVS. /**/ [bugs #11187] Full Item Snapshot: URL: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=11187 Project: MHonArc Submitted by: Egmont Koblinger On: Thu 12/02/2004 at 00:04 Category: Character Sets Severity: 5 - Average Item Group: Incorrect Behavior Resolution: Fixed Privacy: Public Assigned to: None Status: Open Platform Version: Linux Perl Version: 5.8.5 Component Version: 2.6.10 Fixed Release: CVS Summary: incorrectly parsing UTF-8 encoded messages Original Submission: I use mhonarc without any configuration file, just simply the command mhonarc -outdir outdir indir whereas indir only contains one file with one single message encoded in UTF-8. (Both the subject and the body contain UTF-8 encoded accented letters, the subject uses quoted-printable, the body's transfer encoding is 8-bit). The output html files are quite strange. For each UTF-8 byte sequence only the first byte is taken into account and it is converted to a html escape. For example, the Euro sign (U+20AC, UTF-8: E2 82 AC) will appear in the html output as #E2; and then 82 and AC are skipped, processing goes on with the next Unicode character. In MHonarc/CharEnt.pm line 153 there's a switch to check whether perl is new enough to support UTF-8. If it isn't, then manual processing of UTF-8 character takes place. Forcing the non-UTF-8-aware perl branch of the if statement (that is, changing the if ($] = 5.006) to if (0) repairs the problem, in this case the output will be the expected #20AC;. I don't think it matters, but I have LANG=hu_HU (latin2 locale) and no other LC_* variables set. However, UTF-8 locales are also available on my system. Follow-up Comments -- --- Date: Fri 12/03/2004 at 20:41 By: Earl Hood ehood Fix checked into CVS. --- Date: Fri 12/03/2004 at 20:11 By: 0 None Yes, your patch is definitely nicer than my one. I told you I'm beginner in perl :-) Thanks for the fix! --- Date: Fri 12/03/2004 at 18:42 By: Earl Hood ehood The sample patch provided is not applicable for 5.6.x since the Encode module is only available for 5.8.x and later. After some searching, it appears that adding the U0 specifier to unpack makes things work. I do not know fully understand why unpack requires this to get things to work, but it appears to fix the problem. I've attached a patch to this report. It will be checked into CVS after I can resolve some connectivity problems with the CVS server. --- Date: Thu 12/02/2004 at 19:28 By: 0 None Sample patch follows that fixes the problem. It's just a case study to show what the problem is, depending on the Encode module may not be nice and I have no idea whether it's supported in older perls. (Note that I'm absolute beginner in perl.) The problem is that when unpack is executed in line 159 (according to the original 2.6.10 source) then its parameter ($1) is just a sequence of bytes and perl has no idea that it should be interpreted as utf8. Hence I guess it interprets it according to latin1 and that's why unpack doesn't do what we need. Before using unpack we have to tell perl hey that's an utf8 string. --- Date: Thu 12/02/2004 at 00:58 By: Egmont Koblinger egmont I attach a test case. This doesn't only happen for one particular message but rather for every message I write with mutt using UTF-8 encoding so it's not a problem to generate a publicly visible test case. Both the subject and the body contain the following string: asdf then e acute (both latin1 and 2) then e grave (only latin1) then o doubleacute (only latin2) then an euro sign (neither latin1 nor latin2) followed by jkl;. The input directory contains the message. The output-actual directory was generated with mainstream mhonarc 2.6.10 using mhonarc -outdir output-actual input. Similarly output-expected was generated with mhonarc patched as described above. All this packed into a single tarball. --- Date: Thu 12
[approved] [bug #11761] spammode causes broken mailto: links in message body
Follow-up Comment #1, bug #11761 (project mhonarc): The nourl option to m2h_text_plain::filter will prevent the creation of mailto links, but it will also prevent making other URLs into links. A possible solution is to update the filter to allow one to specify which URLs will be hyperlinked. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=11761 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bug #11762] rel=nofollow attribute support in message body hyperlinks
Follow-up Comment #1, bug #11762 (project mhonarc): Looks like an easy feature to add. Will look into it. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=11762 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: Determing Threads
On April 18, 2005 at 20:19, East Coast Coder wrote: Hi. I'm trying to orient myself to the MHonArc source code. Good luck. One thing that I'm getting stuck with is: Are unique indexes assigned to threads? If so, when I'm in output_mail, can I access this message's thread ID (how)? There are no thread IDs. There are relationships for follow-up and and references for a given message. The relationship tree can be walked to get the complete thread (or the root). If not, what would be the best way to do this (that is, assign a unique id to each thread, and be able to access it within the output_mail() sub)? Have you looked at the $TSLICE$ resource variable? I.e. If you provide more info on what you are trying to do, there may already be features that do what you need. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: Determing Threads
On April 18, 2005 at 20:19, East Coast Coder wrote: PS One more question: Is there any functionality built in to determine when one message is quoting another, and, let's say, highlight it differently? There are quoting highlighting features in the plain text filter. See the MIMEFILTERS resource for more info, mainly the m2h_text_plain::filter filter. If you want the ability to know exactly which message is being quoted, this is an AI problem. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: Determing Threads
On April 19, 2005 at 19:37, East Coast Coder wrote: Have you looked at the $TSLICE$ resource variable? I.e. If you provide more info on what you are trying to do, there may already be features that do what you need. I'm experimenting with a format where, instead of rebuilding the entire tree, new messages are output incrementally. I think this would be necessary for using MHonArc for formats other than HTML archives (RSS feeds, perhaps, or text messages). I'd like to be able to process a mbox, take the new messages, and output them - but identify each message with a unique id to its thread, so that the final output device (aggregator, phone, whatever) can associate it. Mhonarc does not assume that it will process messages in the correct order. For example, a follow-up to a message may be processed before its reference(s). Also, mhonarc was initially coded in Perl 4, so leveraging complex data structures was not necessarily trivial. Therefore, mhonarc just recomputes threads after each update to an archive. There may be ways to optimize threading computation with the existing code base, but I have not bothered to look into it. Some of the main hash structures have been Perl 5'ed, but in general, most of mhonarc's data structures are flat. As for your immediate need, you can write a wrapper program that invokes mhonarc for the main work and then does some post-processing to get what you need. With the minimal API facilities of mhonarc, you can determine which messages are new. You will need to maintain your own thread IDs. A simple map can be used to maintain the message to thread ID association. Thread ID generation can be a simple counter. You can check out the mha-preview program in the examples/ directory of the mhonarc distribution for an example of how to develop a wrapper program. Your wrapper will require some more knowledge of the internals of mhonarc that is not documented in the API appendix of the docs. You can examine the library mhinit.pl for a list of the internal data structures used by mhonarc. The ones under Message information variables will probably be of the most interest to you. You can even examine the .mhonarc.db file of an archive to get a clearer picture of how the various hashes are structured. Side Note: I like the idea of having thread IDs. Something to consider if/when mhonarc is rewritten, and maybe something possible with the existing code base. Mhonarc is an old program and various users are definitely hitting up against its limitations. Motivation is my main enemy in doing a complete re-implementation. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: Determing Threads
On April 20, 2005 at 23:36, East Coast Coder wrote: Earl - wow, didn't catch those - very nice. If someone wanted to apply those filters to html messages (that is, very often, even a message coded in text/html will use 's and not blockquote), what path would you recommend? Quoting is part of the message body itself, not something mhonarc does. What the text/plain filter does is detect if quoting is used, and if so, can perform special highlighting of quoted text (similiar to how modern MUAs operate). Therefore, for HTML messages, any quoting will part of the message body itself. From my experience, HTML-aware MUAs already markup quoted text, so mhonarc really has nothing to do. To summarize, quoting is a function of the originating MUA and not mhonarc. For text/plain messages, mhonarc is able to provide special rendering of text that is quoted. For HTML messages, it is up to the originating MUA to provide any quoted highlighted. Note: If you want mhonarc to translate ''s in HTML messages into blockquote, then you need to write your own filter (see MIMEFILTERS). Personally, I do not think it is worth the effort, but your needs may differ. You can use the m2h_text_html::filter as a template for your own, or even better, create a wrapper filter to it. See http://www.mhonarc.org/archive/cgi-bin/mesg.cgi?a=mhonarc-usersi=200309161616.h8GGGc008461%40gator.earlhood.com for more information about wrapper filters. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bug #12802] SubjectStripCode not working on message file
Update of bug #12802 (project mhonarc):
Status: Need Info = Confirmed
___
Follow-up Comment #4:
I understand now what you are reporting. I agree, the behavior
is inconsistent to what a user may expect.
The routing that converts the message header fields into html
works on the $fields hash directly, and since SUBJECTSTRIPCODE
is not applied to $fields-{subject}, the original subject
text will be rendered.
It appears that the fix you suggested is the simpliest that
fixes the problem. I may add something that stores the
original subject in a special key of $fields for any
callback routines that may need it (and for potential
debugging purposes).
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?func=detailitemitem_id=12802
___
Message sent via/by Savannah
http://savannah.nongnu.org/
-
To sign-off this list, send email to [EMAIL PROTECTED] with the
message text UNSUBSCRIBE MHONARC-DEV
[approved] [bug #11762] rel=nofollow attribute support in message body hyperlinks
Update of bug #11762 (project mhonarc): Status:None = Fixed Platform Version: Linux = All Perl Version: 5.8.4 = All Fixed Release: = CVS ___ Follow-up Comment #2: Feature added to mhtxtplain.pl filter. Checked into CVS. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=11762 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bug #11762] rel=nofollow attribute support in message body hyperlinks
Follow-up Comment #3, bug #11762 (project mhonarc): Feature added to mhmsgextbody.pl filter and checked into CVS. Will see if it can be done for HTML message bodies. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=11762 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bug #11762] rel=nofollow attribute support in message body hyperlinks
Follow-up Comment #4, bug #11762 (project mhonarc): mhtxthtml.pl updated to add rel=nofollow to all a tags. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=11762 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bug #12802] SubjectStripCode not working on message file
Update of bug #12802 (project mhonarc): Status: Confirmed = Fixed Fixed Release: = CVS ___ Follow-up Comment #5: Fixed applied to mhamain.pl and checked into CVS. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=12802 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bug #11763] reverse indexes not suitable for search engines
Update of bug #11763 (project mhonarc): Status:None = Duplicate Open/Closed:Open = Closed ___ Follow-up Comment #1: This is really a duplicate of bug #372. Any additional info should be posted to that bug. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=11763 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bug #11759] email address exposed in subject line
Update of bug #11759 (project mhonarc): Status:None = Postponed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=11759 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bug #11761] spammode causes broken mailto: links in message body
Update of bug #11761 (project mhonarc): Status:None = Postponed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=11761 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bug #12930] Cross site scripting bug in m2h_text_html::filter
Update of bug #12930 (project mhonarc): Status:None = Fixed Fixed Release: = CVS ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=12930 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bug #12930] Cross site scripting bug in m2h_text_html::filter
Follow-up Comment #1, bug #12930 (project mhonarc): mhtxthtml.pl has been updated in CVS to escape vbscript and ecmascript. As for the other keywords, I'd like to have more information on what browsers (or other software) support such scheme in event handlers. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=12930 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bug #372] Links to thread index from message page do not link to the correct thread index page when MULTIPG and TREVERSE is active
Update of bug #372 (project mhonarc): Platform Version:None = All Perl Version: = All Component Version: = =2.6.10 ___ Follow-up Comment #1: Problem occurs for reverse date indexes also. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=372 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: Determing Threads
On May 6, 2005 at 02:13, East Coast Coder wrote: 1) Which file/sub does the initial determination if a message is a response or a new thread? mhthread.pl and mainly compute_threads() routine. Mhonarc initially stores any reference message IDs when a message is first read. The routines in mhthread.pl then use that information for determining threads. Note, the code is encumbered with relic Perl 4'isms, so it is not the prettiest. 2) For the threadid, I'd like to store it in MHonArc's own message.db. That is, I'd like to be able to use the db so for any messageid, we can retreive the threadid. Are there simple routines to add a new field to the db, and to retreive it given a messageid? (If not, I can always use another store, like sqllite or something, but I would not want to have to do this unless needed). Check out the mha-preview example script in the distro. It shows how to store and retrieve custom information in .mhonarc.db. 3) What is the best way to persist the counter? Again, can the message.db do this? Are there any race conditions to be wary of (doesn't seem like it, since MHonArc works in serial, and locks anyway - but I want to double check.) Mhonarc locks an archive when processing it to avoid stomping on itself. Depending on when you do your thing, you may need to do your own locking. I.e. If you hook into mhonarc during its own locking, then you do not need to do anything for locking. If you do things during a post-process stage (after mhonarc releases the lock), then you need to do your own thing. Since you are mentioning storing stuff into .mhonarc.db, then those operations will occur when an archive is locked, so you should be okay with using the db file for storing a counter. Of course, you could use an ID generation scheme that does not require locking so you are safe, regardless. A combination of date/time, process-id, hostname/ip, and a random string should be sufficient. Such a technique will be computationally slower than using a simple counter, but it may be negligable depending on your usage requirements. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bug #12512] Consecutive spaces not displayed in some cases
Update of bug #12512 (project mhonarc): Status:None = Ready For Test Perl Version: 2.6.8 = All Fixed Release: = CVS ___ Follow-up Comment #2: Flowed conversion code rewritten since previous code made a faulty assumption of what constituted a paragraph within the context of RFC-2646: Flowed and non-flowed paragraphs do not have to have a blank line separator. Therefore, new code processed each quoted chunk line-by-line vs by CRLF-CRLF separate paragraphs. Ran tests against my flowed example set, and it appears to generate consistent results with mozilla's rendering of the messages. Sample message provided by Jeff also checked for correct rendering. Changes checked into CVS. Encourage people to test changes with next snapshot build. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=12512 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bug #8183] wrong url parse
Update of bug #8183 (project mhonarc): Status: Postponed = Wont Fix ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=8183 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: Fwd: Bug#297007: @INC problems with mhonarc
On March 22, 2005 at 00:54, Jeff Breidenbach wrote: Full report is here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=297007 I fixed this by putting in: ## Check what system we are executing under push(@INC,'/usr/share/mhonarc'); require 'osinit.pl'; OSinit(); If mhonarc runs without error, then the problem is with mharc. Running mharc's install.pl with the -debug option may help in diagnosing the problem. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Getting ready for new mhonarc release
A new release is long overdue, so I'd like to make a new release containing numerous bug fixes. So far, the following bugs have been addressed: Bug ID Summary -- 9050 Regex abort error in mhmimetypes.pl under Win32 11187 incorrectly parsing UTF-8 encoded messages 11207 usenameext option to m2h_external::filter has no effect 11760 spammode false positives on some HTML mail 11762 rel=nofollow attribute support in message body hyperlinks 11977 TSLICETOPBEGCUR ignored 12512 Consecutive spaces not displayed in some cases 12802 SubjectStripCode not working on message file 12930 Cross site scripting bug in m2h_text_html::filter -- Before I make a new release, are there any bugs, features, documentation issues, and/or web site issues that I should address beforehand? I do request that those have a vested interested in the above bugs to please review the bug items on savannah, and if possible, test out the fixes. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
MHonArc Release: 2.6.11
Release 2.6.11 made in /mnt/WWW/customers/mhonarc.org/htdocs/release/MHonArc. http://www.mhonarc.org/release/MHonArc/ 2005/05/20 (2.6.11) * Bug Fixes: Bug ID Summary -- 9050 Regex abort error in mhmimetypes.pl under Win32 11187 incorrectly parsing UTF-8 encoded messages 11207 usenameext option to m2h_external::filter has no effect 11760 spammode false positives on some HTML mail 11762 rel=nofollow attribute support in message body hyperlinks 11977 TSLICETOPBEGCUR ignored 12512 Consecutive spaces not displayed in some cases 12802 SubjectStripCode not working on message file 12930 Cross site scripting bug in m2h_text_html::filter -- https://savannah.nongnu.org/bugs/?group=mhonarc - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: lots of UTF-8 warnings
On May 21, 2005 at 12:17, Jeff Breidenbach wrote:
I'm seeing a lot of UTF-8 warnings woth 2.6.11.
Is this expected?
perl v5.8.4, mhonarc 2.6.11
Malformed UTF-8 character (1 byte, need 3, after start byte 0xef) in
unpack at /usr/share/mhonarc/MHonArc/CharEnt.pm line 156.
Can you provide me with a sample message?
I did some looking into it when I responded to your first message,
and concluded that the warnings may be justified (albeit annoying).
However, to be thorough, I'll take a look at what you have.
From a coding perspective, a key item to examine is the UTF-8 regex
I use:
# Regex pattern for UTF-8 data
my $utf8_re = q/([\x00-\x7F]|
[\xC0-\xDF][\x80-\xBF]|
\xE0 [\xA0-\xBF][\x80-\xBF]|
[\xE1-\xEF][\x80-\xBF]{2}|
\xF0 [\x90-\xBF][\x80-\xBF]{2}|
[\xF1-\xF7][\x80-\xBF]{3}|
\xF8 [\x88-\xBF][\x80-\xBF]{3}|
[\xF9-\xFB][\x80-\xBF]{4}|
\xFC [\x84-\xBF][\x80-\xBF]{4}|
\xFD [\x80-\xBF]{5}|
.)/;
As you can see, '.' is included at the end. Therefore, the regex
will capture invalid utf-8 octets. In the warning message you
provided, it appears that the octet 0xEF occurs in the input, but it
is not followed by 2 octets in the range 0x80 to 0xBF (which defines
a valid utf-8 sequence).
Therefore, the 0xEF is captured by the '.' portion of the regex by
itself, and when passed into unpack(U0U*,...), perl generates
a warning.
One thing to consider is if having the '.' is warranted. If left
out, invalid utf-8 octets will be quietly ignored.
Alternatively, I try to modify the code to check for the invalid
sequence myself instead of blindly passing to unpack. I.e. If the
regex matches a single octet, check its value. If an 8-bit value,
quietly replace octet with invalid Unicode character entity reference
(#xFFFD).
--ewh
-
To sign-off this list, send email to [EMAIL PROTECTED] with the
message text UNSUBSCRIBE MHONARC-DEV
UTF-8 filtering in MHonArc (was Re: lots of UTF-8 warnings)
Jeff, I've been doing some more work on the utf-8 code in CharEnt.pm, and I believe I have a method for dealing with the malformed sequences without generating warning messages. Along with that, I'm trying to make the code more robust. I'm doing some testing, but there are some inconsistencies with different versions of Perl. I currently have Perl versions 5.6.1 and 5.8.0 installed, and noticed that unpack() behaves a little different between the two. I am downloading 5.8.6 to upgrade my 5.8.0 install to see if behavior changes, along with playing with mhonarc code to see if I can get some consistency and a better understanding of Perl's behavior. With unicode-ware Perl (=5.6), I am trying to convert malformed utf-8 sequences to U+FFFD, the recommended practice for dealing with malformed sequences. Doing this for Perl 5.6 may require more work since utf-8 handling is done with a homegrown method. I may leave that code as-is since I'm not sure it is worth the effort for older non-utf-8-aware versions of Perl. If users are concerned about robust utf-8 support, they should use the latest version of Perl. --ewh P.S. Is it wise to suppress the malformed utf-8 warning messages? If mhonarc can deal with the sequences in a proper manner, I'm not sure if there is any value in printing the warnings. - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: UTF-8 filtering in MHonArc
On May 22, 2005 at 11:59, Jeff Breidenbach wrote: I am downloading 5.8.6 to upgrade my 5.8.0 install to see if behavior changes, along with playing with mhonarc code to see if I can get some consistency and a better understanding of Perl's behavior. Please let me know how that goes. FYI, Debian Sarge ships with perl 5.8.4, but it isn't too hard for us to track some other version of perl, including perl 6. Have not messed with perl 6. I do not think there will be any differences between 5.8.4 and 5.8.6. The difference I saw were between 5.6.1 and 5.8.x. I discovered that I had to enable warnings (via the warnings pragma) to get perl 5.8 to be more strict about utf-8 decoding. 5.6.1 was strict by default. There is also some other minor subtleties, which I belive I have dealt with. Is it wise to suppress the malformed utf-8 warning messages? If mhonarc can deal with the sequences in a proper manner, I'm not sure if there is any value in printing the warnings. Good question. I generally don't like to have common-but-harmless warnings in log files, lest they obscure more serious problems. But I'm also quite capable of doing my own filtering. For example, I checked into CVS a new CharEnt.pm that suppressed the warning messages, along with converted malformed sequences into #xFFFD;, according to Unicode recommendations. I was even able to beef up the =5.006 code to be more robust about malformed sequences. If you want to try it out, grab the next snapshot build, or you can download the file from the newly added CVS source browsing at http://www.mhonarc.org/cgi-bin/viewcvs.cgi/*checkout*/mhonarc/MHonArc/lib/MHonArc/CharEnt.pm?rev=1.16. I currently filter out mhonarc's unrecognized character set warnings, since they are common and there's not much I can do about them. See the CHARSETALIASES resource. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Web browsing of MHonArc CVS tree is back
I have installed and configured ViewCVS at mhonarc.org to allow web browsing of the CVS tree. The URL is: http://www.mhonarc.org/cgi-bin/viewcvs.cgi/. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bug #12512] Consecutive spaces not displayed in some cases
Update of bug #12512 (project mhonarc): Status: Ready For Test = Fixed Open/Closed:Open = Closed Fixed Release: CVS = 2.6.11 ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=12512 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bug #12802] SubjectStripCode not working on message file
Update of bug #12802 (project mhonarc): Open/Closed:Open = Closed Fixed Release: CVS = 2.6.11 ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=12802 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bug #12930] Cross site scripting bug in m2h_text_html::filter
Update of bug #12930 (project mhonarc): Open/Closed:Open = Closed Perl Version: probably all... = All Fixed Release: CVS = 2.6.11 ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=12930 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bug #11977] TSLICETOPBEGCUR ignored
Update of bug #11977 (project mhonarc): Open/Closed:Open = Closed Fixed Release: CVS = 2.6.11 ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=11977 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bug #11762] rel=nofollow attribute support in message body hyperlinks
Update of bug #11762 (project mhonarc): Open/Closed:Open = Closed Fixed Release: CVS = 2.6.11 ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=11762 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bug #11760] spammode false positives on some HTML mail
Update of bug #11760 (project mhonarc): Status: Ready For Test = Fixed Open/Closed:Open = Closed Fixed Release: CVS = 2.6.11 ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=11760 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bug #11187] incorrectly parsing UTF-8 encoded messages
Update of bug #11187 (project mhonarc): Open/Closed:Open = Closed Fixed Release: CVS = 2.6.11 ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=11187 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[approved] [bug #8183] wrong url parse
Update of bug #8183 (project mhonarc): Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=8183 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: Using a SQL Database
On May 23, 2005 at 22:52, East Coast Coder wrote:
After much thought, it seems my needs of 1) ThreadID's and 2) High
performance, high capacity archives call for use of a regular SQL
database, rather than messages.db.
I'd still like to use Mhonarc to parse the mbox, and to parse the
individual messages and convert them to HTML. Just I'd like to be
able to hook it up to a SQL database (at least for the threadid,
subject, and references - possibly for the to: and from: also).
The least intrusive way is to utilize MHonArc's callback API to
get the information you need to load into your custom database.
For example, you can set the $mhonarc::CBMessageHeadRead callback
and extract the information you want to load into your database.
The API is described in the documenation in one of the appendix
section.
Some problems may arise depending on what you ultimately want to do.
For example, data in the .mhonarc.db file is needed for numerous
resource variables expansion. Therefore, if you disable the writing
of the .mhonarc.db file, many resource variables will not work.
Depending on your needs, you either customize page layout resource
to not require them (which means you would have to generate your own
index pages and nav links) or register a resource variable callback
(see API docs) to handle the expansion of resource variables (which
is probably a cumbersome task).
I have put some recent thought in what it would take to replace the
flat-file database file with something like Berkeley DB, but such
effort ripples through much of mhonarc's code base. Berkeley DB will
allow for scability, but much code will have to be changed (I think
doing tie tricks will not be sufficient).
If you want to minimize work, you could take the following approach:
* Use the callback API to load key information into your SQL database,
as noted above.
* Use period-based archives (e.g. monthly) to keep archive updates
manageable. This is how mharc works, and it is what other
users have done to make their archives scalable. The period
archives are sufficient for date-based navigation since the
boundaries do not matter (mharc uses a simple CGI program to provide
nav links between periods).
* Customize page layout resources that provide navigational links
based on your SQL data. Since threading is the big issue, you
can do something like the following:
- Disable thread index generation in mhonarc. Mainly because threads
will be broken at period boundaries. This is doable via a
resource setting.
- Remove mhonarc's built-in thread nav links in message pages (same
reason as previous item). This is doable via resource settings.
- Create your own custom thread indexes based upon your database
data. These indexes may be generated via CGI/dynamic programs
that query your database at runtime.
- Create your own thread nav links in messages pages based upon your
own database data. You can modify the page layout resource to
include markup to a CGI (or similiar) URL that determines next and
previous items by thread and/or view entire thread summary.
A subtle technical issue is resolving your database data to the
correct message file. I.e. In your threading code, you need to
know how to map to the correct filename/URL, and your code needs
to deal with the fact that message files may span multiple directories
(due to the period-based archive layout).
In your callback, you can use the $mhonarc::OUTDIR variable to get
the path specified to mhonarc when invoked. Therefore, when calling
mhonarc, make sure OUTDIR is set to a value that you can map to
valid URLs.
As for the base filename of the message, you will need to the message
number mhonarc will assign the message (remember, message file names
are based upon the message number). Unfortunately, the message number
is not explicitly provided to you when $mhonarc::CBMessageHeadRead
is invoked. To get the assigned message number, you can use
the following in your callback routine:
$msg_num = $mhonarc::LastMsgNum+1;
Assuming you are using the default resource values for message prefix
and suffix, you can get the filename with:
$msg_base_filename = sprintf('msg%05d.html', $msg_num);
The above approach does not remove the use of the .mhonarc.db files,
but it should deal with the scalability problem along with addressing
the functionality you desire.
If the above approach is not sufficient for your needs, then a more
detailed technical discussion is required, along with the consideration
of a major redesign/upgrade of the mhonarc code base.
--ewh
-
To sign-off this list, send email to [EMAIL PROTECTED] with the
message text UNSUBSCRIBE MHONARC-DEV
Re: Using a SQL Database
On June 1, 2005 at 13:12, East Coast Coder wrote:
I need mhonarc to do two things:
1) Parse the mbox format
2) Convert all of the content types into HTML
What I don't want is for mhonarc to save the results of #2 into a
file. I'd rather it hand it off to me (which it does, via the
callback), and let me handle saving it myself - I'm working on
nonstandard uses of it, as opposed to generating a collection of html
files.
Try passing the -noarchive option to mhonarc. I forgot about it,
but I added it in a long time ago. Basically, it should go through
the motions of processing a mailbox, but will keep any files from
getting written.
Exception: Attachments will get written. I am not sure if you are
dealing with attachments. I recommend utilizing the ATTACHMENTDIR
and ATTACHMENTURL resources. This way you can have all attachments
placed in a single location.
The ATTACHMENTURL is important for the converted message bodies so
the links to attachments will work.
You can suppress the creation of message pages by passing
the -nomsgpgs option to process_input(). Note, if you do use
-nomsgpgs, then the message bodies are completely skipped, bypassing
any callbacks related to message bodies.
This won't work for me - see above. So I guess I'll need to modify
the source a little bit. Any suggestions on the least invasive way to
do this?
I'm looking into it. The -noarchive may be all you need, but I can
see reasons why someone may want to exclude messages after the body
is processed (e.g. a spam/virus check). I've already made edits to my
working copy to allow CB{Raw}MessageBodyRead to return a false value to
exclude a message from further processing. However, I need to check if
code is needed to reverse some of the side-effects in read_mail_head().
Okay - I assume that not having a db won't cause a crash anywhere (of
course, the features that require it won't work).
One thing you need to do is do the already-processed check. I.e.
If you rescan a mailbox for new messages, you will need to make
sure you do not reprocess messages already archived. You should
easily be able to do this in CBMessageHeadRead.
--ewh
-
To sign-off this list, send email to [EMAIL PROTECTED] with the
message text UNSUBSCRIBE MHONARC-DEV
[bug #13276] Archive of mail lists does not text wrap in the Browser
Update of bug #13276 (project mhonarc): Status:None = Invalid Open/Closed:Open = Closed ___ Follow-up Comment #1: [Not a Bug] This is not a bug but a configuration issue of whomever maintains the archive. MHonArc provides options to deal with mis-behaved MUA's that do not properly format text messages. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=13276 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: br's in format=flowed
On June 3, 2005 at 03:38, Jeff Breidenbach wrote: Users complained about MHonarc 2.6.10 doing exactly this, since multiple spaces get consolidated down to a single space. This tends to corrupt things like ASCII art and python source code. I think there's a recenly closed bug entry on Savannah about this. Checkout https://savannah.nongnu.org/bugs/index.php?func=detailitemitem_id=12512. My follow-up comment contains the real reason for the problem. v2.6.11 contains the bug fix. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: br's in format=flowed
On June 3, 2005 at 11:36, East Coast Coder wrote: Couldn't this be solved simply by converting extra spaces to nbsp; 's? Please read MIMEFILTERS and search the list archives about format=flowed. The m2h_text_plain::filter describes how format=flowed is handled. If you believe there is a bug in how format=flowed is handled, please provide sample messages and submit a bug report. As an aside, it seems that format=flowed alone is pretty rare - most MUA's either send text/html as well (which mhonarc prefers) or text/plain fixed. Is this correct? Incorrect, format=flowed is reasonably common. I wasn't clear. The majority of the time that I have seen format=flowed, it is along with text/html - which mhonarc will prefer. How often do you see format=flowed by itself? See RFC-2646. Format=flowed has nothing to do with text/html. It is only applicable for text/plain messages. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: Shouldn't default setting of CHECKNOARCHIVE be on?
On June 2, 2005 at 21:06, East Coast Coder wrote: The default setting of CHECKNOARCHIVE is currently off. In my opinion, it should be on by default. Probably. Basically, unless you say explicitly that you want otherwise, shouldn't we honor author's wishes as well as the standards? The default is off for behavioral compatibility reasons. I.e. CHECKNOARCHIVE did not exist in early versions of MHonArc, so I wanted to avoid bogus bug reports about messages not getting archived. Many users are still unaware of the no-archive flag in messages. Switching the default to On is something to consider whenever the next major release (like 2.7) happens. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: Crashing on bad callback
On June 5, 2005 at 22:55, East Coast Coder wrote: While working on my callbacks, I noticed that, despite the require() call in mhasiteinit.pl, if there is a compilation problem in my callback file, mhonarc still runs, without a peep - leaving me clueless until I ]$ perl callback_file.pl to see that I introduced a compile error. First, did you run perl -c on your file? Always a good practice. I'm not a Perl junkie, so forgive me for my ignorance: is there a simple way to say that the callback file should be, um, *require*d, and that, if it doesn't compile, mhonarc should say so and quit? Currently, mhonarc ignores any errors in the requiring of mhasiteinit.pl. The reason is that mhasiteinit.pl support did not always exist in mhonarc. Therefore, the existence of it is not required (no pun intended). Therefore, to avoid bogus errors for most users, the return status of 'require' is ignored to avoid user confusion. For users that mess with mhasiteinit.pl, I figured they would at least check the syntax of the file first before trying to use it. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: Crashing on bad callback
On June 6, 2005 at 01:06, East Coast Coder wrote: Similiarly, just spent 25 minutes trying to figure out why my filters were being ignored till I realized that I mistyped the resource filename on the command line. Shouldn't a nonexistant -rcfile param trigger an error? Yep. Typos in mhonarc code prevents the warning message from being printed. I shall commit fixes. You can submit a bug report if you want to track the problem officially. --ewh - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[bug #13316] No warning generated when RCFILE set to non-existent filename
URL: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=13316 Summary: No warning generated when RCFILE set to non-existent filename Project: MHonArc Submitted by: ehood Submitted on: Mon 06/06/2005 at 20:58 Category: Resources Severity: 3 - Normal Item Group: Undesired Behavior Status: None Privacy: Public Assigned to: None Open/Closed: Open Platform Version: All Perl Version: All Component Version: 2.6.11 Fixed Release: ___ Details: Problem initially reported on mhonarc-dev list: http://www.mhonarc.org/archive/cgi-bin/mesg.cgi?a=mhonarc-devi=454651fd050605220660b0b3de%40mail.gmail.com ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=13316 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[bug #13317] POSIX::setlocale() not invoked with LANG resource setting
URL: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=13317 Summary: POSIX::setlocale() not invoked with LANG resource setting Project: MHonArc Submitted by: ehood Submitted on: Mon 06/06/2005 at 21:03 Category: Resources Severity: 3 - Normal Item Group: Incorrect Behavior Status: None Privacy: Public Assigned to: None Open/Closed: Open Platform Version: All Perl Version: All Component Version: =2.6.11 Fixed Release: ___ Details: Typo in mhopt.pl prevents POSIX::setlocale() from being invoked with the value of the LANG resource. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=13317 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[bug #13317] POSIX::setlocale() not invoked with LANG resource setting
Update of bug #13317 (project mhonarc): Status:None = Fixed Fixed Release: = CVS ___ Follow-up Comment #1: Typo corrected and checked into CVS. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=13317 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[bug #13316] No warning generated when RCFILE set to non-existent filename
Update of bug #13316 (project mhonarc): Open/Closed:Open = Closed Fixed Release: CVS = 2.6.12 ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=13316 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
