SOCKS5 host framing uses character length for the port offset

[MicroMilo]

Summary

The SOCKS5 domain-name request writes the host as UTF-8 bytes, but computes the port position with host.length(). For a non-ASCII host, character count and UTF-8 byte count differ, so the port overwrites part of the host bytes and the request frame is malformed.

Code path

• modules/authenticated-socks-module/src/main/java/org/simplejavamail/internal/authenticatedsockssupport/socks5client/SocksCommandSender.java:86-107.
• Lines 90 and 98 use the UTF-8 byte length and bytes.
• Lines 100-101 use host.length() instead of the encoded byte length.

Steps to reproduce

The framing error can be reduced to this wire-layout calculation:

host = "例.com"
encoded = host.encode("utf-8")
assert len(encoded) != len(host)

expected_port_offset = 5 + len(encoded)
current_port_offset = 5 + len(host)
assert current_port_offset < expected_port_offset

With the current implementation, the port bytes begin before the copied UTF-8 host bytes have finished, so a SOCKS5 server receives a corrupted domain request.

Expected behavior

The port must immediately follow the encoded host bytes. The offset should be based on the same UTF-8 byte array that was written to the frame.

Actual behavior

The port offset is based on Java character count. ASCII hosts work by accident; non-ASCII hosts produce an invalid frame.

Existing coverage

The checked issue and PR history did not contain an exact report or fix for this UTF-8 length/offset mismatch.

Suggested fix

Reuse the encoded host byte array and use its length for both frame allocation and port offsets.

Suggested tests

• ASCII host such as example.com.
• A host containing one non-ASCII code point.
• A host containing multiple multi-byte UTF-8 code points.
• Assert the exact request bytes received by a fake SOCKS5 server.

---

Submitted with Codex.

[MicroMilo]

Thanks for the maintainer confirmation on #669 and #670. Both findings were accepted as valid: they were fixed on develop in commit da5a34e and targeted for 9.1.4, while the caller-owned stream contract remains unchanged.

For transparency, after deduplication our current review contains 22 candidate root causes in this repository. Four are now submitted (#669, #670, #674, and #675), leaving 18 not yet submitted: 15 additional SOCKS lifecycle/protocol cases, 2 held for confirmation, and 1 URLDataSource case held back because validation produced 1 bug versus 10 no-bug results. We will re-check upstream issues and pull requests before submitting any remaining case and will avoid duplicates.

[bbottema]

Fixed on develop in d7c2990. SOCKS5 domain connect requests now use the UTF-8 byte length consistently for both the length octet and port offset, so internationalized hostnames no longer have trailing bytes overwritten. Scheduled for 9.1.5.

[bbottema]

The fix is now available in Simple Java Mail 9.1.5 and from Maven Central.