I recieve a number of emails with attachments, for example if someone forwards a simple email to me it comes in as an attachment.
The URL to the attachment is ticketid/1/1
In Internet Explorer, when you click on these, you get a 'File Download' pop-up box.
If you click Open, then cancel, then click the attachment hyperlink again it opens OK.
I have checked my file type settings and text/plain comes should be opened by notepad. However, it looks (to me) like the suffix on the attachment must be .txt.
Are you guys using internet explorer? Do you have some magic setting that I am missing?
The development is being done mainly on Linux at the moment, though we have access to IE to test things. However, I will attempt to answer this off the top of my head.
I believe IE does rely on the suffix rather than the content-type header to determine an attachment's type. The request that you made a while ago for the correct suffixes to be added to attachment names would therefore help.
There is another issue here, however, which I thank you for bringing to my attention. The content-type header of an attached message will probably not be "plain/text" but "message/rfc822" (I'd be grateful if you could confirm for the messages you're receiving). "message/rfc822" is another container type like "multipart" and currently we do not have any special handling for it. I'll file a bug report for this when I've had a chance to research the problem a bit more.
1. With respect to the suffix. It appears to me that the suffix is being used because the Content-Disposition is set to attachment;filename etc.
I disabled this piece of code and the 'download file' dialog stops happening.
With respect to the content-type for mails with attachments, these seem OK. From viewing the source of the mail, it appears that the section type is message/rfc822, but the content-type in that section is still 'text/plain'
My mistake, the wrapper will have content-type "message/rfc822" but the contained message will still have "text/plain". I looked at using the Python mimetypes module to guess extensions, but for most types there are many possible extensions, plus that module is very different between Python 2.1 and 2.2.
In fact, an attachment is only likely not have a name parameter indicating its filename when it is a forwarded message. We probably should have special handling for attached messages - Yahoo! and Pine both display them inline. The only remaining problem then would be attached files that didn't set the name parameter, but they always should.
What piece of code did you disable? We never touch the headers of incoming messages. Were you testing with migrated messages? I see that the migration code always assumes that attachments are files, which is of course not correct, but that is experimental code.
I disabled the piece of code that sets the filename when the filename has no extension (Application.py 1.5 line 44)...
def index_html(self, REQUEST, RESPONSE):
"""Displays an attachment."""
if self.title.find('.') != -1:
'attachment;filename=%s' % self.title)
return File.index_html(self, REQUEST, RESPONSE)
I was working on new messages (non-migrated). I simply emailed myself a message (outside mailmanager). I then forwarded that email to my email in mailmanager.
Yes, the deliberately attached items such as jpgs or files have filenames. These work fine for me.
Ouch, I'd never noticed that line (I take it you meant Attachment.py). I'll have to ask Andrew what it's supposed to be doing. I wonder if it's the "attachment" disposition or simply the "filename" parameter that has that effect. In any case, it's clear that not all attachments should have filenames.
Thanks for drawing these problems to our attention. I have filed a bug report and added some discussion there. The latest CVS version should make your hack in Attachment.py unnecessary.
Log in to post a comment.