I do not think MailPort is an obfuscand. Likewise, any directive which is not defined, or whose value is an empty string, could be skipped. But how would your obfuscator work with editors? Some directives are not handled by the OPTION dialogs, and must be entered using an editor. Other tricky issues: encoding (ASCII vs. Unicode) of %_ININAME; obfuscands in included .INI files (i.e., files used by the INCLUDE directive)?
Your point about decrypting FTP.CFG when you start TCMD/TCC is still unsafe - unless it is done interactively. Below is a suggestion how it could be done safely and dynamically:
Create new .INI sections for each FTP site, in the manner of the [tab1] [tab2]:
[FTP1]
url=
alias=
username=
password=
directory=
template=
with the username and password entries encrypted. This can be done by your plugin dynamically, using the plain text file specified in the FTPCFG directive when first obfuscating. When TCC is started, the decrypting program could build the FTP.CFG file dynamically, in memory mapped files shared by all TCC instances of the current user in the same manner as aliases and functions. A new command in your plugin could invoke the IDE editor to add, change, or delete FTPCFG entries in that file. It would be the user's responsibility to wipe the original FTP.CFG file, which would no longer be accessed. Of course, eventually this method may be integrated into TCC's internal code.