Not that it matters all that much since it's working for your application, but I think the reason it's responding straight away to your "EHLO" command from telnet is because the Microsoft Windows telnet client doesn't enter linemode by default, violating the following section from RFC854 page 4:
TRANSMISSION OF DATA
Although a TELNET connection through the network is intrinsically
full duplex, the NVT is to be viewed as a half-duplex device
operating in a
line-buffered mode. That is, unless and until
RFC 854 May 1983
options are negotiated to the contrary, the following default
conditions pertain to the transmission of data over the TELNET
connection:
1) Insofar as the availability of local buffer space permits,
data should be accumulated in the host where it is generated
until a
complete line of data is ready for transmission,
Looking at traces from a Windows telnet client, it's clear that the MS client sends "E", "H", "L", and "O" in their own individual segments despite not having negotiated non-linemode operation, triggering the rule right after the "O" is transmitted.
If you tested from a Unix derivative or a Linux box whose telnet client entered linemode by default unless it was negotiated to the contrary it should work fine.
As I mentioned, this is probably largely academic at this point though.