Hi Catherine,

> I'm using libcurl for sending mail via SMTP. And until now I have
> encountered very little problems. But during testing I've discovered a
> strange and very difficult to reproduce bug. Some attachments get
> corrupted when sent via libcurl and yet it's very hard to find a
repeatable
> pattern.

Interesting - I've not seen this myself yet and I'm transferring files that
are megabytes big so I'm quite interested if it is an issue.

> To encode attachments I use base64 (Content-Transfer-Encoding:
> base64 and Content-Disposition: attachment
> ) and <CR><LF> for line ending.

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

You'll note that I've included a dummy filename and changed the size data
for clarity as well ;-)

> Inspecting the sent data via the debug mode (CURLOPT_DEBUGFUNCTION)
> I've been able to find where the problem is occurring.
>
> When libcurl is sending data, if at the end of CURL_MAX_WRITE_SIZE
> (16834 bytes) the message (in this context base64 encoded lines) is
> near a line ending libcurl will add a dot :

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?

> I guess the dot is added in the vicinity of a line ending. But I can't be
> more precise, the problem could be in this function
> Curl_smtp_escape_eob (smtp.c)

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).

> I'd appreciate any take on this especially if you think this is not a
libcurl bug.

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

Additionally, are you able to post the contents of your debug function to
rule that out as well?

Kind Regards

Steve

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-10-19