Bug in multipart parsing
g-regor opened this issue · comments
Gregor commented
Multipart mime types are improperly parsed. By standard, the last boundary has "--" appended, which the parser doesn't account to. This produces an erroneous mime part with only "--".
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="===============0438762424560383716=="
Subject: Subject
From: sender@localhost
To: receiver@localhost
Date: Sat, 23 Jul 2022 18:08:29 -0000
Message-Id: <165859970975.49072.13986632326735601263@localhost>
--===============0438762424560383716==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Text message
--===============0438762424560383716==
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
<!doctype html><html><body><b>HTML</b> message</body></html>
--===============0438762424560383716==--
The above email produces 3 mime parts.
Gregor commented
Packages "net/mail" and "mime/multipart" should be used for parsing.
Gregor commented
Looks like there is an existing pull request about this from 5 year ago.