vmime/tests/parser, branch master

Fix a test failure in testNewFromString (#311)

2024-06-11T18:47:53Z

Fixes an oversight in d296c2d1.

vmime: prevent loss of a space during text::createFromString (#306)

2024-05-21T13:55:06Z

``` mailbox(text("Test München West", charsets::UTF_8), "a@b.de").generate(); ``` produces ``` =?us-ascii?Q?Test_?= =?utf-8?Q?M=C3=BCnchen?= =?us-ascii?Q?West?= ``` The first space between ``Test`` and ``München`` is encoded as an underscore along with the first word: ``Test_``. The second space between ``München`` and ``West`` is encoded with neither of the two words and thus lost. Decoding the text results in ``Test MünchenWest`` instead of ``Test München West``. This is caused by how ``vmime::text::createFromString()`` handles transitions between 7-bit and 8-bit words: If an 8-bit word follows a 7-bit word, a space is appended to the previous word. The opposite case of a 7-bit word following an 8-bit word *misses* this behaviour. When one fixes this problem, a follow-up issue appears: ``text::createFromString("a b\xFFc d")`` tokenizes the input into ``m_words={word("a "), word("b\xFFc ", utf8), word("d")}``. This "right-side alignment" nature of the whitespace is a problem for word::generate(): As per RFC 2047, spaces between adjacent encoded words are just separators but not meant to be displayed. A space between an encoded word and a regular ASCII text is not just a separator but also meant to be displayed. When word::generate() outputs the b-word, it would have to strip one space, but only when there is a transition from encoded-word to unencoded word. word::generate() does not know whether d will be encoded or unencoded. The idea now is that we could change the tokenization of ``text::createFromString`` such that whitespace is at the *start* of words rather than at the end. With that, word::generate() need not know anything about the next word, but rather only the *previous* one. Thus, in this patch, 1. The tokenization of ``text::createFromString`` is changed to left-align spaces and the function is fixed to account for the missing space on transition. 2. ``word::generate`` learns how to steal a space character. 3. Testcases are adjusted to account for the shifted position of the space. Fixes: #283, #284 Co-authored-by: Vincent Richard

tests: switch a byte sequence in textTest (#305)

2024-05-21T13:48:26Z

Switch out the byte sequence by one that is simiarly random, but one which happens to decode as valid UTF-8, such that the expected and actual strings are shown with reasonable characters on a terminal.

Fixes/comments for guessBestEncoding (#304)

2024-05-21T13:47:05Z

* tests: add case for getRecommendedEncoding * vmime: avoid integer multiply wraparound in wordEncoder::guessBestEncoding If the input string is 42949673 characters long or larger, there will be integer overflow on 32-bit platforms when multiplying by 100. Switch that one computation to floating point. * vmime: update comment in wordEncoder::guessBestEncoding

vmime: avoid changing SEVEN_BIT when encoding::decideImpl sees U+007F (#303)

2024-05-21T13:45:29Z

* vmime: avoid changing SEVEN_BIT when encoding::decideImpl sees U+007F Do not switch to QP/B64 when encountering U+007F. U+007F is part of ASCII just as much as U+0001 is. --------- Co-authored-by: Vincent Richard

Fixed possible recursion crash when parsing mailbox groups.

2022-01-25T09:28:20Z

Prevent accessing empty buffer

2021-05-15T20:32:24Z

Avoid force-encoding display names that fit within qcontent

2020-12-11T22:10:39Z

When the display name contains an At sign, or anything of the sort, libvmime would forcibly encode this to =?...?=, even if the line is fine ASCII which only needs quoting. rspamd takes excessive quoting as a sign of spam and penalizes such mails by raising the score (rule/match: TO_EXCESS_QP et al.)

#238 Fixed whitespace between encoded words

2020-06-16T17:47:33Z

Added test.

2020-06-02T16:13:34Z