Hi Ryan,
Actually it is a custom BeOS MIME content subtype that seems to be the
problem.
----- 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"
Rather than parse using the inbuilt parser. Could you post the header in
plain text?
Would need to see this to find out why the parser is getting it wrong. It
may be that
BeOS is not breaking the line length and that a mail gateway is being
'helpful' by trimming it
>---------------------------------------
>From what I have seen in the message it seems to indicate that BeOs is using
a custom defined multipart sub type. producing a nested form of
multipart/mixed, which is not wrong, but I would be surprised if the parser
did handle it.
>----From the RFC-------
multipart -- data consisting of multiple parts of
independent data types. Four initial subtypes
are defined, including the primary "mixed"
subtype, "alternative" for representing the same
data in multiple formats, "parallel" for parts
intended to be viewed simultaneously, and "digest"
for multipart entities in which each part is of
type "message".
-------------------------
But if you look at the Boundary you will see that it is not a standard
format but rather custom content type. That of multipart/x-bfile
So it looks like you will have write some changes to detatch.r to handle
this BeOs specific subtype.
multipart/x-bfile. If you send the same message and content from both email
clients, save the message as plain text and examine the contents and the
differences you should be able to see what steps need to be added to handle
this content subtype in detach.r.
Cheers,
Allen K
>
>
>
> 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
>
>