This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author r.david.murray
Recipients Fedele Mantuano, barry, r.david.murray
Date 2016-05-12.16:26:15
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1463070375.81.0.586304921234.issue27010@psf.upfronthosting.co.za>
In-reply-to
Content
When you say the attachment is not detected, what do you mean?  What call are you making to the email library that you are expecting to see the attachment in that it is not in?  Your 'parsed' pastebin isn't something the library produces, so I assume that's the Tika output.

(By the way, pastbin links are problematic in tracker issues, since they may expire.  Please paste directly in to the issue, or attach files to the issue.)

Oh, wait.  Looking at the email I think I see the problem:

----------------------------------------
</BODY>
</HTML>

--51a14337d8625bb8ce4a5b1667f--

--51a14337d8625bb8ce4a5b1667f
<attachment content>
----------------------------------------

That line that ends with '--' signals the end of the last MIME part in the message.  So by RFC standards the remainder of the message is part of the 'epilogue'.  If you check msg.epilogue I think you'll find that it contains the raw text of the remainder of the message.

It is interesting that your email client treats it as an actual attachment.  It would be possible to have the email library recognize such out of place mime dividers and register it as an error.  I would review a patch for that if someone wants to propose one.

--David
History
Date User Action Args
2016-05-12 16:26:15r.david.murraysetrecipients: + r.david.murray, barry, Fedele Mantuano
2016-05-12 16:26:15r.david.murraysetmessageid: <1463070375.81.0.586304921234.issue27010@psf.upfronthosting.co.za>
2016-05-12 16:26:15r.david.murraylinkissue27010 messages
2016-05-12 16:26:15r.david.murraycreate