Message271611
It might also make sense to return the payload undecoded. The documentation for get_payload() function says:
"[...] the payload will be decoded if this header’s value is quoted-printable or base64. If some other encoding is used, or Content-Transfer-Encoding header is missing, the payload is returned as-is (undecoded)."
Even though the header's value tries to convince you "base64" is the encoding, it is - in this case - either broken base64 or not. Hence it might fall into the category "some other encoding is used", justifying the "payload is returned as-is (undecoded)".
As to the original payload Claudiu posted, in that the mailserver has truncated the email. This already provides the user with non-base64 string that they try to convince you to decode as base64. My argument is still valid in this case. |
|
Date |
User |
Action |
Args |
2016-07-29 06:33:37 | CryptidVulpes | set | recipients:
+ CryptidVulpes, r.david.murray, Claudiu Saftoiu |
2016-07-29 06:33:37 | CryptidVulpes | set | messageid: <1469774017.22.0.274413743809.issue27397@psf.upfronthosting.co.za> |
2016-07-29 06:33:37 | CryptidVulpes | link | issue27397 messages |
2016-07-29 06:33:37 | CryptidVulpes | create | |
|