Thanks. In light of all of this I think I am going to re-write
%detach.r to specifically look for image/jpeg, image/gif, etc., content
-types since my intended purpose is to be able to detach images from an
e-mail and ignore all other attachments.
It will be "simpler" just to have the parser look for one or more of a
set of specific content-types and, if the result is true, index the
position of the content-type statements and then find the base64
information and decode.
If I rely on the more general %detach.r as it is already written, I
suspect I may run into other variations which will force me to take
those variations into account, as well.
>Thanks Ryan I received the message. It looked fine in Outlook.
>Looking at the boundary lines and headers it seems that your Be email
client
>has created two attachments.
>One for the image and one for the Be operating system attibutes for
that
>file and seperated them with boundaries. It has then wrapped both of
these
>in a different boundary to make it one attachement at the highest
email
>level. The problem, I think, is that detach.r doesnt realise this is
>possible. But I do not know enough about the protocol to know if this
is
>correct.
>
>However I did get the image saved out by doing the following.
>
>mails: read pop://bhandley.....
>; your message was the first so
>m: import-email mails/1 ; import the relevent email
>detach-results: detach import-email m/content ; treat content as
message
>print ["Filename is: " detach-results/1]
>write/binary detach-results/1 detach-results/2
>
>Hope it helps.
>Brett.
>
>----- Original Message -----
>From: <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Monday, June 12, 2000 8:54 AM
>Subject: [REBOL] /content-type and rebol/core (was Re: %detach.r)
>
>
>> OK. The newer version of %detach.r worked fine with the Windows NT/
>> Pegasus e-mail message. But it is having trouble with the BeOS R5
Pro/
>> BeMail e-mail message.
>>
>> Here are the /content-type and /content results of using 'probe to
view
>> email objects as REBOL sees them. As you can see, the "boundary="
>> statement as read by REBOL/core produces something different than
what
>> the e-mail header declares.
>>
>> Here is the /content-type as produced by 'probe
>>
>> Content-Type: "multipart/mixed; boundary=_------_BeOS.rmp.96"
>>
>>
>>
>> Here is the actual beginning of the email /content as produced by
>> 'probe
>>
>> Content: {This is a multi-part message in MIME format.
>> --_------_BeOS.rmp.960760927_------_
>> Content-Type: multipart/x-bfile;
>> ^-boundary="++++++BFile111399423249++++++"
>>
>>
>>
>> As you can see, the parsing routine within REBOL/core found the
first
>> line in /content which contains "--" and copies the line past the "-
-"
>> and only up to the "6" and then quit, as follows...
>>
>> _------_BeOS.rmp.96
>>
>> Any suggestions? Does REBOL/core for BeOS need to be fixed? Or is
Be,
>> Inc., not adhering to some e-mail message standard?
>>
>> -Ryan
>>
>
>
