http://docs.python.org/3.4/library/email.html#package-history

The table ends with email version 5.1, distributed with Python 3.2, and compatible with Python 3.0 to 3.2.

Since Python 3.3 and 3.4 also distribute 5.1.0, I'm betting that the actual compatibility is at least 3.0-3.4.  (Currently, it is also used on the 3.5 tip, but I suppose we don't want to guarantee that yet.)

That table is actually correct as it stands.  Post 5.1 I pretty much stopped tracking the email version independently of the python version.  So most likely the 3.3 python isn't compatible with 3.2, and the same for 3.4 and 3.3.  

Let's get Barry's agreement that that is OK, and I'll add a note to the docs to that effect.  If he wants separate version numbers I can increment it in 3.4, but it is probably too late for 3.3.  If we can drop the independent version, then we have to decide if we want to deprecate the __version__ string or just remove it.

I'm submitting a patch for review to show the updated table of email versions. If this is accepted, I'll update the docs for 2.7 as well.

I don't know for sure if the compatibility claims are correct, but the patch looks good.

Like I said, the compatibility claims are almost certainly incorrect.

New changeset 2eea52c287b7 by R David Murray in branch '3.4':
#20974: Update version table in email intro.
https://hg.python.org/cpython/rev/2eea52c287b7

New changeset 655b34cd8871 by R David Murray in branch 'default':
Merge: #20974: Update version table in email intro.
https://hg.python.org/cpython/rev/655b34cd8871

I've updated the table (thanks for the patch) but noted that after 5.1/3.2 there is no independent email version.  I'd like to just delete __version__ in 3.5, but I don't know if I have to deprecate the constant first :)  It didn't get updated in 3.3 or 3.4, so it isn't *accurate* in any case.