Do you have the complete input file, or a minimal repro? What generated it?

Is this a multipart document embedded in a multipart part?

I can imagine what the bug might be, but I'd still like to have a repro case. It would save me time trying to generate it.

MIME-Version: 1.0
X-Mailer: PHP/5.4.25
Content-Type: multipart/related; boundary="----=_NextPart_4c2fbafd7ec4c8bf08034fe724b608d9"

------=_NextPart_4c2fbafd7ec4c8bf08034fe724b608d9
Content-Type: multipart/alternative; boundary="----=_NextPart_4c2fbafd7ec4c8bf08034fe724b608d9_alt"

------=_NextPart_4c2fbafd7ec4c8bf08034fe724b608d9_alt
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

This is a multi-part message in MIME format.

------=_NextPart_4c2fbafd7ec4c8bf08034fe724b608d9_alt
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit

html things
------=_NextPart_4c2fbafd7ec4c8bf08034fe724b608d9_alt--
------=_NextPart_4c2fbafd7ec4c8bf08034fe724b608d9--

Thanks.

This fix works for me:
https://play.golang.org/p/p4-qqQLEW5

At the line 36,
I check if the nlDashBoundary is found and terminated by a '\n'
else if the dashBoundaryDash is found.

Too late for Go 1.5.

@rsc, I have a fix for this at https://go-review.googlesource.com/11811 and it'd still be nice to get into Go 1.5 since this isn't some hypothetically fuzzer case, but generated by a real client library, and this is our fault.

CL https://golang.org/cl/11811 mentions this issue.