Possible SMTP command line length conformance issue in Exim 4.99.4

Dear Exim maintainers,


I am testing SMTP implementation conformance against RFC 5321 and found two possible conformance issues in Exim 4.99.4. I would like to confirm whether these behaviours are intentional compatibility choices or should be treated as bugs.


Tested version:
   - Exim tag: exim-4.99.4 - Commit: aae0c4c3fba1f7e50971ba250ddbbedb583d48a6
   - Source: https://code.exim.org/exim/exim.git
   - Local build from the tagged source, with no tracked source modifications


Issue 1: HELO/EHLO accepts overlong Domain / label arguments


RFC 5321 Section 4.1.1.1 defines:
ehlo = "EHLO" SP ( Domain / address-literal ) CRLF
helo = "HELO" SP Domain CRLF


RFC 5321 Section 4.5.3.1.2 limits a domain name or number to 255 octets. RFC 1035 also limits a label to 63 octets.


In my tests, Exim accepts the following malformed HELO/EHLO arguments and returns 250 success:


1. Domain text length 256 octets:
"a"*63 + "." + "b"*63 + "." + "c"*63 + "." + "d"*62 + "." + "e"
Observed:
HELO <domain_256> 250
EHLO <domain_256> 250
Both were stable over 100/100 runs.


2. Single label length 64 octets:
"a"*64 + ".com"
Observed:
HELO<label64> .com -> 250
EHLO <label64> .com -> 250
Both were stable over 100/100 runs.


These command lines are below the 512-octet SMTP command line limit, so this is separate from a command-line-length issue. The apparent issue is that the HELO/EHLO Domain argument itself is not checked for domain/label length limits.


Issue 2: LF-only command lines and LF-only DATA terminator are accepted


RFC 5321 specifies SMTP commands using CRLF line endings. More importantly, Section 4.1.1.4 says the DATA terminator is: 
   <CRLF>.<CRLF>
The same section explicitly says SMTP server systems MUST NOT accept bare LF line endings as equivalent, and in particular MUST NOT treat:
   <LF>.<LF>
as equivalent to the DATA terminator.


In my tests, Exim accepts LF-only input:
HELO example.com\n -> 250
EHLO example.com\n -> 250
Both were stable over 100/100 runs.


For DATA, this sequence was also accepted:
HELO example.com\r\n
MAIL FROM:\r\n RCPT TO:\r\n
DATA\r\n
Subject: x\n
\n
body\n .
\n


Observed:
250 OK id=
This was stable over 100/100 runs. The control case using the standard . terminator also returned 250 as expected.


I noticed that src/src/smtp_in.c documents and implements command reading by checking only LF:
          while ((c = (receive_getc)(buffer_lim)) != '\n')


I understand this may be a historical interoperability choice, but RFC 5321 appears especially strict for the DATA terminator case.
Could you please confirm whether these behaviours are intentional in Exim, or whether they should be reported as conformance bugs?


I am not claiming memory corruption, authentication bypass, or remote code execution. The impact I see is protocol conformance divergence and possible message-boundary disagreement with strict SMTP clients, proxies, or protocol state-machine checkers.


I can provide minimal reproducer scripts and JSON evidence files if helpful.


Best regards,
Bocheng Cao