Header parsing and formatting is one of the major changes in email6, and it should handle this much more sensibly.  email6 won't land until 3.3, though it will be available on pypy for testing before that.  If you want propose a patch for fixing this in the current email module I will consider it (but see below).  Absent that, I'm marking this for email6/3.3.

Note that in email6 the primary interface for creating headers will be a factory function, and in the current design it will reject header values that contain /n (and/or /r).  The parser will deal with unfolding values when parsing existing messages.

Also, while I agree with you about what the RFC *says*, what email programs actually *do* seems to be a bit different.  Email generators in general use a single leading tab as folding whitespace, but if you unfold the resulting value, it is clear that the tabs are noise, and should be replaced by single spaces on unfolding.  This becomes obvious when you consider things like an unstructured Subject header that has been wrapped.  It will be wrapped with tabs by any mailer I've so far encountered, but if you unwrap it, add a 'Re:', and rewrap it, preserving the tab is clearly the wrong thing to do.  This is in fact what email used to do, and this has annoyed many many people over the years (including me) because the header in the reply message has this tab stuck in the middle of the subject...

So currently my plan is to special case tabs on folding and unfolding.  When unfolding single leading tabs will become blanks, when folding a single tab will be used as folding white space, replacing single blanks at the point of folding.  I haven't tested this algorithm on any other mailers yet, because I haven't got enough of the code finished yet to generate parseable messages.  (Maybe I'll do some by hand.)

This folding policy will be a controllable policy setting, so it will be possible to produce the strictly-RFC-conformant folding and unfolding on a per-message or even (when creating them) a per-header basis.

I welcome your thoughts on this subject (and if you are so moved your participation on the email-sig, which while it is pretty quiet right now will probably get less so soon when I post the next API iteration for email6).