Hi Steve,

> I tend to send the following information in my message header:
>
> Content-Type: multipart/mixed; boundary="pj+EhsWuSQJxx7pr"
> Mime-version: 1.0
>
> Note: The boundary is generated for each message (and sub messages if I am
> including plain text and html data as well) and then I send the following in
> my message body:
>
> --pj+EhsWuSQJxx7pr
> Content-Type: application/octet-stream; name="filename.ext"
> Content-Transfer-Encoding: base64
> Content-Description: filename.ext
> Content-Disposition: attachment; filename="filename.ext"; size=xxxxx
>
> base64 data removed for clarity
>
> --pj+EhsWuSQJxx7pr--
>

A typical message will look like this :

Date: Mon, 17 Oct 2011 22:03:21 +0200
From: ...
MIME-Version: 1.0
To: ...
Subject: =?UTF-8?B?dGVzdA==?=
Content-Type: multipart/mixed;
  boundary=
"BgaWo2KQ9TGhMveuXnAsxHd0Rr5Cji3EPmIUDV714tqSbkYlf6ZFw8OcJNLzpy"

This is a multi-part message in MIME format.
--BgaWo2KQ9TGhMveuXnAsxHd0Rr5Cji3EPmIUDV714tqSbkYlf6ZFw8OcJNLzpy
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

test att.

--BgaWo2KQ9TGhMveuXnAsxHd0Rr5Cji3EPmIUDV714tqSbkYlf6ZFw8OcJNLzpy
Content-Type: application/pdf;
  name="=?UTF-8?B?MTM4Ni5wZGY=?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
  filename*=UTF-8''%31%33%38%36%2E%70%64%66

JVBERi0xLjQNJeLjz9MNCjQ1IDAgb2JqDTw8L0xpbmVhcml6ZWQgMS9MIDcwNzYz
L08gNDcvRSAzMTM1Mi9OIDQvVCA3MDM5OS9IIFsgNTA3IDIyNV0+Pg1lbmRvYmoN
...
ICAgICAgICAgICAgICAgICAgDQo2NSAwIG9iag08PC9EZWNvZGVQYXJtczw8L0Nv
bHVtbnMgNC9QcmVkaWN0b3IgMTI+Pi9GaWx0ZXIvRmxhdGVEZWNvZGUvSURbPEQ0
MTYNCiUlRU9GDQo=
--BgaWo2KQ9TGhMveuXnAsxHd0Rr5Cji3EPmIUDV714tqSbkYlf6ZFw8OcJNLzpy--

> You mentioned the issue was hard to reproduce but do you see the dot every
> 16384 bytes when you do see the problem or is it a one off?

You'll see in the thread that I've just posted a small test program
that will always reproduce the error. The error was hard to
reproduce in real life conditions cause you need <CR><LF> at the end
of the CURL_MAX_WRITE_SIZE and depending on your header, your body,
your attachment name etc... CURL_MAX_WRITE_SIZE could always end on
some random character.

> Are you able to debug you application and add a breakpoint in
> Curl_smtp_escape_eob() to see if it is this function has an issue. I would
> suggest putting the break point in the if block near the end of the function
> that starts if(si != nread).

Right now I'm using libcurl as a shared library (dll) in MSVC10
(Windows), so I can't/don't know how to do this.
I'll have to build my test with the relevant libcurl .c files to put
a breakpoint in source file (that I can do). I'll see if I can
manage to do this (I don't know if the libcurl make files for
windows are doing some special preprocessing that'll prevent this).

> How are you passing your data to libcurl (eg. As a FILE* or via
> CURLOPT_READFUNCTION) and what version of libcurl are you using?

Latest version of libcurl 7.22, Windows 7, Visual C++ Express 2010.
I'm using a CURLOPT_READFUNCTION, I'll try to pass FILE* to see if
it changes something.

Thanks for your answer.

--
Catherine
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html