Mantis - Squeak
Viewing Issue Advanced Details
1601 Network minor always 08-03-05 22:51 12-10-05 21:15
assigned 3.8  
0001601: [ENH] HeaderFolding-klc
"Change Set: HeaderFolding-klc
Date: 5 March 2004
Author: Ken Causey

Support of proper header folding and unfolding per RFC 822 seems to be
variable among email clients, MTAs and the like. Despite the standard
specifying otherwise occasionally the line is broken at some postion
that is not a space. In particular a recent case resulted in an
attachment filename being garbled because the header specifying the
filename was broken at the period of the extension.

To try to cut down on the effects of this issue I've added pre-emptive
header folding to MailMessage. My implementation is relatively simple,
only folding lines at spaces. But hopefully by pre-folding the lines in
the way we desire them to be folded we will cut down on the incidence of
destructive folding."
related to 0000151assigned gokr MailMessage cannot send to more than one email address 
 HeaderFolding-klc.cs.gz [^] (1,300 bytes) 08-03-05 22:51
 TestHeaderFolding-fbs.cs.gz [^] (526 bytes) 08-03-05 22:54
 HeaderFolding-klc.2.cs.gz [^] (1,747 bytes) 08-03-05 22:56
 HeaderFolding-klc.3.cs.gz [^] (1,779 bytes) 08-03-05 22:57
 HeaderFolding-klc.4.cs.gz [^] (1,781 bytes) 08-03-05 23:01

08-03-05 22:52

"Attached is a small test, showing
* a small header
* a header with 53 characters
* a header with 3 26-character tokens being folded.

The last test fails because #ifNotEmpty: takes a one-argument block.

When folding lines, you must terminate lines with a crlf pair, not just
a cr - or will something after the MailMessage transform that cr into a
crlf pair?

What happens if we have a really long line that can't be folded on
spaces (because, say, there aren't any)? I can't see what the RFC
actually says about that. It mumbles about "structured headers" and such
without giving too much detail. Or I'm not reading with my thinking cap
(attaching TestHeaderFolding-fbs.cs.gz)
08-03-05 22:54

"First of all I want to thank you very much for your detailed analysis
and most especially for the included test. This morning even before I
saw your email I thought to myself that I was remiss in not providing at
least one test case.

Now to reply to your comments:

"The last test fails because #ifNotEmpty: takes a one-argument block."

Yes, it does fail but this is not the reason. First of all #ifNotEmpty:
uses #valueWithPossibleArgs which means that it is quite happy with a 0
argument block. If you are actually seeing a problem there I bet you
have RB installed which rather rudely redefines ifNotEmpty: if I
remember correctly.

The failure I see is due to your comments regarding cr vs. crlf. The
reason I did not specify crlf but instead cr is that I was following the
conventions of the rest of MailMessage which uses cr. I have to admit I
did not track it down to confirm but it is my assumption that at some
later point in the process the linefeeds are inserted as necessary.
This convention is relatively standard in Squeak where internally cr is
used and it is converted to crlf as needed just before leaving the
environs of Squeak.

I've taken the liberty of including your test case within the new
version of my enhancemnt I hope you don't mind. I changed the test to
use String cr and it passes now.

"What happens if we have a really long line that can't be folded on
spaces (because, say, there aren't any)? I can't see what the RFC
actually says about that."

My reading is that header folding is completely optional. The RFC
really only talks about it in the context of displaying on narrow screen
width terminals. I've added this because other software in the chain
between the user and the BFAV2 archive would fold headers and often do
so incorrectly and destructively. This change is merely to provide a
pre-emptive folding in the hopes of reducing the occurance of
destructive folding. As I admit in the preamble this is a simplistic
change. Folding anywhere other than a space is significantly more
complex as it depends on where it is safe to make a break and dependent
on the header, at least that is my understanding. If this change
results in no folding we are no worse of than we were before.

Again, thank you for taking the time to look at this and for the test

(attaching HeaderFolding-klc.2.cs.gz)
08-03-05 22:56

"This version just corrects a mistaken attribution."

(attaching HeaderFolding-klc.3.cs.gz)
08-03-05 22:58

"[sm][er][cd][et][su][sl] Works!

Just one comment - MailMessageTest should be part of
Network-RFC822-Tests, rather than Tests-Network-RFC822."
08-03-05 23:00   
Now, some 17 months after the original report comes the 4th and hopefully final version of this 'enhancement'. The only change here is to answer Frank Shearar's misgiving (with which I agree) regarding the category name of the test case. No other change compared to v3.

See HeaderFolding-klc.4.cs.gz.