It is possible to configre IMSpector to automatically “inject” messages into a conversation from within IMSpector. This can currently be used for two purposes:
- To inform the users (both local and remote) that the conversation they are having is being recorded. This might be needed for legal reasons.
- To inform the sender that a file (or message) was blocked. This is useful because the sender will know a block occured, instead of the transfer simply failing.
Because the mechanics of the message generation rely on an SQLite backend, the SQLite client libraries must be present to build this plugin.
This plugin is not built unless you invoke the
make dbresponderplugin.so target. It adds the following options to the config file:
- responder_filename – The filename of the DB to use for storage.
- response_prefix – The prefix to all generated messages, for example Message from IMSpector:
- response_postfix – The postfix to all generated messages.
- notice_days – The time between sending “notices” in days.
- notice_response – The message to send for notices.
- filtered_mins = The time between sending “filtered” in minutes.
- filtered_response – The message to send for filtered.
All customisable messages have nice defaults; a notice message will by default look like this:
Message from IMSpector: -=Your activities are being logged=-
To enable the responses, the minimum options that are needed are the responder_filename, the notice_days (7 is a good start) and the filtered_mins (15 is a good start).
The usefulness of the two timeout intervals is clear; you do not want to remind the users continually that the messages are being logged. The principle reason for the filtered timeout is that some protocols (like MSN) will retry the file sending when they realise it is being blocked. The timeout interval ensures that the sender will not see a response each and every time the client retries the transfer.
Due to various reasons, responses are not supported by the ICQ/AIM protocol plugin. They are also never generated from within group chats.
For the interested people reading, the schema for the SQLite table that powers the respnose mechanism is as follows:
CREATE TABLE IF NOT EXISTS responder (
id integer PRIMARY KEY AUTOINCREMENT,
type integer NOT NULL,
timestamp integer NOT NULL
As with all the SQL tables, the table is created by IMSpector automatically if required.
type is either TYPE_NOTICE (1) or TYPE_FILTERED (2). Timestamp is the time that the message was sent, and is used to determine wether or not to generate another respone. The other fields should be self-explanatatory.