On Thu, Apr 11, 2013 at 1:48 AM, Andy Bennett <andy...@ashurst.eu.org>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 <p...@knodium.com>" > To: "Andy Pandy <andy...@knodium.com>" > 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 <p...@knodium.com>" > To: "Andy Pandy <andy...@knodium.com>" > 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 > > -- > andy...@ashurst.eu.org > http://www.ashurst.eu.org/ > 0x7EBA75FF > >
_______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
