Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

Deecting attachments

 [1/3] from: philb::upnaway::com at: 29-Jun-2001 0:28

Hi rebolers, What is the best was (ie covers all posibilities) of checking to see if an email has attachments? Is the best was to check the Content Type? Cheers Phil

 [2/3] from: jelinem1:nationwide at: 28-Jun-2001 14:18

As an example, have a look at: I found the need to enhance this script. In several situations it failed for me; something about varying syntax in the attachment declaration (within the email). I don't pretend to know the specifications of attachments, I just hacked fixes to the script based on emails that I received. - Michael Jelinek From: [philb--upnaway--com] on 06/28/2001 11:28 AM Please respond to [rebol-list--rebol--com] Sent by: [rebol-bounce--rebol--com] To: cc: Subject: [REBOL] Deecting attachments Hi rebolers, What is the best was (ie covers all posibilities) of checking to see if an email has attachments? Is the best was to check the Content Type? Cheers Phil

 [3/3] from: brett:codeconscious at: 29-Jun-2001 11:47

As far as I've seen with the limited set of emails I've been sent by friends, attachments are something you may have to search for. Content-Type is part of the MIME specification for messages. The MIME specification specifies the structure of messages and how attachments should be dealt with. Briefly, according to my reading of the spec, internet messages (including email) were fairly simple, meant to be read and composed manually. Lots of servers etc were built to handle them. Later, when people wanted to send a more semantically rich message they came up with MIME (rfc 1521). But so as not to break the old transport systems and clients they made MIME "fit within" an old message. That is a MIME message looks like an old message (rfc822), but if you know how to read it you can get more from it. Not all messages are MIME messages though (so if you use IMPORT-EMAIL on a non-MIME message you should ignore content-type field of the resulting object - it is meaningless). No doubt before MIME came along people were sending attachments (and still do without using MIME). The old/standard transport mechanisms for emails could only handle 7bit characters, so to send a binary you need to convert it. One way is to get the file and "uuencode" it. Uuencoding (unix-to-unix encode) converts data into a series of 7-bit ASCII characters. This series is inserted into the body of the email message. It normally begins with begin xxx where xxx is the unix permission of the file. Therefore in this case your program needs to search for the attachment. MIME also has mechanisms for converting data to 7-bit representations. One is quoted-printable and the other is base-64. Quoted-printable is still fairly readable, base-64 is appropriate for binary streams. MIME is nice in that it tells you explicitly what the encoding is in the content-type header. The detach.r script in the library works only on MIME messages. It dispenses with attempting to read the MIME structure of a message and just searches for base-64 encoded streams of information - assuming these are the attachments. Which is probably a fairly reasonable assumption that has the benefit of keeping the script small (3K). I've made 25K of related code (inetmsg-model.r and supporting scripts) which you can find on my rebsite "Code C.". These scripts parse the structure of the MIME messages and make an attempt at uuencoded attachments. Unfortunately it appears to have been broken by View 1.2.1 - a suspected bug in Rebol. It does work with View 1.2 and Core 2.5 Brett.