IRC message truncation risk due to fixed MAX_PRIVMSG_LEN assumption #1827
Description
Summary
JoinMarket currently uses a fixed constant MAX_PRIVMSG_LEN = 450 to limit message payload size (src/jmdaemon/irc.py:12). This assumes approximately 62 bytes of overhead for the IRC message prefix (:{nick}!{ident}@{host} PRIVMSG {target} :), bringing the total line length to ~512 bytes (the IRC protocol limit including CRLF).
This does not appear to be causing issues in the current production setup, but the fixed assumption could become problematic in certain deployment environments, particularly because failures would be silent and difficult to diagnose.
Background
The IRC protocol (RFC 1459/2812) specifies a maximum line length of 512 bytes including:
- The prefix: :{nick}!{ident}@{host}
- The command and parameters: PRIVMSG {target} :{payload}
- The line terminator: \r\n
The current implementation calculates chunk sizes based on MAX_PRIVMSG_LEN, assuming the prefix overhead is fixed. In many IRC setups (short hostnames, cloaked hosts, typical Tor exits), this works fine. However, if the actual prefix exceeds the assumed overhead, messages could be truncated by the IRC server.
Primary concern: Silent failure
The main issue is that if truncation occurs, there would be no clear error message or indication to the user. The chunking reassembly logic expects specific trailer markers ( ; for continuation, ~ for completion), and if these are truncated, messages may be silently dropped or misparsed.
This could potentially manifest as intermittent connection issues or communication failures that are difficult to diagnose, as the symptoms would be deployment-specific and users wouldn't receive clear feedback about what went wrong.