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
_______________________________________________
Email-SIG mailing list
Email-SIG@python.org
Your options:
http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
