Message85337
Daniel: i can't remember the exact scenario (i filled this bug 2 years
ago !)
after having a look back at email.message.Message.get_payload, i
remember the problem: the decoding errors are silented by the method and
you have no way to know if the decoding has been successful or not.
to find my malformed email i had to patch the module like that
(basically just removing the try/except blocks):
<patch>
--- message.py.orig 2009-04-03 23:46:47.000000000 +0200
+++ message.py 2009-04-03 23:48:27.000000000 +0200
@@ -192,19 +192,11 @@
if cte == 'quoted-printable':
return utils._qdecode(payload)
elif cte == 'base64':
- try:
- return utils._bdecode(payload)
- except binascii.Error:
- # Incorrect padding
- return payload
+ return utils._bdecode(payload)
elif cte in ('x-uuencode', 'uuencode', 'uue', 'x-uue'):
sfp = StringIO()
- try:
- uu.decode(StringIO(payload+'\n'), sfp, quiet=True)
- payload = sfp.getvalue()
- except uu.Error:
- # Some decoding problem
- return payload
+ uu.decode(StringIO(payload+'\n'), sfp, quiet=True)
+ return sfp.getvalue()
# Everything else, including encodings with 8bit or 7bit are
returned
# unchanged.
return payload
</patch>
once again, the behaviour is documented, so it's not really a bug.
but it caused me a lot of trouble (and it does not conforms very well to
"Errors should never pass silently.":)
but i guess applying such a patch could potentially break number of
client code so... is it worth the change? |
|
Date |
User |
Action |
Args |
2009-04-03 21:58:36 | rndblnch | set | recipients:
+ rndblnch, barry, ajaksu2 |
2009-04-03 21:58:36 | rndblnch | set | messageid: <1238795916.52.0.278884258304.issue1672568@psf.upfronthosting.co.za> |
2009-04-03 21:58:34 | rndblnch | link | issue1672568 messages |
2009-04-03 21:58:33 | rndblnch | create | |
|