Before now, if the sysop enabled login-by-user-number and the specified login
ID *started* with a decimal digit, it'd be treated as a user number and
converted to a 32-bit integer. This could result in weird stuff, like this
error I got today:
SMTP ... !ERROR -2 getting data on user (7000401005.gc7gg@synchro.net)

7,000,401,005 is clearly greater than the number of users in my user base
on Vert, but since 7B is > 2.1B (0x7fffffff), the number would be parsed as
a *negative* integer value and thus less than the total number of users in my
userbase.

An obvious solution would be to just turn of login-by-user-number, and for
most systems, I suggest doing that (a system is less secure with it enabled).

However, I want to leave the option for sysops (at least for now) and don't
want this weird behavior so, a login by user number now requires that the
entire login ID is just decimal numbers, nothing else, and the number is
parsed as an unsigned integer. So yes, roll-over can happen for very high
numbers (>4.2B), but in no instance will the number be parsed as negative and
thus lead to an invalid user record look-up attempt.