[Mimedefang] Fwd: processing HTML email and handling attachments

[Michael Sofka]

> According to http://www.eym.com/products/mas/, EYM has a "patent-pending"
> system which strips attachments from e-mail and makes them available via
> a URL, much like action_replace_with_url.

Here is a post from CREN's lp-discuss list.  This list was created
to discuss future features for listproc, before listproc 9.0 was cancelled,
and listproc 8.2 made open source.  Note item 1 under "B.  Better processing
of attachments."  I'm fairly sure this is the first I read of the idea.

I was also considering doing this via MIMEDefang right around the time
you added action_replace_with_url, but don't recall if I discussed it on
the list, or anyplace else that would have been recorded.  Regardless, that
would be no more than a year ago.  (Almost immediately after putting
MIMEDefang on our listproc machine, I started thinking about how it
could be used to put much of the listproc 9 wishlist into listproc 8.2.)

Mike

----------  Forwarded Message  ----------

Subject: processing HTML email and handling attachments
Date: Mon, 17 Jan 2000 08:11:53 -0500
From: David Rosenthal <davidr at shamash.org>
To: lp-discuss at cren.net

<x-flowed>Here are more wish list ideas.....

A. Since HTMLizing email is becoming the wave of the present (not to
mention the future), I'd like to see ListProc 9.0 (if not Lapis) handle
this well..

That means:
1.  Being able to strip out HTML from messages sent to the listprocessor,
and understand the non-HTML text there as commands.  Since all
markup  begins with "<" and ends with ">", it shouldn't be too hard to
parse that out of the message, before the remainder of the message is fed
into ListProc to process a command.

2.  Nicely digesting HTMLized messages, keeping the HTML intact in the
multipart digest.  (ListServ is doing this now)

3.  If a message has BOTH HTML and non-HTML text in it, then it can be sent
unchanged for regular mail distribution, but for digest purposes one or the
other (HTML or plain text) should be selected and digested (this can
perhaps be a list configurable option, defaulting to HTML text).

====

B. Better processing of attachments

Attachments can be useful and annoying.  A small excel file sent to a list
may be very useful.  But a HUGE Excel file can be a real pain to download,
and cause lots of problems, especially if you don't have EXCEL on your
computer.

1.  Maybe certain MIME/UUENCODE types of attachments can be extracted from
emails and placed into a web page automatically.  The message can go out to
users with the text intact, and at the bottom it can say "The attachment
which was part of this message can be found on the web
at:  http://yourhost.domain.xxx/listproc/listname/filename.xxx"  That way
people who WANT to get the large attachment can download it, but it won't
clog your mail system.

2.  Attachments of certain file names should not be allowed (I'm sure we've
all dealt with the Happy99 virus.  This should be set up in a site-wide
configuration file since new viruses and junk will certainly come out in
the future.)

3.  Attachments of a certain size should either not be allowed or be placed
onto a web page (as described in #1 above)  This is the old "limit message"
defined in the $LPDIR/config file.  Since this hasn't been working in 8.2
many sites have placed such limits with their MTA out of necessity.

4.  The ability to not allow any attachments of any kind should also be
allowed on a list-by-list basis, with a site-wide override! (with a
site-wide exception list of acceptable mime types, like those annoying, but
small, vcards that some users attach with personal signature-like info).

====

What else can be said on these topics?  What did I forget?  Anyone
like/dislike these ideas?
--
   David Rosenthal
   Shamash Staff  http://shamash.org
   PGP key: http://drosenthal.org/davidrkey.pgp

</x-flowed>

-------------------------------------------------------