On October 15, 1999 at 18:08, shaunp wrote:
<MIMEArgs>
....
m2h_external::filter;usename subdir
....
</MIMEArgs>
When I run mhonarc using this resource file, it saves the attachments in
the normal way (ie: with names like jpg0000.jpg) and not in a subdirectory.
MHonArc is reporting that it is reading the resource file correctly, but
doesn't seem to take any notice of it!
A resource that represents a "list" of values will augment
the current setting by default. In the MIMEArgs case the
default value is:
<MIMEArgs>
image/gif; inline
image/jpeg; inline
image/x-xbitmap; inline
image/x-xbm; inline
</MIMEArgs>
Therefore, after you specify:
<MIMEArgs>
m2h_external::filter;usename subdir
</MIMEArgs>
The new value is actually:
<MIMEArgs>
image/gif; inline
image/jpeg; inline
image/x-xbitmap; inline
image/x-xbm; inline
m2h_external::filter;usename subdir
</MIMEArgs>
Since the arguments to the various image/* media-types take
hide any filter-named arguments, the image data does NOT have
the "usename subdir" settings. From the MIMEARGS resource page:
If an argument string is defined for a filter explicitly and for a
content-type that the filter processes, the content-type string will
override the filter string.
There are a couple approaches to get what you want. The first is
to use the "override" attribute to MIMEARGS:
<MIMEArgs override>
m2h_external::filter;usename subdir
</MIMEArgs>
When the "override" is specified, all previous settings are erased.
Therefore, the image/* settings are no longer in effect.
However, if you still want to "preserve" the current settings but
add the new options, you will need to do:
<MIMEArgs>
image/gif; inline usename subdir
image/jpeg; inline usename subdir
image/x-xbitmap; inline usename subdir
image/x-xbm; inline usename subdir
m2h_external::filter;usename subdir
</MIMEArgs>
Using "override" here depends if there other MIMEArgs settings
you want to preserve or not.
WARNING: Using "usename" is a potential security risk. It has
come to my recent attention that "usename" or "usenameext" opens
up attacks by exploiting server-side includes (SSIs). I.e. Data
can specify a filename with a ".shtml" extension, and if SSI is
enabled, the data can specify SSIs that could exploit your
site.
Also, it is HIGHLY ADVISABLE to not have SSIs active for
".html" files. Currently, SSIs in HTML message data are not
removed byt the text/html filter, so someone can compromise
your site by sending an HTML message with SSI directives.
--ewh
