Commit 1cbfce29 authored by rswindell's avatar rswindell
Browse files

Correctly detect a "last boundary delimeter":


Without this change, some attachment (e.g. from gmail) would not be correctly
decoded because gmail would not insert any blank lines between the end of the
nested multipart/alternative part and the beginning of the attachment part:
Content-Type: image/jpeg;
Content-Disposition: attachment;
Content-Transfer-Encoding: base64

It looks (from RFC2046) like boundary delimeters should actually be:
"\r\n--<boundary>", but I'll look into that later.
parent 62a5db2d
......@@ -361,6 +361,8 @@ static char* mime_getcontent(char* buf, const char* content_type, const char* co
txt = buf;
while((p = strstr(txt, boundary)) != NULL) {
txt = p+strlen(boundary);
if(strncmp(txt, "--\r\n", 4) == 0)
p = strstr(txt, "\r\n\r\n"); /* End of header */
......@@ -429,7 +431,7 @@ char* SMBCALL smb_getplaintext(smbmsg_t* msg, char* buf)
return buf;
/* Get just an attachment (just one) from MIME-encoded message body */
/* Get just a base64-encoded attachment (just one) from MIME-encoded message body */
/* This function is destructive (over-writes 'buf' with decoded attachment)! */
uint8_t* SMBCALL smb_getattachment(smbmsg_t* msg, char* buf, char* filename, size_t filename_len, uint32_t* filelen, int index)
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment