Re. embedded, *useful* HTML: Yes, that's my point about why I don't think
that it's a trivial problem (and hence, why if *I* were responsible for
solving it, people probably wouldn't be happy).

Note, however, that you can cite a URL without using HTML.  In fact, this
is the best way to do it, IMHO.

On reflection, I think that HTML-bouncing is a relatively trivial problem
to solve.  Surely, HTML-mail is marked with MIME types, yes?  So one could
use metamail, perhaps, as a quick way to find out if any part is HTML (and
if so, bounce the whole thing).  (I haven't looked at metamail in years,
but I recall that it was a fairly straightforward UNIX-style filter, so it
should let one check MIME types readily.)

(If metamail won't serve, perhaps another tool would; or one could go grab
the MIME RFC's, write a MIME content-type parser just for the job, and use
that.)


Re. long lines: Yes, they obviously have function from time to time.
That's why I said that (if it were my call) long lines would result in
*warnings* (not bounces).  If someone writes a paragraph-on-one-long-line,
that isn't a healthy thing on a mailing list (as you note).  If they are
pasting verbatim dmesg output (say), then it's appropriate and preferable
to have the long lines from time to time.

I don't know how an automated filter would always know the difference, and
certainly paragraphs-on-a-line should get some kind of negative
reinforcement.  Thus my suggestion of a warning.  Long lines should rarely
need to happen, so warnings shouldn't occur too frequently.

(Here, perhaps I should clarify: When I say ``warning'', I mean in the
compiler sense of ``This looks slightly bogus.''  *Not* in the sense of
``This is your Nth warning.  Failure to comply will result in us saying
bad things about you.'' or any such.)


  ``I probably don't know what I'm talking about.'' --rauch@math.rice.edu