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: <bug-872250-21960@http.bugzilla.novell.com/>

https://bugzilla.novell.com/show_bug.cgi?id=872250

https://bugzilla.novell.com/show_bug.cgi?id=872250#c0


Summary: metamail (and munpack) fails to recognize filename of
attachments from MS-multipart/alternative
Classification: openSUSE
Product: openSUSE.org
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)
--> (http://bugzilla.novell.com/attachment.cgi?id=585237)
contains patch and example to reproduce / verify the problem

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


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/vnd.ms-excel" - 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 @@
SkipWhitespace(&disposition);
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;
}

SkipWhitespace(&disposition);



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
contentParams)
{
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 {
fclose(outfile);
- 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
intention:

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

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



Attachment:

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: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
< Previous Next >
Follow Ups