Fixed in WFTPD Pro 3.0 Release 3:
1. A GPF in Windows Security Model logins has been fixed.
2. Restricted users can now access their files again.

Fixed in WFTPD Pro 3.0 Release 2:
1. The use of "/.." to exceed restrictions has been stopped.

New to WFTPD Pro 3.0:

The biggie - Windows user database authentication.
Random PASV port assignment.
PASV port assignment from a range (for firewalled sites)
Security review of all code for common (and uncommon) exploits.

Current issues in WFTPD Pro 3.0:

1. To support the "Windows" Security Model, the service needs to be running in the context of a user who has "Act as part of operating system" privilege - aka "SE_TCB_NAME".  Doesn't have to be enabled, just owned.  Perhaps WFTPD Pro should complain if it doesn't have this privilege?  Should the check be at the start of the service, or whenever you try to start a server that has "Windows" Security Model set?
2. Virtual directory support, similar to IIS, would be somewhat of a nice thing, but requires some considerable effort.  Won't be done in version 3.0.


Features to be put into WFTPD 3.0:
1. Port range.
2. Random port assignment.
3. Move RFC 2577-related features to a new "Advanced" Security Dialog, as per WFTPD Pro.
4. If bound to 0.0.0.0, list as many IPs as possible, and let the user know that these are (some of the) addresses that are being listened to.  OR, have a button to list IP addresses ("Help | What's my IP address?")


An eye to the future:

Currently, there are a few features that we are interested in implementing for future versions (in no particular order):
1. SSL or some other form of encryption - to allow authentication (user names, passwords, etc) to pass without being readable to others, and to encrypt data streams to provide authenticity _and_ protection against sniffing.
2. Access to some form of outside database for user configuration information.  Probably through ODBC, but open to any good suggestions.  Perhaps even RADIUS, LDAP, etc?  Could be done through use of external DLLs - see item 3.
3. Expand the external DLL capabilities - call user-supplied functions on logoff, when asking for rights, etc.  Suggestions are solicited for sample DLLs to be provided.
4. (somewhat of a long shot, perhaps) Write a remote admin client that uses only the FTP control connection, to allow distribution to customers renting FTP space.  We might charge per seat on such a tool.  This tool would probably require writing much of an FTP client, and there's a possibility that the SSL support would suggest a custom client as well, so this may be a future product avenue.
5. Virtual directories like IIS does them - invisible to the OS, but visible in the FTP server.  Somewhat disturbs me, since this is a _file_ transfer protocol server, not a "made up thing to look like a file" transfer protocol server.
