On Sat, Dec 3, 2011 at 4:00 PM, Tom <t...@hutch4.us> wrote: > Is Mhonarc not really supported any more or is this list dead?
This list is not dead, but does not get much traffic. As for size limits, mhonarc is limited to RAM since each message processed is loaded into memory. Not efficient, but that is a left-over from the initial code base. Making things more efficient would require a considerable rewrite of the core parsing code. There is the -savemem option that can be used to try to reduce the overall memory footprint (it keeps mhonarc from keeping a handle of all new message data in RAM), but it does slow things down due to more file I/O done. As for HTML processing, there is a history of performance issues with the regexes used to strip out markup that can cause security problems, with the possibility of much memory being consumed. This is somewhat an artifact of the regex and perl's regex engine, but I lack the knowledge of perl's regex internals. Attempts over time have been done to try to use regexes that will not trigger engine problems. IMO, HTML mail is horrendous, and the horrible lack of conformancy by major mail providers just contributes to the security problems HTML mail provides. The latest release clamped down on what HTML is acceptable since XSS vulnerability risk increases (and were proven) with previous releases. The FAQ provides information about the security problems of HTML mail, and how to mitigate it. If the solutions provided is not sufficient for your needs, mhonarc is explicitly designed to allow you to register your own handler for HTML messages, giving you full control of how the are processed. You can see if integrating a 3rd party HTML parsing engine can be used. I personally sick of dealing with the markup atrocities of HTML mail, and have no incentive in do any more work on it. However, patches or alternate filters are always welcome and will be considered to be included in mhonarc itself if such contributions have no adverse effects. --ewh