[ mailman-Bugs-1792087 ] Mailman changes attachment filenames

SourceForge.net noreply at sourceforge.net
Tue Sep 18 19:28:28 CEST 2007

Bugs item #1792087, was opened at 2007-09-10 17:58
Message generated for change (Comment added) made by msapiro
You can respond by visiting: 

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
Private: No
Submitted By: Steven (madrobin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mailman changes attachment filenames

Initial Comment:

I'm using Mailman version 2.1.9.cp2, hosted by site5.com.

When sending attachments with long filenames to a list, the file name arrives with one character substituted for another. The attachments with the changed filename cannot be opened in the FirstClass email client.

The attachment names were:

2007 September Using FirstClass To Book School Resources.pdf


2007 September Teaching Lab Expectations and Routines.pdf

In both cases, when the attachment filenames were viewed in FirstClass after having been delivered by Mailman, the last space in the filename had been converted to a character which looks like a square. I am attaching a screenshot.

If I try to open the attachment in FirstClass, I receive an error dialog box:

File Transfer Failed because 

File not open error


I am not able to open the attachment.

If I send the same attachments with the same filenames "directly" (not through Mailman) and open them in FirstClass, there is no problem. The filenames do not change and the attachments can be opened without difficulty.

If I shorten the attachment filenames (for example, I removed the "2007 September" part of the above filenames) and send them through Mailman, there is also no problem; the filenames do not change and the attachments can be opened.

I also tried viewing the long-filename attachments sent via Mailman in a different email client (Pegasus Mail). The attachment filenames had again been changed (instead of a square, the character which had been substituted for the last space looked more like a thick vertical bar.) However, even with the filename change, Pegasus Mail was still able to open the attachments. (Unfortunately, my employer allows us to use only FirstClass.)

I was not able to find anything addressing this problem. However, if I missed it and you can point me in the direction of a solution, I would greatly appreciate it.

Thank you.


>Comment By: Mark Sapiro (msapiro)
Date: 2007-09-18 10:28

Logged In: YES 
Originator: NO

I have received the 'before and after' messages, and the problem is
because of header folding and unfolding. There have been discussions of
this on the mailman-*@python.org email lists. One example is at
which happens to address Subject: headers, but the issue is the same.

In this particular case, the original message attachment contains the

Content-disposition: attachment; filename="Test document saved with a very
long file name to see if it can be determined what is messing up.pdf"

all on one line even though it is probably split here. In Mailman's
processing of this message, the underlying Python email library methods
determine that this header exceeds the 78 character recommended maximum
length and thus folds it into

Content-disposition: attachment;
<tab>filename="Test document saved with a very long file name
<tab>to see if it can be determined what is messing up.pdf"

where <tab> represents an ascii tab character. The first fold (between
attachment; and filename=) occurs at a 'higher level syntactic break' as
recommended by the RFCs, but the filename itself is still too long so it is
folded onto a third continuation.

The basic issue revolves around the rules for folding and unfolding long
header lines. The original standard was RFC 822
<http://www.faqs.org/rfcs/rfc822.html>, sec 3.1.1. The current
recommendation is RFC 2822 <http://www.faqs.org/rfcs/rfc2822.html>, sec

Mailman via the Python email library is not doing the right thing
according to these standards. Mailman is replacing a <space> with
<CR><LF><tab> in order to fold the header. This works unambiguously for the
first fold at a syntactic break, but in the second case it doesn't work.

FirstClass is doing the right thing in unfolding by removing only the
<CR><LF>, but this leaves the <tab> in the middle of the file name which
causes a problem for FirstClass.

Because of the ambiguities between RFC 822 and RFC 2822, it is more common
for mail clients to remove a whitespace character when unfolding. In this
case, that would have the effect of removing the space between 'file name'
and 'to see'. This also is an incorrect result, but not as bad.

The correct (RFC 2822) thing for the python email library to do would be
to fold by just inserting <CR><LF> immediately after 'attachment;' and also
immediately before ' to see'. This would not be a complete solution to
these issues as long as there were common mail clients the removed
whitespace when unfolding, but it might minimize the damage. Note that this
is really a Python email library issue, not a Mailman issue.

In the mean time, the problem can possibly be avoided by avoiding spaces
in file names. Use underscores instead.


Comment By: Steven (madrobin)
Date: 2007-09-16 16:16

Logged In: YES 
Originator: YES


Thanks very much for your reply. I have tried your suggestions about
renaming the attachments in FirstClass, but it does not seem to be
possible. If I try to "save" rather than "open" the attachments, I get an
immediate "file input/output error" and that's that.

I would be able to send you a copy of the "internet headers" from the
message as it was received in FirstClass, as well as the headers of the
copy of the message which I saved in Pegasus Mail when the message was
being sent. Is this what you need? I'm not sure that this is something I
would want to post in a public forum. Can I email them to you?

Thanks again for your help.


Comment By: Mark Sapiro (msapiro)
Date: 2007-09-10 18:31

Logged In: YES 
Originator: NO

This appears to be a problem with header folding and unfolding resulting
in the <space> being possibly replaced by a <tab> which is shown as an
'invalid character' (the square symbol) by the mail client.

Can you save the attachment and then open the saved file outside of
FirstClass (perhaps after changing it's name or 'saving as' and providing a
'good' name)?

I am unable to know what is at fault here without seeing the raw headers
of the attachment part from the mail as sent and the mail as received from

It may be a Mailman issue, a cPanel issue or a FirstClass issue.

Also, please see


You can respond by visiting: 

More information about the Mailman-coders mailing list