On Sat, 13 Oct 2012 12:50:13 -0700, "Jordan Hayes" <jmha...@j-o-r-d-a-n.com>
wrote:
> Just stumbled upon this today:
>
> http://mail.python.org/pipermail/email-sig/2008-June/000394.html
>
> Mark Sapiro writes:
>
> > I may have the urge to look at this after Mailman 2.1.11 is released.
>
> Any urge now? :-)
I believe these issues have been dealt with, and that we are now RFC 2822
(and 5322, for that matter) compliant. Except, of course, that we don't
do any unfolding (but see next paragraph). Part of this was done in 3.1,
more of it in 3.2, and the final bits in 3.3. In 3.3 we even fixed the
whitespace issues in our handling RFC 2047, thanks to Ralf Schlatterbeck.
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 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. (Since it is a new algorithm I
am sure there are undiscovered bugs[*], which is part of the reason it
is provisional code. Another reason is that not all of the RFC's header
types have been fleshed out, so I shouldn't really say "fully" yet...)
--David
[*] not to mention the fact that it is a really really *ugly* algorithm
that I need to completely rewrite now that I at least got it working
(modulo the undiscovered bugs) and understand the issues involved
better.
_______________________________________________
Email-SIG mailing list
Email-SIG@python.org
Your options:
http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
