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:
|
|
