email/header.py:decode_header() Line 95: dec = 
email.base64mime.decode(encoded)

Headers that contain Subject or From headers which are Base64 encoded 
and are insufficiently padded raise a HeaderParseError. The actual 
padding error is begin generated in binascii.a2b_base64 and bubbling up 
as a HeaderParseError in header.py. 

decode_header() should detect the padding error (Base64 text length does 
not evenly divide by 3) and automatically add padding before handing off 
to a2b_base64. The problem usually occurs with spam.

Example problem header:
Subject: =?iso-8859-1?B?
UHJldmVudCBGb3JlY2xvc3VyZSAmIFNhdmUgWW91ciBIb21lIA=?=


Properly Padded:
Subject: =?iso-8859-1?B?
UHJldmVudCBGb3JlY2xvc3VyZSAmIFNhdmUgWW91ciBIb21lIA==?=

Postel's law suggests that, as bad padding can be repaired,
decode_header ought to do so.  The patch does that, adds a test for it,
and alters another test to still properly fail on really bad encoded data.

The test doesn't check a single character encoded string, as such does
not specify a complete octet and I felt that base64 decoders might
reasonably differ on what to do then.

The issue exists in Python2.6.1 (where I made it) and trunk.

In the absence of a specific doc citation saying otherwise, this strikes me as a feature request to be considered for the 3.2 email update.

Patch includes a test.

I'd argue that since the recipient has little control over incorrect header padding, the traditional approach with e-mail is to fix-up bad encoding...and this ia bug.

The quote of Postel's Law is in the RFCs, actually.  So I think we can choose to consider this a bug.  There is a effort/benefit tradeoff when deciding to handle dirty data, but this one is simple enough.  Unless someone can think of a reason why the slight change in behavior might break existing code (other than by letting more spam through :(

Committed to py3k in r83690, 3.1 in r83694, and 2.7 in r83695.

Thanks Jason.