After fast look on RFC 5321, i don't see exact place what describes how
to handle "500 Line too long".
AFAIK there isn't one. Unlike some other standards processes, we don't spend
much time trying to nail down how illegal inputs have to be handled in most
cases. (And IMO this is a very good thing - having been down this road in other
standards processes I've observed it takes a fantastic amount of time for
almost no benefit.)
In fact I would argue that we've done ourselves no good in the few cases when
we've gone down this path ourselves. The specified handling of bare CR and LF
is a case in point - I'm on record on that one as believing that what we've
done has actually harmed interoperability.
Must server junk bytes(if max line exceeded) and try to read CRLF, after
that returns "500 Line too long".
or
Must server send "500 Line too long" straight away.
The problem is the "right" answer depends on the client's intent, which of
course the server doesn't know. If the nefarious intent of the client is to
overrun the server with garbage, the right answer is to send the error once the
condition is detected. Waiting for a CRLF that's hever going to arrive isn't
useful.
But this fails in the case of a client that is confused in some way and for
whatever reason is sending a legitimate mail that happens to be too long. In
this case sending a response before getting the CRLF will probably
desynchronize the protocol.
There are also many other options. One is to have two threshholds, one where
the line has gotten too long but things still look legit, the other for
when the server believes it is just getting garbage from the client.
Another set of implementation choices revolves around whether or not the server
should disconnect in such situations. If the server decides that the client is
simply spewing garbage without end, disconnection, while frowned upon by the
specifications, is probably the right thing to do. But the devil is in the
detail of determining that this is really what's going on.
There's also a big difference between SMTP commands that are too long and
message lines that are too long, and arguably a distinction might even be drawn
between DATA and BDAT transfers. An error needs to be returned in the case of
an overly long command. The situation with message data is more ...
interesting. While RFC 5321 (incorrectly IMO) talks about not having limits on
things whenever possible, RFC 5322 is quite clear that line lengths MUST be
limited. So rejecting messages with overly long lines is a valid choice. But
it's hardly optimal, and in this case truncation, wrapping, or even forced MIME
encoding are all viable alternatives.
In any case, it strikes me that you're looking for a sort of implementation
guidance in the RFCs that just isn't there, and IMO at least its absence is
almost always a feature, not a bug.
Ned