Mailscanner converting HTML messages with FORM tags

[Lancaster, David Matthew]

Quoting David Lee <t.d.lee at DURHAM.AC.UK>:

> On Wed, 22 Oct 2003, Lancaster, David Matthew wrote:
>
> > > > >Perhaps the Allow/Convert options could be restructured to something
> like
> > > > >this:?
> > > > >Allow Form Tags = { yes | convert | no}
> > > > >Allow Object Codebase Tags = { yes | convert | no}
> > > > >Allow IFrame Tags = { yes | convert | no}
> > > > >
> > > > >This would also allow further selection of criteria (e.g. javascript,
> > > etc)
> > > > as
> > > > >"Dangerous HTML", while still allowing a great deal of tuning.
> > > >
> > > > Would you like to be able to strip _all_ html out of some messages, or
> > > just
> > > > strip out a few specific tags from some messages? The latter is much
> > > harder.
> > >
> > > I don't currently have the need to strip out specific html...just to
> select
> > > which of the three criteria (iframe, obj codebase, form) will cause the
> > > message
> > > to be converted to plain text.
> > >
> > > D.
> > >
> >
> > Hate to be a pest, but any idea if this could be added to MailScanner?
> > I realize that MailScanner must keep you quite busy, so if it's not
> something
> > you're interested in looking at, I might take a peek at the code
> myself...but
> > it doesn't make sense for two people to be duplicating the work.
>
> If I understand it correctly, this revised behaviour and configuration
> also has my vote.  (We want to allow "forms" through unmolested, but to
> convert "object codebase".)
>
> The proposed "Allow <X>= { yes | convert | no}" would seem to achieve such
> flexibility with elegant simplicity and, further, to allow possible future
> extensions beyond the current set of three values for <X>.
>
> Further, one could also envisage (at least in theory) the possibility of
> two (or even more?) different conversions:
>    Allow <X>= { yes | no | convert-all | convert-tag }
>
> Julian:  If you agree in principle, then I'd be happy to work (albeit
> subject to the usual "local busy-ness constraints") with David Lancaster
> to try to implement this framework over the coming weeks.  (I took at
> quick peek yesterday at the relevant 4.24-5 code to see what might be
> needed.)

Sounds like a plan to me.  Julian appears to be pretty busy of late (know what
that's like...).

I'm hoping that Julian wouldn't have any problems with rolling the modifications
into the mainline distribution, to minimize the maintenance and since others
would probably find it useful.

D.