This section contains some intimate informations about WAI's privacy and interior. You necessarily don't need to know them, but if you want to be informed about how the system works (and why is something acting in seemingly strange ways), you should.
Attachment handling is a little bit complicated. All message attachments are temporarilly stored in the
/attachments virtual directory. The files are created when user clicks to "download attachment" link and deleted by any other actions.
This arrangement is not optimal, I'll try to make something better in future time. This implementation has problems when the filename is containing some special characters (such as Czech diactiric) and you shouldn't use the WAI while downloading the file.
In some strange cases (unexpected end of script execution etc.) some temporary files are leaved in the
/attachments folder. All such files are deleted on application restart.
XMail's implementation of handling frozen messages is pretty slow. Getting list of frozen messages from server may take dozens of seconds. And that is very, very long time for web application and makes on-line handling of frozen messages amost impossible.
So, I established institution I call FrozCache. There is Windows Script Host script called
frozcache.vbs in the
config folder. This script is designed to be run regularly using task scheduler. Its purpose is to create XML file (called
frozcache.xml), containing all unhandled frozen messages.
That script execution can take as time as needed -- it's asynchronous operation, do not loading the web application. The application works only with the cache file, and this operation is very quick.
The darker side of this solution is, so informations about frozen messages are not always up-to-date. It's important to set the execution time of FrozCache script to be proportional to your needs.
If you have small server and are doing maintenance twice a week, you can execute the script once a day. If you have a high-load server and are checking for frozen messages twice a day, you'll probably consider to have this script executed hourly or maybe even frequently.
Version 2.2.0 and above is not using the
ctrlclnt.exe, but custom script accessing XMail spool folders directly, which is faster and more reliable. According to some users the client hangs up sometimes.
Until version 1.9.0, WAI allows the user MAILPROC.TAB to be edited in some way. Allowing users to directly edit these files may be dangerous -- they may setup some malicious file or script to be executed etc.
So, the process has two levels. At first, the system administrator must establish some templates to be executed. Templates are combination of commands and parameters, some of which can be entered by end users. They can only choose which one from the predefined commands want to be used.
By default, all XMail commands, except of invoking external file, are specified and thus enabled. You may define additional commands (if they would be added to XMail) or specify some trusted scripts to be executed.
But there is a little problem: WAI needs more information about MAILPROC directives, than XMail stored by default. So it uses pack of XML files, stored in the
config\mailproc folder. Currently I don't have energy to describe internal format of these files, so please treat them as undocumented black box. The only thing you really need to know about them is not to modify them in any way -- the WAI will do everything you need.
Warning: WAI expects to be the only application working with user MAILPROC files. So if you would modify these files by hand, all changes may be lost, because WAI would restore the files to last known state.
WAI also allows integration with my other program for XMail, the Simple List Manager (SLIM). You may get SLIM at no cost at my website: http://www.altair2000.net/software/xmail-slim/.
If you want to enable WAI-SLIM cooperation, you must enable it in the
config.xml file by adding the program element to external section. The path attribute must point to SLIM folder, withound the ending slash. Example part of config file may be:
<external> <program name='slim' enabled='yes' path='C:\SYS\Scripts\Xmail\SLIM'/> </external>
If you would set the
True, the WAI would run in Debug Mode.
In normal situations, all XML configuration files (
config.xml and language files) are loaded and parsed once, at application startup. This is done for performance reasons -- parsing of XML file may be time-consuming operation, especially if more users are connected simultaneously.
But this logic means, so application must be restarted every time configuration is changed. That's okay for production state. But if you're testing new language file etc., it's not so practical. Therefore, if application runs in debug mode, XML caching is turned off. That means, so all the files are loaded and parsed every time page is loaded. Fine for debugging, deadly for production.