Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: DBMail: users

correctnes of bodystructure

 

 

DBMail users RSS feed   Index | Next | Previous | View Threaded


marc at electronics-design

Feb 3, 2009, 6:55 AM

Post #1 of 3 (403 views)
Permalink
correctnes of bodystructure

Hi,

If I let a client fetch the bodystructure of messages I get the
following 2 examples:

BODYSTRUCTURE ("text" "plain" ("charset" "us-ascii") NIL NIL "7BIT" 125 12 NIL ("inline" NIL) NIL NIL))

BODYSTRUCTURE (("text" "plain" ("charset" "us-ascii") NIL NIL "7bit" 324 14 NIL NIL NIL NIL)("text" "html" ("charset" "us-ascii") NIL NIL "quoted-printable" 1601 36 NIL NIL NIL NIL) "alternative" ("boundary" "----=_NextPart_000_0008_01C98611.CBB36EF0") NIL NIL NIL))


RFC3501 it says that
<quote>
Extension data follows the multipart subtype. Extension data
is never returned with the BODY fetch, but can be returned with
a BODYSTRUCTURE fetch. Extension data, if present, MUST be in
the defined order.
</quote>

Now, in the first example, the message clearly is not a multipart
message. How is it that extension data still is being returned?
Referring to " NIL ("inline" NIL) NIL NIL".
The same is for the sub-parts of the second multipart message
Referring to " NIL NIL NIL NILu" after 14 and after 36.

Marc
_______________________________________________
DBmail mailing list
DBmail[at]dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail


paul at nfg

Feb 3, 2009, 7:41 AM

Post #2 of 3 (377 views)
Permalink
Re: correctnes of bodystructure [In reply to]

Marc Dirix @ Electronics Design wrote:
> Hi,
>
> If I let a client fetch the bodystructure of messages I get the
> following 2 examples:
>
> BODYSTRUCTURE ("text" "plain" ("charset" "us-ascii") NIL NIL "7BIT" 125 12 NIL ("inline" NIL) NIL NIL))
>
> BODYSTRUCTURE (("text" "plain" ("charset" "us-ascii") NIL NIL "7bit" 324 14 NIL NIL NIL NIL)("text" "html" ("charset" "us-ascii") NIL NIL "quoted-printable" 1601 36 NIL NIL NIL NIL) "alternative" ("boundary" "----=_NextPart_000_0008_01C98611.CBB36EF0") NIL NIL NIL))
>
>
> RFC3501 it says that
> <quote>
> Extension data follows the multipart subtype. Extension data
> is never returned with the BODY fetch, but can be returned with
> a BODYSTRUCTURE fetch. Extension data, if present, MUST be in
> the defined order.
> </quote>

>
> Now, in the first example, the message clearly is not a multipart
> message. How is it that extension data still is being returned?

Because the rfc says we must do so:

<quote>
A body type of type TEXT contains, immediately after the basic
fields, the size of the body in text lines. Note that this
size is the size in its content transfer encoding and not the
resulting size after any decoding.

Extension data follows the basic fields and the type-specific
fields listed above. Extension data is never returned with the
BODY fetch, but can be returned with a BODYSTRUCTURE fetch.
Extension data, if present, MUST be in the defined order.

The extension data of a non-multipart body part are in the
following order:
</quote>

so for non-multipart body parts extension data is returned as part of
the bodystructure fetch response.







> Referring to " NIL ("inline" NIL) NIL NIL".
> The same is for the sub-parts of the second multipart message
> Referring to " NIL NIL NIL NILu" after 14 and after 36.






--
________________________________________________________________
Paul Stevens paul at nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands________________________________http://www.nfg.nl
_______________________________________________
DBmail mailing list
DBmail[at]dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail


marc at electronics-design

Feb 3, 2009, 12:37 PM

Post #3 of 3 (380 views)
Permalink
Re: correctnes of bodystructure [In reply to]

>> Now, in the first example, the message clearly is not a multipart
>> message. How is it that extension data still is being returned?
>>
>
> Because the rfc says we must do so:
>
Ah. Sorry, I was to quick to the gun.

DBMail users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.