lib-imap: imap-utf7 - Reject invalid octet in imap_utf7_to_utf8()

[nishat-06]

• I confirm that this PR does not fix, disclose, demonstrate, or discuss a suspected security vulnerability.
• I have read CONTRIBUTING.md and SECURITY.md
• I have compiled and tested this code

AI policy

Dovecot allows AI assisted or generated code, but we would like to know if it is such.
Do not include 'Co-Authored-By' header in the commit.

• This PR includes AI-generated code or text.

Type of Change

• Bug fix
• New feature
• Breaking change
• Refactor or code cleanup

Description

imap_utf7_to_utf8() is supposed to reject invalid mUTF-7, but a raw 8-bit or control octet that appears outside a shift sequence is emitted silently instead: the non-escaped path in imap_utf7_to_utf8_int() (escape_chars is "") falls into the escape branch, runs str_printfa(dest, "%c%02x", '\0', octet) which appends a NUL byte, and still returns success. That disagrees with imap_utf7_is_valid(), which rejects the same input, so a client mailbox name such as &AAE-\x80 (SELECT/CREATE/LIST via client_find_namespace_full) slips past the "not valid mUTF-7" check and yields a name containing an embedded NUL. The fix returns -1 in the non-escaped path, matching the sibling mbase64 failure branch just below it; the escaped API and every valid input are unchanged.

Additional Notes

Added test_imap_utf7_raw_octet_after_shift to test-imap-utf7.c. It sweeps every control/8-bit octet placed after a completed shift and asserts both imap_utf7_is_valid() and imap_utf7_to_utf8() reject it. The case fails on the current tree (the octet is accepted with an embedded NUL) and passes with this change, while the existing valid-input and escaped round-trip cases are unaffected.

[cmouse]

Hi! Thank you for the submission, is this a vulnerability change as you have not certified that it is not? Also this look a bit like AI assisted submission.