On September 16, 2003 at 21:33, Vicki Brown wrote:
It is MIMEEXCS.
and it is excluding application/* data.
You need to reset MIMEEXCS as shown in one of previous messages.
How is this happening?
MIMEEXCS defines the list of content-types to exclude from processing.
I don't have MIMEEXCS in my .mrc file; thus, how is _anything_ being excluded
The default is documented as "Nil".
How do I "fix" a setting I currently do not have?
If I insert a MIMEEXCS resource setting that doesn't mention
application/octet-stream, will it "override" whatever is stuck in MhonARC's
Not unless you specify the override attribute. Otherwise, it just
adds to the existing list.
One solution is to use the inlineexts and usenameext options to
m2h_external::filter; inlineexts="jpg" usenameext
Unfortunately, such a solution can make your archive vulnerable to
attacks (see the MIMEFILTERS page and the m2h_external::filter and
the Security section of the FAQ for more information).
I don't understand. I read the Seurity FAQ; the section on "Why doesn't
MHonArc, by default, use the specified filename when saving attachments?
seemed the most relevant." - from this, it would appear _safer_ to save a
.jpeg as a .jpeg (which is not executable) than as something else, e.g. .bin,
which _could be_ executable!
No. .bin just means it is binary data. Just because some browsers
(and I won't name names) like to assume that application/octet-stream
implies an executable does not mean that it is correct behavior.
Also, your logic if flawed since you are focusing on a single case.
The filename specification in a mail message is solely intended for
informational purposes only (the RFCs explicitly warn about the usage
of filename information). Because some MUAs fail to treat it as such
(or provide proper warnings to the user), is a reason why many mail
viruses are able to spread.