Re: Message body size limits? (Bigger Problem)

[Earl Hood <earl@xxxxxxxxxxxx>]

On Sat, Dec 3, 2011 at 4:00 PM, Tom <tom@xxxxxxxxx> 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