Date: Tue, 14 Apr 1998 14:19:13 -0600 (MDT) From: Leonard Sitongia Reply-To: Leonard Sitongia Subject: Re: e-mail attachments To: woods@ucar.edu Cc: nsag@ncar.UCAR.EDU |> Subject: Re: e-mail attachments |> To: sitongia@jabba.hao.ucar.edu |> Date: Tue, 14 Apr 1998 14:04:14 -0600 (MDT) |> Cc: woods@ucar.edu, nsag@ncar.UCAR.EDU |> From: woods@ucar.edu (Greg Woods) |> Perhaps you could share what you learned with the rest of the organization? |> I certainly haven't heard anything about this. Probably 80% of |> the complaints I hear are from people on Solaris systems. Sure. Here is the memo I wrote to staff. I'll also include the FAQ which Kitty wrote. Synopsis: Help with handling e-mail attachments We are observing a growing number of reported problems with attachments in e-mail. As we (the CSMT) play catch-up with technology and comprehend the problems, we will issue helpful information, such as this e-mail and will update the Electronic Mail Attachment Frequently Asked Questions (FAQ) you can now find in /opt/share/pub/FAQ/e-mail_attachments. In general, the underlying transport of e-mail is working correctly. That transport has little responsibility for the content of the messages. The only responsibility is to move the e-mail document with integrity. Many types of data are being moved in e-mail messages these days. The data could be simple ASCII text, or a Word document, for example. The only thing that e-mail is responsible for doing is to convert the data into a safe format for transporting as an e-mail message. Beyond that is the issue of how you read e-mail and what is done with it. This is where dtmail, mailtool, zmail, etc. become relevant and where the MIME (Multipurpose Internet Mail Extensions) standard comes into play. MIME defines how to identify the contents of an attachment, and what action is taken when you click on that attachment. There are also a few limitations with how MIME attachments can be handled in our environment. The biggest limitation is the action(s) of the mail program when you click on a mail attachment. One operating system or set of application programs cannot be held responsible for knowing what to do with data from another operating system or application; for example: Word documents. If someone is working on a PC and e-mails you a Word document as an attachment and you read your mail on Unix, what is supposed to happen when you double-click on the attachment? There's no Word on Unix. In general, you cannot expect anything sent to you to be readable on the system you read it on. You need to coordinate these issues with the sender. Set up some agreements with your collaborators as to the compatible medium you will use for your work. In the particular case of Word, it happens that FrameMaker can read Word documents under Unix, although it cannot handle everything in Word. The problems with messages from UCAR coming in as one long line is a known problem with mail handling under Solaris 2.5.1. It will be implicitly fixed in Solaris 2.6. Under 2.6, the messages are *not* attachments, and they are properly line-wrapped to see in the window (refer to the workaround in the FAQ). If you encounter a particular error message, then we need to look at the problem you are having in more detail. It means that either a Solaris utility program is not starting correctly when you double-click on the attachment, or the attachment is not a valid type under Solaris. We need to see the EXACT circumstances of your error. We need to look at your mail and your system. First try logging out and back in. Don't delete the message. Then notify us through trouble. CSMT - High Altitude Observatory Electronic Mail Attachments Frequently Asked Questions (FAQ) We have been receiving a larger than normal number of trouble requests for information concerning email attachments. The following FAQ includes questions and answers gathered from the HAO trouble queue. This FAQ is a work in progress. As we (the CSMT) play catch-up with technology and comprehend the problems, we will add that information to this FAQ. ================================================================================ Summary 1. Saving email attachments 2. Messages from UCAR arriving as one long line 3. Error messages when reading UCAR attachments 4. Software for reading email attachments 5. Word attachment is from a Mac user 6. Reading binhex attachments 7. Stuffit Expander error 8. MIME attachments 9. MediaMail error reports as attachments 10. Binary attachment and base64 encoding 11. uuencode/uudecode 12. RTF attachments 13. PDF attachments 14. Other suggestions ================================================================================ 1. Saving email attachments Q: I very often get attachments that I do not have an application program under Unix to read. How do I save these attachments? A: Email reading programs usually display an attachment in a separate window from the body of the email mesage. Pop-up or pull-down menus provide operations to apply to the attachment. Do not save the entire message into a file to work on. Simply save the attachment itself as a file, via the operations described above. This is an important distinction. If you save the entire message, then there will be other text with the attachment, which is likely to cause subsequent work, such as reading the attachment with a program, to fail. For example: I detach the attachment(s) as a file(s) then, in my case, go to the public PC and login in. I open the file(s) via the Network Neighborhood->FileServer->[user-name]->[wherever you stored the file]->FILE.DOC and 95% of the time you can then print, edit, save, etc. Then, you can even go back to your workstation, Reply to the message and Attach the same file (NOT INCLUDE) so the other person can even read it correctly. 2. Messages from UCAR arriving as one long line Q: I use the CDE mail tool and sometimes a message sent from a PC or Mac arrives as an attachment. Sometimes the attachment message has no newlines (carriage returns), so the whole message is a single line. I.e., the owner-everybody msg that UCAR sent out recently. Is there an easy way to read these messages without saving them as a file and adding newlines? A: The problems with messages from UCAR coming in as one long line is a known problem with mail handling under Solaris 2.5.1. It will be implicitly fixed in Solaris 2.6. Under 2.6, the messages are *not* attachments, and they are properly line-wrapped to see in the window. In this case, the dtpad opened by double-clicking is not doing the line wrapping. For this, you would add the following resource to your .Xdefaults file and then log out and back in: Dtpad*WrapToFit: True Or you can use "Reload Resources" from the Desktop_Tools of the Application Manager to make this take effect, so you don't have to log out. 3. Error messages when reading UCAR attachments Q: I have two email attachments from other UCAR sites. When I try to read them in my mailtool I receive two messages: "The executing action failed" and "tt_err_ptype_start attempt to launch instance of ptype failed". What do these mean? A: This is usually caused by the situation described in question #2 above. Try that solution to the problem. If that doesn't fix the problem, them please report the problem to trouble. 4. Software for reading email attachments Q: I continue to get email attachments that cannot be interpreted by the mailer. I think the CSMT should make a priority to implement some software so that we can read these attachments. A: We have recognized the significance of these issues and are already working on them. We need to know what type(s) of attach- ments you are getting. In a previous Q&A we mentioned "detaching" an attachment rather than "saving" or "moving" it. At present, the next stage can be tricky because it depends on whether the type of MIME encoding tells you what type of document it is. For example: .DOC is most *likely* MSWORD (but not always). What you need to do currently on a Workstation is go to a public PC and use MSWord to open the document (again, refer to the previous Q&A). Another example: If you "POP" mail to the PC directly with Eudora the detaching/re-attaching is easier. In the future (maybe not too distant), a workstation user may be able to double-click on the attachment and have MSWord launched directly on the workstation, without having to go to the PC (it is not certain that this will be available but we are considering it). 5. Word attachment is from a Mac user Q: What if my Word attachment is from a Mac user? It has a weird format. A: In addition to what is mentioned in the previous Q&A, the final wrinkle is that MSWord attachments from some Mac users can be in binhex format as well. This involves another step: detach the file as before, but now rlogin to r2d2, set the display to your workstation, and start MAE (Mac Application Environment interface). Then launch Stuffit-Expander and point to the detached file and expand it. That will produce the actual MSWord document. (It **may** be necessary to alter the name to .DOC for MSWord to correctly recognize it). Now you can go to the public PC, etc., although when sending it back, it's not really necessary to binhex it again. We are also exploring other Unix utilities for binhex file conversion. 6. Reading binhex attachments Q: I'm rlogged into r2d2 and I have an MAE window displayed to my workstation. I have a binhex file that I'm trying to read, but I can't find binhex. Please advise. A: The software for decoding binhex on MAE is Stuffit Expander. To find it, go to the control panels and open the launcher. Stuffit Expander in located on the third-party tab. 7. Stuffit Expander error Q: I'm told "The application StuffIt Expander has unexpectedly quit because an error of type 1 occurred". The last time I tried this I was told that the file that I was trying to expand was not a complete binhex file. I got it as an attachment in a mail message. I dragged and dropped the icon using mailtool and file manager to separate the file from the rest of the message. What didn't I do? A: You need to remove the first two lines as well. Since the file is now in your home directory, you can go to the public PC and open the document via the Network Neighborhood. 8. MIME attachments Q: Sometimes I get attachments to mail that are mime-encoded (some standard Microsoft utility), that I can't seem to open. Is there a solution on the Unix workstations for this? A: MIME (Multipurpose Internet Mail Extensions) is an Internet mail standard. It's not Microsoft. In general, there is no universal solution to all MIME types on Unix, nor is there on any other OS. MIME is a protocol for how to handle attachments, not a program or something which displays them. So, the simple answer is no. Under dtmail Options, Advanced Options heading, select "Use strict MIME character encoding". 9. MediaMail error reports as attachments Q: MediaMail is now sending error reports as attachments to mail messages. When I try to read them I get the error "No program provided for multipart/report". Now what? A: This is a standard feature of returned messages in the latest version of MediaMail. To view the error report: In the Message Window select the Message menu option and go down to Attachments (or type Control-A while in the Message Window). You'll see the attachements (you may need to play with the button selections to change it to text/plain, for example), then click the Display button and you'll see the text of the error report. 10. Binary attachment and base64 encoding Q: I just received some strange email; is it binary? How do I read it? A: This is a general issue of base64 encoding. The message should have been automatically decoded. If it hasn't, please report the problem to trouble. 11. uuencode/uudecode Q: Someone needs to send me a file which is uuencoded. How do they send it to my PC without it coming across garbled? I'm using Eudora on my PC. A: First try using dtmail from Unix to Attach (as an Attachment) the binary file to an email message to yourself; no uuencoding. Next look at the new email message and see if the binary file comes across as an attachment in Eudora. Then save the file from Eudora and try using the application on it. Or you can save the file into your Unix directory (accessible through the Network Neighborhood and FileServer from your PC), then login to hao and run uudecode on the file. Usually a uuencoded file will start with a line which tells you what the filename will be that it creates, such as begin filename You then run uudecode as uudecode file-you-saved and it creates "filename". If you are able to get the file sent as a binary attachment, Eudora then decodes it successfully. You could also request your collaborators not use uuencode. 12. RTF attachments Q: The document attached to my email is a Word document with .rtf extension, VITAE.RTF. Will dtmail do the uudecode itself? A: That file is indeed uuencoded. You need to cut the portion starting with "begin" and place it into another file, then use uudecode to get the original file (see previous Q&A). 13. PDF attachments Q: I received a .pdf file and have some vague information that I need Adobe Acrobat to read it. Do we have means to read it at HAO? A: A .pdf file can be read using Adobe Acrobat on any of the public PC's at HAO. Alternately, in the PUBLIC software directory, the program acroread will display the file under unix. 14. Other suggestions Q: I just received another attachment that our system does not know how to interpret. What do I do now? A: When looking at the attachment in dtmail, it shows a Framemaker icon. Double-clicking on the attachment brings it up a window in Framemaker. Framemaker doesn't recognize the format so it opens a window which asks me which data type to convert from. In this case I selected Word. It then converted the document into a readable form in Framemaker. As an example, FrameMaker version 5.5 can read Microsoft Word and WordPerfect documents, although it will lose some parts of the document, such as graphics. Consider Framemaker to be a partial solution, which you can use directly on the Unix platform but with limitations. If you need complete compatibility, then you need to use the actual program used to create the attachment. --Leonard --Leonard E. Sitongia Computer System Management Team (CSMT) sitongia@ncar.ucar.edu voice: (303)497-1509 fax: (303)497-1589 High Altitude Observatory P.O. Box 3000 Boulder CO 80307 USA