I believe I've come across some partial solutions for this particular issue in past web searches but I haven't been able to find them now. In any case, my recollection is that they didn't work 100% of the time.
Sometimes Eudora incorrectly parses MIME attachment file names so that they show up truncated and the resultant links in the body of the email don't work. Sometimes only the extension is missing, at other times when the file name is long, several words and the extension may be gone. A plain text MIME record may show up in the message body, indicating what the file name should have been, and it appears that there is a line-feed and/or carriage return inserted into the file name in this MIME record. The CRLF position in the plain text correspond to the point where the file name was truncated in the link.
Although it's not very difficult to figure out what happened and rename the file so it can be opened, it's frustrating for end users, who don't want to deal with the problem. Have any reliable work-arounds been found for this issue, or is this something we'll need to wait for in the new version?
Thanks for any help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do not recall ever seeing this problem but maybe that's just because of the types of attachment I tend to receive. It is very believable that there could be bugs in this area. And it seems possible that the problem could be remedied, at least in some cases, by preprocessing messages to fix MIME headers so that Eudora interprets them better. However I think the better choice is to wait for Hermes because problems of this kind will be the easiest to fix once we get a working executable.....but easy only if we have examples of messages that fail. So it would be most helpful if you could provide us with a sample or two.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm sending two screenshots. These involve the same document, sent from the same source to the same email address, twice. The errors appear to be identical.
Please note that the messages were originally received on a Windows 7 SP1 computer running the last version of pre-Hermes Eudora 7.x. The screen shots show them as they were forwarded to me in Hermes-installer Eudora on Windows 10.
Thanks for the screenshots. Without seeing the actual message in its native form I cannot be certain but it looks very much like Eudora is not at fault here. More likely the MIME headers were botched either by the originating email client or by some server that handled its delivery. Do you know what client it originated from?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The message originated from an Exchange Server, most likely accessed by some version of Outlook. The sender says other recipients did not have a problem with the attachment.
This is far from the only case of this problem we've seen over the past several years, but I haven't kept them all, so I can't determine if they all have that issue in common.
I suppose it could be some Outlook/Exchange proprietary issue which does not arise if the recipient uses Outlook to receive the message.
On the other hand, almost everybody uses Outlook and Exchange in my world, so if Eudora's going to be able to cope with modern life it will have to address such things. The Hermes-installed version of Eudora fixes other Outlook-specific issues that are present in the last Qualcomm version, such as graceful handling of HTML CSS tags in the body of the message. So perhaps there is a way to get at this one as well. For example, can CRLFs simply be parsed out of file names in MIME segments?
Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This adds to the mystery. I am reluctant to believe that Outlook or Exchange would corrupt MIME headers. However, given the evidence at hand, I am also reluctant to point the finger at Eudora. I will do some testing to check if Eudora unfolds headers correctly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I confirm the situation - have hundreds of such attachments with truncated file names.
Seems to me that there is some line-length limit somewhere, and as soon as it is reached a line-brake is insertet, which is causing the file name(s) to be truncated in that place.
Hope the attached screenshots are helpful... if needed, I can send more by PM.
Earlier in this thread I wrote that I had not seen this problem myself. But a memory has crept slowly into my consciousness and I now realize that I have. Apologies for this forgetfulness. (I am getting old!)
I have done some testing with a message structured much like the one that Kenneth Dibble posted, in which the "filename" argument of a MIME Content-Disposition header is folded, and I see no problem. Specifically, the raw message reads:
Subject: Test with folded MIME headers
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="Boundary"
Dear Pete,
OK, will send you this evening (after arriving home) some samples of mails:
(a) The "Send to browser" txt/html file, and
(b) Raw copy/paste from mdb into a text file, and
(c) Copy/paste from Eudora's message display.
However, I'd prefer to send them to you by PM rather than openly posting them here... is that OK for you?
I also did yesterday evening some tests with attachment filenames up to 36 ANSI characters long without triggering this issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear Pete,
have transfered 12 emails (originating from different countries between 2007 and 2019) with truncated attachment names into an MBX, and zipped it together with it's corresponding TOC - so it should contain all the data saved by mother Eudora.
Unfortunattely I'm not able to send the ZIP to you (as intended) by PM, coz sourceforge-PM has no option to attach files, and sending email from outside to sourceforge-address isn't working.
However, I have sent you by PM my email address so you can reply , if you wish, enablinng me to send you the files.
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for the samples, Johann. They confirm a consistent pattern of misbehaviour but also make the matter even more perplexing. The fact that the messages were created by a variety of different email clients rules out responsibility at that end of things. The fact that the problem happens with messages received via different servers would seem to rule them out. Which makes me conclude that Eudora must be the culprit. However I am unable to reproduce the problem with similar messages that I concoct and import into Eudora. I will keep thinking...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear Pete, thanks for the feedback. that is kind of conclusions which I also came to.
Out of curiosity I just made a test .
I created 16 files with those file names which getting truncated in two sets: dummy files (actually renamed empty text files) and real files (real PDF, XLS, PPS).
Then I sent out (from Outlook) each of these sets as attachments to 3 separate emails formated as: PlainText, HTML and Rich-Text (totally 6 emails).
Will check this evening (at home) what is arriving in Eudora, and come back to you by email.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks to materials that Johann sent me I have been able to confidently narrow down this problem and pin it squarely on Eudora. Many thanks to you, Johann. As I said before, this should be one of the first things we will be able to fix once Hermes is built.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I believe I've come across some partial solutions for this particular issue in past web searches but I haven't been able to find them now. In any case, my recollection is that they didn't work 100% of the time.
Sometimes Eudora incorrectly parses MIME attachment file names so that they show up truncated and the resultant links in the body of the email don't work. Sometimes only the extension is missing, at other times when the file name is long, several words and the extension may be gone. A plain text MIME record may show up in the message body, indicating what the file name should have been, and it appears that there is a line-feed and/or carriage return inserted into the file name in this MIME record. The CRLF position in the plain text correspond to the point where the file name was truncated in the link.
Although it's not very difficult to figure out what happened and rename the file so it can be opened, it's frustrating for end users, who don't want to deal with the problem. Have any reliable work-arounds been found for this issue, or is this something we'll need to wait for in the new version?
Thanks for any help.
I do not recall ever seeing this problem but maybe that's just because of the types of attachment I tend to receive. It is very believable that there could be bugs in this area. And it seems possible that the problem could be remedied, at least in some cases, by preprocessing messages to fix MIME headers so that Eudora interprets them better. However I think the better choice is to wait for Hermes because problems of this kind will be the easiest to fix once we get a working executable.....but easy only if we have examples of messages that fail. So it would be most helpful if you could provide us with a sample or two.
I'm sending two screenshots. These involve the same document, sent from the same source to the same email address, twice. The errors appear to be identical.
Please note that the messages were originally received on a Windows 7 SP1 computer running the last version of pre-Hermes Eudora 7.x. The screen shots show them as they were forwarded to me in Hermes-installer Eudora on Windows 10.
Thanks.
Thanks for the screenshots. Without seeing the actual message in its native form I cannot be certain but it looks very much like Eudora is not at fault here. More likely the MIME headers were botched either by the originating email client or by some server that handled its delivery. Do you know what client it originated from?
The message originated from an Exchange Server, most likely accessed by some version of Outlook. The sender says other recipients did not have a problem with the attachment.
This is far from the only case of this problem we've seen over the past several years, but I haven't kept them all, so I can't determine if they all have that issue in common.
I suppose it could be some Outlook/Exchange proprietary issue which does not arise if the recipient uses Outlook to receive the message.
On the other hand, almost everybody uses Outlook and Exchange in my world, so if Eudora's going to be able to cope with modern life it will have to address such things. The Hermes-installed version of Eudora fixes other Outlook-specific issues that are present in the last Qualcomm version, such as graceful handling of HTML CSS tags in the body of the message. So perhaps there is a way to get at this one as well. For example, can CRLFs simply be parsed out of file names in MIME segments?
Thanks.
This adds to the mystery. I am reluctant to believe that Outlook or Exchange would corrupt MIME headers. However, given the evidence at hand, I am also reluctant to point the finger at Eudora. I will do some testing to check if Eudora unfolds headers correctly.
I confirm the situation - have hundreds of such attachments with truncated file names.
Seems to me that there is some line-length limit somewhere, and as soon as it is reached a line-brake is insertet, which is causing the file name(s) to be truncated in that place.
Hope the attached screenshots are helpful... if needed, I can send more by PM.
Last edit: Johann Doniga 2019-10-10
Earlier in this thread I wrote that I had not seen this problem myself. But a memory has crept slowly into my consciousness and I now realize that I have. Apologies for this forgetfulness. (I am getting old!)
I have done some testing with a message structured much like the one that Kenneth Dibble posted, in which the "filename" argument of a MIME Content-Disposition header is folded, and I see no problem. Specifically, the raw message reads:
Subject: Test with folded MIME headers
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="Boundary"
--Boundary
Content-Type: text/plain
Content-Disposition: inline
Message Body
--Boundary
Content-Type: text/plain
Content-Description: OSENDUCopy of Prepopulated Resource Planning Doc by RPC Region.xlsz
Content-Disposition: attachment; filename="OSENDUCopy of Prepopulated Resource Planning Doc by RPC
Region.xlsx"
Attachment content
--Boundary--
I have pasted this here and, because of factors such as wrapping, I cannot be sure that it will display exactly as it should.
My conclusion from this is that we will need the raw text of a message that Eudora fails with in order to understand the problem better.
Dear Pete,
OK, will send you this evening (after arriving home) some samples of mails:
(a) The "Send to browser" txt/html file, and
(b) Raw copy/paste from mdb into a text file, and
(c) Copy/paste from Eudora's message display.
However, I'd prefer to send them to you by PM rather than openly posting them here... is that OK for you?
I also did yesterday evening some tests with attachment filenames up to 36 ANSI characters long without triggering this issue.
Johann, Thank you! Yes, please send them directly to me, preferably in a Zip attachment.
Dear Pete,
have transfered 12 emails (originating from different countries between 2007 and 2019) with truncated attachment names into an MBX, and zipped it together with it's corresponding TOC - so it should contain all the data saved by mother Eudora.
Unfortunattely I'm not able to send the ZIP to you (as intended) by PM, coz sourceforge-PM has no option to attach files, and sending email from outside to sourceforge-address isn't working.
However, I have sent you by PM my email address so you can reply , if you wish, enablinng me to send you the files.
Thanks
Thank you for the samples, Johann. They confirm a consistent pattern of misbehaviour but also make the matter even more perplexing. The fact that the messages were created by a variety of different email clients rules out responsibility at that end of things. The fact that the problem happens with messages received via different servers would seem to rule them out. Which makes me conclude that Eudora must be the culprit. However I am unable to reproduce the problem with similar messages that I concoct and import into Eudora. I will keep thinking...
Dear Pete, thanks for the feedback. that is kind of conclusions which I also came to.
Out of curiosity I just made a test .
I created 16 files with those file names which getting truncated in two sets: dummy files (actually renamed empty text files) and real files (real PDF, XLS, PPS).
Then I sent out (from Outlook) each of these sets as attachments to 3 separate emails formated as: PlainText, HTML and Rich-Text (totally 6 emails).
Will check this evening (at home) what is arriving in Eudora, and come back to you by email.
Thanks to materials that Johann sent me I have been able to confidently narrow down this problem and pin it squarely on Eudora. Many thanks to you, Johann. As I said before, this should be one of the first things we will be able to fix once Hermes is built.