Re: [Chicken-users] hato multipart/alternative

[Alex Shinn]

On Thu, Apr 11, 2013 at 1:48 AM, Andy Bennett <address@hidden> wrote:

Hi,

> When specifying your own multiple Content-Type, you
> need to include the boundary:
>
>   Content-Type: "multipart/alternative; boundary=xyzzy"
>   Boundary: "xyzzy"
>
> [Ideally it should infer the boundary in this case, and it
> would also be nice to automatically generate the boundary
> when unspecified.]
>
> This should prevent everything falling out to the top-level
> as you described, though it may not generate quite what
> you want.  You can log issues on hato.googlecode.com

> <http://hato.googlecode.com>.

> If it's a bug I'll try to fix it, but feature requests will largely
> be pending the port to R7RS.
>
>
>     hato seems to generate MIME messages with a single boundary string.
>
>
> Attachments may include nested attachments, which will
> result in nested multiparts with different boundaries.  You
> should only need one top-level boundary in your case though.

Thanks for the tips. I've fiddled with it some more but I can't get it
to produce exactly the right structure.

OK, then could you file a bug?  If it's not actually broken

make it a feature request.  [One thing it needs is an option

to disable the implicit body when using attachments.]

You can file a separate bug for the timezone format.

Patches welcome!

-- 

Alex

 

-----
(send-mail From:    "Pat Andrews <address@hidden>"
           To:      "Andy Pandy <address@hidden>"
           Subject: "Hato Test"
           Charset: "ISO-8859-1"

           Content-Type: "multipart/alternative; boundary=xyzzy"
           Boundary: "xyzzy"

           Body: "Hello this is the first attachment"

           Attachments: '((Content-Type: "text/plain" Body: "This is the second
attachment")))
-----

Produces:

-----
Content-Type: multipart/alternative; boundary="xyzzy"
-----
...in the headers

and
-----
--xyzzy
Content-Type: multipart/alternative; boundary="xyzzy"; charset="ISO-8859-1"

--xyzzy
Content-Type: text/plain; charset="ISO-8859-1"

This is the second attachment

--xyzzy
Content-Type: text/plain



--xyzzy--

--xyzzy--
-----
...in the body.

The "This is the first attachment" text is mysteriously missing and the
structure of the message is wrong because there's an extra MIME header
at the start of the body.

-----
(send-mail From:    "Pat Andrews <address@hidden>"
           To:      "Andy Pandy <address@hidden>"
           Subject: "Hato Test"
           Charset: "ISO-8859-1"
           Content-Type: "multipart/alternative"

           Boundary: "xyzzy"

           Body: "Hello this is the first attachment"

           Attachments: '((Content-Type: "text/plain" Body: "This is the second
attachment")))
-----

(i.e. omiting the "boundary=" bit from the Content-Type header)

produces:

-----
Content-Type: text/plain
-----
...in the headers

and
-----
--xyzzy
Content-Type: multipart/alternative; charset="ISO-8859-1"

Hello this is the first attachment

--xyzzy
Content-Type: text/plain; charset="ISO-8859-1"

This is the second attachment

--xyzzy
-----
...in the body.


The structure of this one is *almost* correct but the Content-Type in
the header is wrong: it should be "multipart/alternative..." and the
Content-Type in the first part of the body is wrong: it should be
"text/plain". Also, there's no specification of the boundary anywhere.



Perhaps I could hack hato-smtp.scm to do what I wanted but I'm not
particularly familiar with the appropriate standards so I thought I'd
discuss it here first.

The only way I could come up with for getting hato to not generate an
extra MIME header at the start of the body was to use the Body: in
send-mail and a single attachment but that leaves no way to specify both
the fact the parts are alternative and the Content-Type of the first part.

Regards,
@ndy

--
address@hidden
http://www.ashurst.eu.org/
0x7EBA75FF