List Script (was Re: [WEB4LIB] RE: Can anyone help?)

[Robert Tiess]

Roy,
I examined the script, and here's what I found:

The script appears to check first if the incoming
message is simply text/plain; if it is, it sends
the text and exits (lines 89-94).  If the message's
Content-Type is something else, the program loops
through several other Content-Types that might be
present (lines 103-123).

The script doesn't appear to test for
"Content-Type: multipart/mixed" and at first glance
for good reason, since this is where attachments
would occur.  The code for this extra Content-Type
checking would look like:

  && ($work[$i] !~ /multipart\/mixed/i )
     #content not multipart/mixed

(hypothetically inserting this extra conditional
at line 114, after the /multipart\/digest/i match)

Of course the encoding of subsequent boundaries
would have to be Content-Type: text/plain (which
the loop deos seem to check for).  Anything other
than text/plain could be an attachment, for
example a file or image.  If it is a pure text
file, it should be a Content-Type of text/plain
and might survive this script (depends on how
well the sending e-mail client treats attached
text upon transmission and how well this script
reacts).  I haven't run the script at my end.

Another thing this script should probably check
for is Content-Type: multipart/alternative,
which involves, for example, a message with mixed
parts of text/plain and text/html (a very common
occurrence in current e-mail clients set to
plain/text but capable of sending HTML
automatically, by user preference, or both
text and HTML alternative editions).  The extra
code for this would look like:

  && ($work[$i] !~ /multipart\/alternative/i )
     #content not multipart/alternative

(hypothetically inserting this second conditional
at line 116, after the newly inserted
/multipart\/mixed/i conditional above)

Since the loop doesn't check for "Content-Type: text/html"
e-mail clients sending both text and html (an
option in most current clients) should not need
to be reconfigured if the script simply ignores
text/html portions and posts the alternate text
(text/plain boundaries); the script seems to
suggest it would behave this way.  E-mail clients
set to HTML-only *would* present fatal problems,
as there'd be no alternative plain text to view,
rendering such messages invisible, even at the
source level; those users should set their e-mail
clients back to text/html or better yet plain
text, as has been recommended.

For more on MIME and multipart Content-Types:
http://www.freesoft.org/CIE/RFC/1521/index.htm

I hope this information will be helpful.

Robert

rjtiess at warwick.net
http://rtiess.tripod.com


Roy Tennant wrote:
> Allow me. This is apparently the script we are using to do it, but I
> haven't yet checked with my systems support person to find out if he
> changed it at all:
> 
> http://www.listproc.net/ftp/software/lp_utils/filter00.pl
> 
> If you can improve upon it, I'm sure CREN would appreciate a better
> version, since they provide this script as a service to ListProc
> users. Thanks,
> Roy Tennant
> 
> >Can anyone clarify what web4lib currently does if it gets a posting that
> >consists of a MIME-standards-compliant message that contains a
> >multipart/alternative (or other multipart/*) where the FIRST part is a
> >text/html and the second part is the corresponding text/plain?  In this
> >case, does the listserv software now throw out the baby with the
> >bathwater?
> >
> >JQ Johnson                      Office: 115F Knight Library
> >Academic Education Coordinator  mailto:jqj at darkwing.uoregon.edu
> >1299 University of Oregon       phone: 1-541-346-1746; -3485 fax
> >Eugene, OR  97403-1299          http://darkwing.uoregon.edu/~jqj/