Re: Disabling attachments

2005-06-02 17:48:22
On June 1, 2005 at 20:25, East Coast Coder wrote:

Oddly enough, I can't find in the docs a switch to ignore all
attachments.  Am I missing it?  What is the best way to do this?

Well, the concept of "attachments" is fuzzy in MIME, in my IMHO.
There is the Content-Disposition header field to clearly state when an
entity is to be treated as an attachment, but most people refer to an
"attachment" on anything that must be saved to disk (because not all
media-types can be rendered inline).  Plus, Content-Disposition is
not a required header field (it is defined by a separate RFC from
the standard MIME RFCs).

There are cases where a text/plain entity may be denoted as an
attachment via Content-Disposition.  Do you want to exclude it?

Sometimes images are denoted as attachments and sometimes they
are not, and sometimes no Content-Disposition exists telling how
it is to be treated, leaving it up to the MUA to make the decision.

I think the better question is: What media-types are you willing to
accept for your archives?

Come up with a list, and from that, you can configure MHonArc to
only allow those types.

You can use the MIMEEXCS resource to exclude media-types, and if
you are willing to check out the latest snapshot build, the new
resource MIMEINCS gives any more control over what to include
and exclude.  Documentation is provided for MIMEINCS.

Side Note: MHonArc, by default, ignores the Content-Disposition
designation of "attachment", mainly due to usability and security
reasons.  By default, anything not directly renderable in a browser is
saved to file.  The m2h_text_plain::filter and m2h_text_html::filter
support an "attachcheck" option if Content-Disposition should be
checked.  For HTML, this can pose a security risk as noted in
the MIMEFILTERS resource page of the docs.

The m2h_external::filter has a few options related to attachment
handling, mainly wrt images.  By default, this filter does try to
honor Content-Disposition, if present, wrt images for rendering
purposes.  But options exist to override this behavior.


<Prev in Thread] Current Thread [Next in Thread>