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:
http://www.reboltech.com/library/scripts/detach.r
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]@rebol.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.