Please to not use attachment names longer than 35 characters when submitting to BFAV

Thomas Koenig tomkoenig at mindspring.com
Sat Mar 6 22:19:34 UTC 2004


As Ken notes below, attachment names longer than 35 characters will
sometimes be corrupted in transit to the Bug Fix Archive. 

-----Original Message-----
From: Ken Causey [mailto:ken at kencausey.com] 
Sent: Friday, March 05, 2004 9:44 AM
To: Frank Shearar; Tom Koenig; Brent Vukmer
Subject: Problem with attachments with exceedingly long names


If you haven't already learned this using email as the transmission
mechanism for BFAV2 is the bane of my existence. ;)

There is a problem when attachment names are very long.  As an example
Frank recently sent out a message with a changeset called
'TextEmphasisMagicNumberCleanupMonticello-fbs'.  Unfortunately long line
folding seems to be one of the 'features' of RFC 822 that is least well
supported.  The RFC seems quite clear to me but MTAs and clients often
violate the folding rules.  Specifically in this case someone in the
chain folded the header line naming the attachment in Frank's email like
so:

Content-disposition: attachment;
        filename="TextEmphasisMagicNumberCleanupMonticello-fbs

.cs.gz"

This is completely wrong but nearly impossible to reliably handle once
it has happened.  The main problem is that since the culprit decided to
fold the line at somewhere other than a whitespace (which is invalid)
the unfolder cannot know whether or not a space should be inserted when
putting the line back together.  This causes a miriad of problems with
BFAV2 and one of the primary reasons I've turned my attention toward
moving to a pure object solution.  However that's for the future.  For
now we just have to deal.

My first suggestion is that you refuse all attachments with names longer
than about 35 characters or suggest that the user rename them.

Secondly I'm working and hope to submit today a patch to MailMessage
that preemptively folds the header lines correctly which will hopefully
elminate folding elsewhere.  Even at that point however long attachment
names will be a problem and so should still be length limitted although
perhaps at a longer length than 35.

Ken




More information about the Squeak-dev mailing list