chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] hato multipart/alternative


From: Andy Bennett
Subject: Re: [Chicken-users] hato multipart/alternative
Date: Wed, 10 Apr 2013 17:48:35 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.9) Gecko/20121014 Icedove/10.0.9

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.


-----
(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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]