GpgFrontend/vmime
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Skip delimiter lines that are not exactly equal to the boundary

Browse Source 
There is crap software out there that generates mails violating the
prefix ban clause from RFC 2046 §5.1 ¶2.

Switch vmime from a prefix match to an equality match, similar to
what Alpine and Thunderbird do too.
This commit is contained in:
Jan Engelhardt 2019-10-05 11:24:48 +02:00
parent df32418df5
commit b06e9e6f86
2 changed files with 56 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
src/vmime/body.cpp
View File

@ -53,6 +53,11 @@ body::~body() {
}
/*
* boundaryStart: will become the index for "\r\n--marker"
* boundaryEnd: will become the index after "marker", i.e. index for potential trailing "--", "\r\n", etc.
* return value: index for "marker"
*/
// static
size_t body::findNextBoundaryPosition(
const shared_ptr <utility::parserInputStreamAdapter>& parser,
@ -271,6 +276,19 @@ void body::parseImpl(
boundaryEnd += 2;
} else if (boundaryEnd < end && parser->peekByte() == '\n') {
++boundaryEnd;
} else if (boundaryEnd == end) {
} else {
/*
* RFC 2046 §5.1.1 page 19: """[...] optional
* linear whitespace, and a terminating
* CRLF.""" — junk handling is left
* unspecified, so we might as well skip it to
* facilitate broken mails.
*/
boundaryEnd += parser->skipIf([](char_t c) { return c != '\n'; }, end);
pos = findNextBoundaryPosition(parser, boundary, boundaryEnd, end, &boundaryStart, &boundaryEnd);
--index;
continue;
}
if (index == 0) {

38
tests/parser/bodyPartTest.cpp
View File

@ -39,6 +39,7 @@ VMIME_TEST_SUITE_BEGIN(bodyPartTest)
VMIME_TEST(testGenerate7bit)
VMIME_TEST(testTextUsageForQPEncoding)
VMIME_TEST(testParseVeryBigMessage)
VMIME_TEST(testParseBoundaryPrefix)
VMIME_TEST_LIST_END
@ -373,4 +374,41 @@ VMIME_TEST_SUITE_BEGIN(bodyPartTest)
VASSERT("2.2", vmime::dynamicCast <const vmime::streamContentHandler>(body2Cts) != NULL);
}
void testParseBoundaryPrefix() {
/*
* Clients are not supposed to create boundary identifiers that
* contain a prefix of another (RFC 2046 section 5.1), but alas
* CANCOM FortiMail produces this garbage.
*/
vmime::string str =
"Content-Type: multipart/related; boundary=\"--b12\"\r\n"
"\r\n"
"----b12\r\n"
"Content-Type: multipart/alternative; boundary=\"--b12-1\"\r\n"
"\r\n"
"----b12-1\r\n"
"Content-Type: text/plain; charset=utf-8\r\n"
"\r\n"
"P11\r\n"
"----b12-1\r\n"
"Content-Type: text/html; charset=utf-8\r\n"
"\r\n"
"P12\r\n"
"----b12-1--\r\n"
"----b12\r\n"
"\r\n"
"P2\r\n"
"----b12--\r\n";
vmime::bodyPart relco;
relco.parse(str);
auto relbd = relco.getBody();
VASSERT_EQ("global-partcount", 2, relbd->getPartCount());
auto altbd = relbd->getPartAt(0)->getBody();
VASSERT_EQ("part1-partcount", 2, altbd->getPartCount());
VASSERT_EQ("part1.1-body", "P11", extractContents(altbd->getPartAt(0)->getBody()->getContents()));
VASSERT_EQ("part1.2-body", "P12", extractContents(altbd->getPartAt(1)->getBody()->getContents()));
VASSERT_EQ("part2-body", "P2", extractContents(relbd->getPartAt(1)->getBody()->getContents()));
}
VMIME_TEST_SUITE_END