Author CryptidVulpes
Recipients Claudiu Saftoiu, CryptidVulpes, r.david.murray
Date 2016-07-29.06:33:37
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1469774017.22.0.274413743809.issue27397@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2016-07-29 06:33:37CryptidVulpessetrecipients: + CryptidVulpes, r.david.murray, Claudiu Saftoiu
2016-07-29 06:33:37CryptidVulpessetmessageid: <1469774017.22.0.274413743809.issue27397@psf.upfronthosting.co.za>
2016-07-29 06:33:37CryptidVulpeslinkissue27397 messages
2016-07-29 06:33:37CryptidVulpescreate