Re: continuation_ws in Generator and Header

> I believe these issues have been dealt with, and that
> we are now RFC 2822 (and 5322, for that matter) compliant.

Great!  Any chance of this making it into a patch for 2.1.15 ...?

> The only thing that continuation_ws is used for now is when
> doing line wrapping on RFC 2047 tokens.  (And it now defaults
> to a space, which may or may not be optimal, but certainly works.)

I thought the issue is that there should be no character at all: 2822 
says to perform folding you simply insert a CRLF *before any whitespace* 
so that unfolding is simply a matter of removing the CRLF.

Maybe an example would help.  Here's a header line:

Subject: This is overkill to fold, but legal

Here's one way to fold it:

Subject: This is overkill
 to fold, but legal

Because the space between "overkill" and "to" is valid whitespace, it's 
also valid as a signal that the second line is a continuation of the 
first.  You don't have to insert another space (or as it does presently, 
a tab!), you just have to insert CRLF.  Likewise on the way out, just 
remove the CRLF.

So I think for Mailman, which can modify the Subject: line, what you 
need to do is first unfold the line if it's already folded; apply any 
changes; and then optionally refold, if it's now longer than you'd like 
it to be.

> I addition, the new (provisional) email policy in the 3.3 email
> library has a both an unfolding and a folding algorithm that are
> supposed to be fully RFC 2822/5322 compliant, including that the
> folding algorithm implements folding according to the RFC's syntax.
> That is, it really knows where the higher level syntactic breaks are
> on a per-header-type basis and folds there preferentially.

Sounds great.

Thanks,

/jordan