>>>>> "BLH" == Brian L Heess <dmbong@commline.com> writes:
BLH> I don't know about you guys, but when it comes to lists, I hate
BLH> multipart messages.
Well, I don't mind people attaching patches and such. It does bother me
when done uselessly (like to include a stupid redundant text/html part) but
anyone without the benefit of a MIME-capable mailer is pretty much in the
stone age these days.
BLH> I have in my 1.94.3 (yeah, yeah) a bunch of taboo things to keep that
BLH> stuff out of the lists, ALL of types are not wanted here, uu, base64,
BLH> html, etc...
Sounds like you're a prime candidate to plug for input/work on the
MIME-munging scheme that was put forth a while back. I'll include it
below. (NOT as an attachment; after all, it's just text.)
BLH> Now, that make makes me look at your question with tinted glasses,
BLH> but, the first part sounds good, at the same time, the preamble sounds
BLH> good. Any chance of checking both and forgetting the rest?
What do you mean by forgetting the rest? If you mean not checking the
other parts, then I completely agree. Preamble, first part, or nothing.
If you mean forgetting all of the included headers complexity, then I can't
do that because we've supported it all this time. Fortunately, the
Approved: followed by headers scheme won't require any MIME knowledge; I
just open the body handle, look for Approved, then look for headers, then
reread the bodyhandle (ugh), skip over the Approved: and tell the parser to
pull in an entirely new MIME entity from everything that follows. Sounds
complex but it's not too bad. (I'd prefer to use parse_nested_messages,
but that requires that the enclosing message specify content-type:
message/rfc822 and I can't rely on that.
Supporting broken mailers and weird approval methods that go along with
them is going to be the most painful thing.
MIME-munging scheme follows; see it also as the file MIME-munging in any
recent snapshot.
- J<
Date: Tue, 08 Jul 1997 20:56:42 -0700
From: Bill Houle <Bill.Houle@SanDiegoCA.NCR.COM>
Subject: MIME-munging (was Re: Current 2.0 TASKS list)
Many moons ago, Jason asked for design input for Mj 2.0, specifically:
>Come up with a MIME-munging scheme:
> Many list owners don't want some kinds of MIME parts getting on to their
> lists. taboo_body deals with some of this, but we need a mechanism that
> allows the owner to specify what kinds of MIME parts are OK and which are
> not. A minimal level of support would bounce the messages for
> confirmation, or would just delete offending parts. Better would be a
> conversion to an external-body type (and we already have the get method
> to take care of that). I just need the user-side of the specification
> (i.e. what the list owner needs to put in a variable) and some pseudocode
> for converting and removing the parts.
Here is something towards that end. Its not completely thought out, but
I'll just throw it out and let's discuss:
attachment_rules << END
multipart/mixed bounce
application/ms-tnef discard
application/* detach=decode
text/* pass=8bit
END
attachment_dir = "/some/path"
attachment_url = "http://host/some/path";
o $attachment_dir might be the same as $archive_dir??
o $attachment_url does not have to be set (non-Web-enabled sites).
o Order of interpretation for $attachment_rules will be top-down, and only
one match is allowed. (ie, once you've discarded, there is no way to detach).
o Wildcards are accepted for rudimentary pattern match (the conventional
'*' is converted to the equivalent regexp meta '.*').
o The BOUNCE action means presence of the MIME type causes the entire
message to be sent to the list-owner for approval.
o The DISCARD action means the attachment will be removed from the message,
neither archived nor passed on. The rest of the message will continue to be
processed.
o The DETACH action means the file will be stripped from the message and
saved to the $attachment_dir directory. A snippet about how to retrieve the
file via email will be inserted into the message:
+---------------------------------------------
| To retrieve this attachment, send mail to
| $list-request@$whereami with the command
| GET $list $filename
+---------------------------------------------
If $attachment_url is specified, the message will also contain
Web-retrieval instructions:
+---------------------------------------------
| To retrieve this attachment, send mail to
| $list-request@$whereami with the command
| GET $list $filename
| or via the URL
| http://host/some/path/$filename
+---------------------------------------------
o The optional argument to the DETACH command specifies an encoding scheme
for how the files are saved to disk. Values are "DECODED" (apply the
appropriate uu or BinHex to create a possibly binary file), "BINHEX" (for
Macintosh text format), "UUE" for MSMail style uuencoding, "MIME" (for
preserving MIME encoding), and "EXTERNAL" for conversion to RFC1521 MIME
external body types. No value means there will be no translation and the
attachment will be saved exactly as it was sent (all mailer encodings
preserved).
o The PASS command indicates the attachment will be mailed on without
modification.
o The optional argument to the PASS command specifies an encoding scheme
for how files are sent on to the list. Valid values are "8BIT" for 8bit
mail and "QP" for quoted-printable. No value means there will be no
translation and the attachment will be passed as-is.
o The attachment recognition engine could be further enhanced to recognize
in-body non-MIME file attachments such as uuencode and BinHex files that
are prevalent in todays mailers. This would extend the $attachment_rules
functionality as follows:
attachment_rules << END
WINMAIL.DAT discard
FILE.PPT detach
*.EXE bounce
END
o Matches can be either based on MIME type (signified
by the xxxx/xxxx pattern) or filename.
o Filenames are case-independent.
The biggest problem I am having is that I come from a UUencoded non-MIME
world. I tried to incorporate some of the MIME and translation stuff that
Jason had talked about, but I am really clueless in that area. This needs
work. But ask me to propose the non-MIME side and I'll feel comfortable
with it.
What else needs work?
Are there better "action" names?
Are there any other actions that you think will be necessary?
How should we handle no attachment_rules defined (automatically BOUNCED or
PASSED)?
--bill
Follow-Ups:
References:
|
|
