Mailinglist Archive: opensuse-bugs (2150 mails)

< Previous Next >
[Bug 872250] New: metamail (and munpack) fails to recognize filename of attachments from MS-multipart/alternative
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Sat, 5 Apr 2014 15:02:44 +0000
  • Message-id: <>

Summary: metamail (and munpack) fails to recognize filename of
attachments from MS-multipart/alternative
Classification: openSUSE
Version: unspecified
Platform: All
OS/Version: SLES 11
Status: NEW
Severity: Enhancement
Priority: P5 - None
Component: 3rd party software
AssignedTo: opensuse-communityscreening@xxxxxxxxxxxxxxxxxxxxxx
ReportedBy: guenther.pommer@xxxxxx
QAContact: opensuse-communityscreening@xxxxxxxxxxxxxxxxxxxxxx
Found By: ---
Blocker: ---

Created an attachment (id=585237)
--> (
contains patch and example to reproduce / verify the problem

User-Agent: Mozilla/5.0 (X11; Linux i686; rv:27.0) Gecko/20100101

Short story for explanation ahead, will give my intention below.

On our SLES11 I've tried to automize the extraction of mail-attachments and
found, that the attachment's name is not recognized on certain mails from
some broken mailer (M$), that leaves away the "name=" parameter, if it is a
multipart/alternative mail with attached
"Content-Type: application/" - but at least the
"filename=" parameter is provided in the "Content-Disposition:" tag - but
unfortunately metamail does not use the later.

Then I tried munpack (source mpack-1.6-2.1.src.rpm) from OpenSuSE build
service, but the result was the same. I had a look into the source and
found, that in cases where an e-mail-message did not contain a "name="
parameter with it's "Content-Type:" tag, then munpack was not able to
pick the (existing) "filename=" parameter from the "Content-Disposition:" tag
either, because of just a tiny lapsus (see patch-lines below).

As a solution, I appended the lines below, to the patch-file "mpack-1.6.diff",
which is shipped with the package "mpack-1.6-2.1.src.rpm" (from OpenSuse build
service). After running rpmbuild again, munpack would use the attachment's
given filename instead of generated names like "part1".

#======= appended the following lines to "mpack-1.6.diff" ===============

diff -ubrN mpack-1.6/decode.c mpack-1.6-1/decode.c
--- mpack-1.6/decode.c.old 2014-04-04 23:54:57.000000000 +0200
+++ mpack-1.6/decode.c 2014-04-04 23:55:13.000000000 +0200
@@ -546,8 +546,8 @@
if (!disposition) return 0;

- /* If we're looking at a ";", we found what we're looking for */
- if (*disposition++ == ';') break;
+ /* If we're NOT looking at a ";", we found what we're looking for */
+ if (*disposition++ != ';') break;


Additional change:
For overwrite protection, munpack was using a numeric count as file-name
suffix, which distorts file-extensions (.xls1, .csv2,...) and confuses
M$-office. So I also added the following patch, that changes the suffix to
a prefix, thus leaves the file-extension recognizeable.

#======= appended the following lines to "mpack-1.6.diff" ===============

diff -ubrN mpack-1.6/unixos.c.old mpack-1.6/unixos.c
--- mpack-1.6/unixos.c.ori 2014-04-05 13:49:57.000000000 +0200
+++ mpack-1.6/unixos.c 2014-04-05 13:59:26.000000000 +0200
@@ -163,7 +163,7 @@
FILE *os_newtypedfile(char *fname, char *contentType, int flags, params
char *p;
- static int filesuffix=0;
+ static int filesuffix=0, fileprefix=0 ;;
char buf[128], *descfname=0;
FILE *outfile = 0;

@@ -203,7 +203,7 @@
else if (!overwrite_files && (outfile = fopen(fname, "r"))) {
do {
- sprintf(buf, "%s.%d", fname, ++filesuffix);
+ sprintf(buf, "%d-%s", ++fileprefix, fname);

} while (outfile = fopen(buf, "r"));
fname = buf;

These slight modifications make munpack ways more practical for non
interactive usage. So for now my problem is solved, but here's my

Is there any chance, to get this tool shipped with SLES one day ?

Thanks in advance
kind regards
G√ľnther Pommer ( guenther.pommer@xxxxxx )


unpack-modification.tar.gz containing:

mail.raw - the problematic raw-mail to re-produce "my" problem
mpack-1.6.diff - patch-file including all previous and new changes
chk_att_name - temporary perl-workaround, while still using metamail
bug-report.txt - again

Reproducible: Always

Steps to Reproduce:
reproducible with the example mail-body in the attachment
Actual Results:
see bug-report.txt

Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.
< Previous Next >
Follow Ups