[ mailman-Bugs-1518281 ] Bad Content-Disposition breaks senddigest

SourceForge.net noreply at sourceforge.net
Sat Jul 8 02:50:17 CEST 2006


Bugs item #1518281, was opened at 2006-07-06 10:27
Message generated for change (Comment added) made by msapiro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1518281&group_id=103

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: mail delivery
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Philip Crotwell (crotwell)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad Content-Disposition breaks senddigest

Initial Comment:

We are using the default mailman on mac osx server 10.3
which is mailman 2.1.2, so this may be old. But just in
case, we got an email with attachement that caused
mailman to croak in senddigest. Here is the output of
running it by hand. I added 2 prints to see what the
offending filename variable had in it. The
Content-Disposition headers are below. Note that the
two parts of the filename have been joined, but because
of the bizarre endquoting in filename*0, there is an
embedded \n\t.

We fixed this locally by editing the mbox to change the
offending filename to be shorter and not split into two
parts, but it might be nice if mailman would check for
illegal characters embedded in filenames?

In addition to senddigest croaking, all emails after
this bad one were not added to the archive. Luckily we
had made a copy of digest.mbox before running
senddigest manually and were able to manually add the
lost emails to the archive mbox.

roo:/usr/share/mailman root# python -S cron/senddigests
-l chair-archive
(None, None, 'Outside Professional Activities GS
Policy_4-22-03 rev\n\t5-16-05.doc')
(None, None, 'Outside Professional Activities GS
Policy_4-22-03 rev\n\t5-16-05.doc')
Traceback (most recent call last):
  File "cron/senddigests", line 94, in ?
    main()
  File "cron/senddigests", line 86, in main
    mlist.send_digest_now()
  File "/usr/share/mailman/Mailman/Digester.py", line
60, in send_digest_now
    ToDigest.send_digests(self, mboxfp)
  File
"/usr/share/mailman/Mailman/Handlers/ToDigest.py", line
130, in send_digests
    send_i18n_digests(mlist, mboxfp)
  File
"/usr/share/mailman/Mailman/Handlers/ToDigest.py", line
303, in send_i18n_digests
    msg = scrubber(mlist, msg)
  File
"/usr/share/mailman/Mailman/Handlers/Scrubber.py", line
257, in process
    url = save_attachment(mlist, part, dir)
  File
"/usr/share/mailman/Mailman/Handlers/Scrubber.py", line
348, in save_attachment
    fnext = os.path.splitext(msg.get_filename(''))[1]
  File "/usr/share/mailman/pythonlib/email/Message.py",
line 709, in get_filename
    return unicode(newvalue[2], newvalue[0])
TypeError: unicode() argument 2 must be string, not None



--Apple-Mail-5-348793981
Content-Transfer-Encoding: base64
Content-Type: application/msword; x-unix-mode=0666;
        name="Outside Professional Activities GS
Policy_4-22-03 rev
        5-16-05.doc"
Content-Disposition: attachment;
        filename*0="Outside Professional Activities GS
Policy_4-22-03 rev
        5-16-05.do"; filename*1=c



----------------------------------------------------------------------

>Comment By: Mark Sapiro (msapiro)
Date: 2006-07-07 17:50

Message:
Logged In: YES 
user_id=1123998

There are a couple of different issues here.

The '\n\t' in the filename come about because the header is
folded in the middle of the quoted value of the filename*0
parameter. The filename*0 and filename*1 parameters split
the filename per RFC2231, the very purpose of which is to
allow breaking of long parameter values into smaller pieces
so that header folding/unfolding can be accomplished at
syntactic breaks - e.g. at the semicolons.

In this case, either the generating MUA (Apple Mail) folded
the header in the middle of the filename*0 value or it made
the value so long that a subsequent MTA folded it. Thus,
with respect to the '\n\t' in the middle of the name, it
results from a non-compliant message.

The immediate cause of the exception in your case was fixed
in the email library shipped with Mailman 2.1.3. The fix
replaces

            return unicode(newvalue[2], newvalue[0])

with

            return unicode(newvalue[2], newvalue[0] or
'us-ascii')

and makes a similar change in a few other places. The patch
for this change is attached here.

There is also a bug in the (in your case)
/usr/share/mailman/pythonlib/email/Utils.py module. See the
post at
http://mail.python.org/pipermail/email-sig/2006-July/000293.html
for more on this and a possible patch.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1518281&group_id=103


More information about the Mailman-coders mailing list