1 TABLE OF CONTENTS
5.1. The Mailbox panel
5.2. The mail list panel
5.3. Common elements
6.1. General Mailbox Properties
6.2. Auto-reply Mailbox Properties
6.3. Mailbox Access Keys
6.4. Mailbox Home Properties
6.5. Mailbox Business Properties
7.1. General Mail List Properties
7.2. Messages properties
7.3. Security properties
7.4. Members properties
7.5. Mail list digests
7.6. Header processing
7.7. How Mail Lists Work
7.8. Mail List Processor Commands
This manual describes the remote Mailbox Management Software for the Windows NT and Windows 95 operating systems which forms part of the Professional Internet Mail Services known as VopMail.
The software exists as two parts, the client software (MailMC) described and the remote mailbox server software (MailMS) which is described elsewhere. The client and server interact using a private protocol described in the the companion MailMS protocol Specification.
The client software is written in Java and runs as a Java Applet hosted by a Web Browser. The client was written using Microsoft Visual J++ 1.1 and uses the features of Java 1.0.
In order to maintain a measure of compatibility with the mailbox configuration program mailcfg.exe the client software makes use of dialog boxes abstracted from that program. While not identical the dialogs should at least seem remarkably familiar.
Return homeThe client software is distributed as a set of java class files, together with a single html script which identifies the java code for the applet. The java applet is included in the Web page using an applet tag. The tag as distributed is as shown below and may need modification. In particular the codebase may need to be adjusted to reflect the location of the java applet class files, as these may reside in a different directory from the html script. Also, the params may need adjustment as described in section 3.
<applet
codebase=.
code=remconsole.class
name=remconsole
width=565
height=410 >
<param name=archive value="remcon.zip">
<param name=title value="">
<param name=server value="">
<param name=user value="">
<param name=password value="">
<param name=BuildVector value="NO">
</applet>
The distribution comprises the following files…
remconsole.html
( class files included in remcon.zip )
app.class
Confirm.class
Conn.class
ConnObservable.class
ControlPanel.class
cryptpwd.class
DialogLayout.class
Displayable.class
doLogin.class
Filter.class
FrameMbox.class
FrameMlst.class
helpFrame.class
HelpSys.class
HelpWindow.class
lex.class
lexList.class
Mailbox.class
Maillist.class
MboxPlugin.class
MboxProtocol.class
MD5.class
Members.class
MessageBox.class
MessageDigest.class
MlstPlugin.class
MsgBox.class
MyCheckboxBinary.class
MyCheckboxGroup.class
Popup.class
Property.class
PropertyList.class
PropertySheet.class
PropMap.class
remconsole.class
remconsoleFrame.class
RFC822Address.class
Tabs.class
REG.class
REG_DWORD.class
REG_MULTI_SZ.class
REG_SZ.class
PASSWORD.class
IDD_CONNECT.class
IDD_CONTROL_MBOX.class
IDD_CONTROL_MLST.class
IDD_EDITDIGEST.class
IDD_EDITLISTMESSAGES.class
IDD_EDITLISTPROPERTIES.class
IDD_EDITLISTSECURITY.class
IDD_EDITMEMBERS.class
IDD_HEADERSCRIPT.class
IDD_MAILBOX_AUTO_REPLY.class
IDD_MAILBOX_GENERAL.class
IDD_PROPSHEET.class
IDD_USERID.class
Only limited configuration of the client software is possible and this is achieved by tailoring the params part of the <applet> tag (see section 2). There are five possible parameters but only four are used when the client runs as an applet. These are
used as a title string within the Logon dialog box. This will default to
`"VopMail Remote configuration"
permits the “Mail Server” field within the Logon dialog box to be preset.
permits the “User name” field within the Logon dialog box to be preset.
permits the “User password” filed within the Logon dialog box to be preset.
By default, the console doesn't retrive the Server's mailboxes information like it did in the previous remconsole versions. This can be change by putting "YES" in the parameter name "BuildVector".
Ex.:PARAM NAME="BuildVector" VALUE="NO" ( Default )
Ex.:PARAM NAME="BuildVector" VALUE="YES"
If the value is "NO" and the Display button is pushed, a message box will appear with the option of retriving the Server's mailboxes informations.
Theses informations are:
This is a one time proccess. When the mailboxes informations are retrived, the mailbox list can be used to display the mailboxes. It can take quite a while if you have a slow connection and/or for Servers with a lot of mailboxes.
The login dialog is used to establish the initial connection to the server hosting the remote Mailbox Management Service (MailMS).
The “Mail server” field identifies the target host. When running as an Applet within a browser window, this field will be immutable and will identify the host which served the Remote Console Applet to the browser.
The “User name” identifies the user and is in the form mailBoxName@domain. The domain portion is optional and if omitted implies the default domain. The “User password” is required for authentication.
The “Logon” button initiates the connection to the remote host and subsequent authentication exchange. Users of the Remote Console are accorded privilege at one of three levels, as follows …
· None - may only manage their own mailbox.
· Domain - may manage any mailbox within their domain, subject to certain constraints.
· Server - may manage any mailbox supported by the server.
Users with no privilege will be presented with a display of mailbox properties presented within the browser window (see section 0) . More privileged users will be presented with a “Control Panel” display (see section 5) giving access to all the mailboxes which they are permitted to manage and allowing new mailboxes to be created .
The “Clear” button clear up the User name and User password field.
The “Help” button pops up a window containing help text for all the components of the dialog box.
Help for individual components may be obtained by selecting the component with the mouse and pressing function key F1.
At login, Privileged users will be presented with a tabbed sheet giving access to the mailboxes and mail lists which they are permitted to manage. The individual sheets for Mailboxes and Mail lists are very similar in style and are described below.
A drop down choice of domains over which the logged in user has privilege. This will either be a single domain or all domains known to the server.
A dropdown choice of mailbox plugins available at the server for supporting different types of mailbox.
Current known types are “Registry mailbox”, “NT mailbox” and “Database mailbox”, some or all of which may be supported. Included in the choice is the “dont care” which implies any type.
An (optionally scrollable) list of mailboxes within the selected domain and of the type corresponding to the selected plugin. Double clicking an item in the list will open it for management, as will selecting from the list and pressing the open button. The list permits only single selection.
This button is used to display the mailboxes manualy in the mailbox list box. Initialy when you log on, the mode is set to manual. By default, the console doesn't retrive the Server's mailboxes information like it did in the previous remconsole versions. This can be change by putting "YES" in the parameter name "BuildVector" in the remconsole.html file included with the console package.
Ex.:PARAM NAME="BuildVector" VALUE="NO" ( Default )
Ex.:PARAM NAME="BuildVector" VALUE="YES"
If the value is "NO" and the Display button is pushed, a message box will appear with the option of retriving the Server's mailboxes informations.
Theses informations are:
This is a one time proccess, when the mailboxes informations are retrived, the mailbox list can be used to display the mailboxes.
The "Auto" and "Manual" checkboxes are used to toggle between the automatic and manual display mode.
Opens the selected mailbox for management. The mailbox properties will be presented in a separate window as a tab sheet with additional buttons (see section 0). While only one mailbox may be selected from the list at any time, it is possible to open several mailboxes simultaneously.
Deletes any mailbox currently selected from the Mailbox list. Confirmation is required. If the mailbox is open for management, the containing window will be dismissed and the mailbox closed. Outstanding changes will be lost.
Pressing the “Create” button causes the text box New mailbox name to appear. This text box is normally hidden
A text box which remains hidden until the “Create” button is pressed. When visible, the name of a new mailbox may be entered. Pressing the “Create” button or the <ENTER> key will cause a new mailbox to be created with the given name, in the selected domain and of the selected type. The mailbox will be opened and presented in a separate window so that the properties may be initialised. Pressing the <ESC> key while the text box is visible will cause it to be hidden.
The “Quick” button is used to open rapidely a mailbox without having to wait for the Server's mailboxes informations to be retrived and without having to wait for the mailbox list to display all the mailboxes. Pressing the “Quick” button causes the text box Quick mailbox name to appear. This text box is normally hidden
A text box which remains hidden until the “Quick” button is pressed. When visible, the name of a mailbox may be entered. Pressing the “Quick” button or the <ENTER> key will cause to open a mailbox with the given name, in the selected domain. The mailbox will be opened and presented in a separate window so that the properties may be initialised. Pressing the <ESC> key while the text box is visible will cause it to be hidden.
Return home
A drop down choice of domains over which the logged in user has privilege. This will either be a single domain or all domains known to the server.
A dropdown choice of mail list plugins available at the server for supporting different types of mail list.
Current known types are “Registry”, “NT” , “Text” and “Database”, some or all of which may be supported. Included in the choice is the “dont care” which implies any type.
An (optionally scrollable) list of mail lists within the selected domain and of the type corresponding to the selected plugin. Double clicking an item in the list will open it for management, as will selecting from the list and pressing the open button. The list permits only single selection.
This button is used to display the mail list manualy in the mail list list box. Initialy when you log on, the mode is set to manual.
The "Auto" and "Manual" checkboxes are used to toggle between the automatic and manual display mode.
Opens the selected mail list for management. The mail list properties will be presented in a separate window as a tab sheet with additional buttons (see section 0). While only one mail list may be selected from the list at any time, it is possible to open several mail lists simultaneously.
Deletes any currently selected mail list. No confirmation is required. If the mail list is open for management, the containing window will be dismissed and the mail list closed. Outstanding changes will be lost.
Pressing the “Create” button causes the text box “New mail list name” to appear. This text box is normally hidden
A text box which remains hidden until the “Create” button is pressed. When visible, the name of a new mail list may be entered. Pressing the “Create” button or the <ENTER> key will cause a new mail list to be created with the given name, in the selected domain and of the selected type. The mail list will be opened and presented in a separate window so that the properties may be initialised. Pressing the <ESC> key while the text box is visible will cause it to be hidden.
The “Quick” button is used to open rapidely a mail list without having to wait for the mail list list to display all the mail list. Pressing the “Quick” button causes the text box Quick mail list name to appear. This text box is normally hidden
A text box which remains hidden until the “Quick” button is pressed. When visible, the name of a mail list may be entered. Pressing the “Quick” button or the <ENTER> key will cause to open a mail list with the given name, in the selected domain. The mail list will be opened and presented in a separate window so that the properties may be initialised. Pressing the <ESC> key while the text box is visible will cause it to be hidden.
The “LogOff” button dismisses the dialog and terminates the Applet.
The "Help" button causes a help window to be displayed; the window will contain help text for each visible dialog box component. The "F1" key displays help for a selected component. Help is available for buttons that dismiss the window if left moused button is depressed meanwhile.
Mailbox properties are presented on three tabbed sheets entitled “General”, “Auto Reply” and “AccessKeys”. The former gives access to general mailbox properties, second provides a means of configuring the mailbox to respond to messages automatically and last provide with the mailbox **Access Keys configuration.
**read-only, see section 6.2. for more information on mailbox Access Keys
Certain properties may only be modified by users with “server” level privilege. For users with lesser privilege, the property values will be displayed but will not be modifiable.
The tabbed sheets are accompanied by a set of six buttons which have the following effects …
The "OK" button causes any outstanding changes to be applied and the window dismissed. Any errors will be highlighted and reported, but the last correct values will be retained. The mailbox will need to be revisited if errors are to be corrected and the changes reapplied.
The "Cancel" button causes the mailbox to be closed and the window dismissed. Outstanding changes are lost. When presented in the browser window, this button will have the legend LogOff and will terminate the Applet.
Apply
The "Apply" button causes any outstanding changes to be applied to the remote the mailbox. Successful changes are highlighted in green. Errors will be reported via error dialogs and the corresponding field highlighted red.
Help
The "Help" button causes a help window to be displayed; the window will contain help text for each visible dialog box component. The "F1" key displays help for a selected component. Help is available for buttons that dismiss the window if left moused button is depressed meanwhile.
ResetErrors
The "ResetErrors" button will cause all error fields (highlighted red) to revert to their former correct value.
UndoAll
The "UndoAll" button undoes all changes applied to the mailbox during this session. Note however that password changes cannot be undone using this mechanism.
This dialog allows you to configure the full name, password and auto-forwarding features for this mailbox.
The full name of the user who owns the mailbox, used when rewriting the To: address.
The password assigned to a mailbox is entered here
If you change the password, you must re-enter it here.
One or more email addresses to which messages for this mailbox will be forwarded. Leave empty to disable forwarding. If more than one address is specified, these should be separated by commas. Note that when a message is auto-forwarded, a full set of Resent-* headers is inserted by the autoforward processor. This complies with upcoming mail standards.
If checked, this will prevent any mail messages from actually being delivered to the mailbox. It is normally set only if Forward to: or the auto reply feature is being used.
This is provided for future remote management extensions, and should be left unchecked in the present release.
This is the maximum size in Kb of the mailbox. If this is exceeded, then new messages will not be delivered to the mailbox, and a non-delivery report will be generated. (Note that only .MSG files are included in the size calculation.) If set to "none", no quota limit will be enforced. If set to "default", the quota limit is inherited from the domain - see Chapter 3 for information on the domain settings.
This is a warning level in Kb. If the size of all the messages in the mailbox exceeds this value, a message warning the user of impending danger is sent. If set to "none", no warning will be sent. If set to "default", the warning level is inherited from the domain - see Chapter 3 for information on the domain settings.
This is the mailbox messages lifetime in days. If the messages in the mailbox are older (days) than this value, the messages will be deleted. If set to "none", the messages have no lifetime limit. If set to "default", the message lifetime is inherited from the domain.
If there is a value set here, The mailbox will be deleted under these conditions:
- If user has never accessed his mailbox and the mailbox creation date is older (in days) than the set value.
- If the last access by the user dates back a number of days exceeding the set value.
If set to "none", the mailbox has no set lifetime. Set to "default", the mailbox lifetime is inherited from the domain.
This is the creation date of the mailbox. For older version of VOPMail (version 1.68 or less) the creation date is taken from the first processing cycle of the mailboxes after installation of the new version of VOPMail with mailbox expiry control.
This is the date of the last time the mailbox was accessed by the user using a Pop3 or Imap4 client.
This enables you to specify an external program that will be executed whenever a message is delivered to a local user’s mailbox directory. It must be a command-line program or batch file (not an interactive program or Windows program). The following substitutions are performed on the command line before it is executed:
|
Special symbols |
Replaced by |
|
%f |
Full file name of the message which was received |
|
%u |
Name of the mailbox |
|
%h |
Mailbox directory |
|
%d |
Domain to which the mailbox belongs |
|
%% |
Single percent character |
The message file (%f) will be located in the mailbox directory, but will not have a .MSG extension. The command may change the contents of, or may even delete, the message file. When the command completes, VopMail will automatically rename the file (if it still exists) to have a .MSG extension, so it will be available for access using POP and IMAP.
You can configure VopMail to reply to messages for particular mailboxes automatically. This can be useful in a variety of circumstances.
For instance, a user who is on holiday may wish to arrange for people who send her mail to receive a message explaining when she will return. Or, as mail administrator, you may want to arrange for mail addressed to a former employee to be replied to with details of the individual's new email address.
To set up the auto-reply feature for a particular mailbox, invoke the Mailbox Properties dialog by double-clicking on the appropriate icon in the Mailboxes page of the configuration console, and select the AutoReply tab.
Check to enable the auto reply feature.
Check to ensure that no sender receives more than one auto reply. When this is checked, SMTPDS will append the email address to which it replies to a file called REPLIED.TXT, located in the mailbox’s incoming mail directory. It will delete this file if the auto reply feature is switched off.
Controls the behaviour of other directives in the auto-reply message. For use in future remote mailbox management extensions. (Disabled except for managers with “Server” wide privilege).
Check to return the original message with an auto reply message
The email address from which an auto reply message will appear to have come.
A list of email addresses (one per line) to which auto reply messages will not be sent. Use Enter to start a new line of text. If a message is received which is addressed to (or CC'd to) one of these addresses, then no automatic reply will be sent. You would typically include addresses of mail lists in here (since automatic replies to mail list messages are antisocial and potentially could cause mail loops). Note that VopMail will never send an auto reply to an address like owner-XXXXXX or like XXXXXX-request, for the same reason.
Contains the text of the auto reply message. Use Enter to start a new line of text.
Mailbox Access Keys are used to control access to certain services and features by particular mailboxes. Default settings can be server-wide (all the mailboxes have a certain default value), which can be overriden by default domain settings. You can also assign specific privileges to individual mailboxes or groups of mailboxes in a domain, thus overriding the server-wide and the domain-wide default settings.
If enabled, this key will grant access to the POP3 client. Users will be able to retrieve their Email normally. Without it, users will get an "Access Denied".
If enabled, this key will grant access to the IMAP4 client service. Users will be able to retrieve their Email normally. Without it, users will get an "Access Denied".
If enabled, this key will allow incoming mail to be delivered to this particular mailbox.
If enabled, the mailbox will allow the authentication ( AUTH ) command from the user client side. The authentication requires a valid login name and password for the user before he can send mail.
If enabled, this key will allow mail to be forward to the specified address in the "Forward mail to:" field. On the other hand, if the FORWARD key is not checked, the mail will be delivered to the current mailbox. If the "Don't deliver to this mailbox" property is enabled while the FORWARD key is not checked and there is a forwarding address, then the message will still get stored in the current mailbox.
If enabled, this key will grant access to the Java console and the Web Mail Manager (WebMailMgr) tools. Note that with the Web Mail Manager, the user will still require the proper mailbox privileges (Domain or Server), even if the EXTERN CONSOLE key is enabled. This is not the case with the Java Console.
If enabled, this key will allow the user to configure the "Forward mail to:" field of his mailbox using the Java console.
If this option is checked, the key that are not controlled by the authentication datasource plugins settings will inherit those set for the domain.
Return home
This dialog allows you to configure the home-related information regarding the user who owns the mailbox.
The street address name of the user who owns the mailbox.
The city name of the user who owns the mailbox.
The state/province name of the user who owns the mailbox.
The zip/postal code of the user who owns the mailbox.
The country name of the user who owns the mailbox.
The phone number of the user who owns the mailbox.
The fax number of the user who owns the mailbox.
The cell phone number of the user who owns the mailbox.
The pager number of the user who owns the mailbox.
Comment from the administrator or user.
The web site address name of the user who owns the mailbox.
Return home
This dialog allows you to configure the Business-related information regarding the user who owns the mailbox.
The company name of the user who owns the mailbox
The job title name of the user who owns the mailbox
The department name of the user who owns the mailbox
The office name of the user who owns the mailbox
The business phone number of the user who owns the mailbox
The business fax number of the user who owns the mailbox
The business cell phone number of the user who owns the mailbox
The business pager number of the user who owns the mailbox
The business street address name of the user who owns the mailbox
The business city name of the user who owns the mailbox
The business state/province name of the user who owns the mailbox
The business zip/postal code of the user who owns the mailbox
The business country name of the user who owns the mailbox
The business web site name of the user who owns the mailbox
Return homeMail list properties are presented on a number of tabbed sheets dependin upon the type of mail list being managed. Four sheets are common to all mail lists and are described first. Sheets particular to specific mail lists are described subsequently .
Certain properties may only be modified by users with “server” level privilege. For users with lesser privilege, the property values will be displayed but will not be modifiable. Properties not relevant to certain types of mail list will be disabled.
The tabbed sheets are accompanied by a set of six buttons which have the following effects …
The "OK" button causes any outstanding changes to be applied and the window dismissed. Any errors will be highlighted and reported, but the last correct values will be retained. The mail list will need to be revisited if errors are to be corrected and the changes reapplied.
The "Cancel" button causes the mail list to be closed and the window dismissed. Outstanding changes are lost. When presented in the browser window, this button will have the legend LogOff and will terminate the Applet.
Apply
The "Apply" button causes any outstanding changes to be applied to the remote the mail list. Successful changes are highlighted in green. Errors will be reported via error dialogs and the corresponding field highlighted red.
Help
The "Help" button causes a help window to be displayed; the window will contain help text for each visible dialog box component. The "F1" key displays help for a selected component. Help is available for buttons that dismiss the window if left moused button is depressed meanwhile.
ResetErrors
The "ResetErrors" button will cause all error fields (highlighted red) to revert to their former correct value.
UndoAll
The "UndoAll" button undoes all changes applied to the mail list during this session. Note however that password changes cannot be undone using this mechanism.
Return home
If a message to an address on the mail list cannot be delivered, this specifies what should be done by the mail software on the computer which discovers that the mail is not deliverable. The options are:
· Return a non-delivery report to the original message sender.
· Send a non-delivery report to a specified email address.
You can specify the mail addresses of the "moderators" of a list. If more than one address is specified, these should be separated by commas. A moderator can control who can post to a list, who can join the list and/or who can leave it.
· Moderator Controls Joining
Any JOIN message to this list will be forwarded to the moderator, who should manually add the user to the list.
· Moderator Controls Leaving
Any LEAVE message to this list will be forwarded to the moderator, who should manually remove the user from the list.
If a list is not moderated, anyone can join or leave the list by sending a message with JOIN or LEAVE in its body to the -request address of the list: see the chapter on mail lists.
You can control who can post messages to the list. The choices are:
· Anyone can post a message to the list.
· Members only may post (default).
· Moderators only may post.
· Members and digesters only may post.
If you check this box, messages from the mail list will have a Reply-to: header field added, such that replies will be sent to the mail list. The exception is that if an incoming message for the mail list already has a Reply-to: header, that header is left untouched and no additional Reply-to: header is added.
If this box is checked, then any Reply-to: header field in an incoming message is replaced such that replies will be sent to the mail list. Force is available only if Reply to list is checked.
Indicates the maximum message size (in bytes) that may be sent to the list. A message that exceeds this size will cause a non-delivery report to be returned to the sender. A value of zero (the default) means that no size limit is applied.
VopMail provides a simple script language for controlling the headers of messages sent to a mail list. Script commands are provided to add, rewrite and remove headers, and to test for the presence of specific headers. See 5.4 for details.
If this checkbox is checked, VopMail will log the commands sent to the list-request address. It will record the log information in a file called CMDLOG.TXT, located in the list-request directory. Note that this file is not cycled - VopMail keeps appending to it. Therefore, you should remember to delete the file every so often, to ensure you don't run out of disk space.
To help list users who may be relatively unfamiliar with list processors, an option to simplify the request processor interface is provided. If you check the "Disallow multiple commands" checkbox, VopMail will process only the first command in messages sent to the list-request address. This means that users do not need to disable their email "signature", and ensures that any accidental coincidence of signature lines with valid list processor commands is harmless.
If you enable multiple commands (by un-checking the box), all lines (up to the end of the message or to a STOP command) are processed.
A message to a mail list (or to a mail list's -request address) may be pre-processed by an external program before being acted on by VopMail. The external program must be a command-line program or a batch file. It must not be an interactive program (i.e. requiring user keyboard input), nor may it be a Windows program. It must be efficient and must terminate reasonably quickly, since VopMail will not process any mail lists or local messages while it is running.
This "external hook" can be used to implement a wide range of features. Some examples are:
· A program which filters out "LEAVE" and "UNSUBSCRIBE" messages sent to the main list address.
· A program which checks a mail message for offensive language.
· A program which provides additional mail list processor commands.
· A program which implements additional mailing-loop prevention techniques.
You can configure the command line which will be executed when a message for a mail list is received, using the "Execute command on list message receipt" field. A separate command for messages received by the mail list request address can be set in the "Execute command on -request message receipt" field. In both fields, you should provide a command which could be executed at the Windows command-line prompt. However, you can use the following special character combinations in the command lines:
|
Special symbols |
Replaced by |
|
%f |
Full file name of the message which was received |
|
%m |
Moderator address of the mail list, or "-" if no moderator |
|
%n |
Name of the mail list |
|
%d |
Domain to which the mail list belongs |
|
%% |
Single percent character |
The message file (%f) will be located in the mail list directory, but will not have a .MSG extension. The external program may change the contents of, or may even delete, the message file. When the external program completes, VopMail will automatically rename the file (if it still exists) to have a .MSG extension, and will process it as normal.
Return home
This page enables you to record a number of standard messages which are automatically sent out when the appropriate event occurs. The following standard message types are available:
Welcome message - sent when a user JOINs a list.
Goodbye message - sent when a user LEAVEs a list.
Help message - sent when a user issues a HELP request in a message.
Message prolog - added to the beginning of every message distributed to list members.
Message postscript - added to the end of every message distributed to list members.
Select the message type from the drop-down list, and type in the message text in the space below the drop-down control.
The message that you type in can contain "directives", which are replaced by other text when the Welcome message is actually sent. Thus for instance the %ADDRESS directive will be replaced by the email address of the person joining or leaving the list. The full list of directives is as follows:
|
Directive |
Replacement text |
|
%ADDRESS |
The email address of the person joining or leaving the list or sending the HELP command |
|
%DATE |
The current date |
|
%TIME |
The current time |
|
%INCLUDE(filename) |
The contents of the filename |
|
%EXECUTE(commandline) |
The output produced by executing the commandline(trusted mail lists only) |
|
%% |
A single percent character |
If you want to put a large amount of text into your message, you should use the %INCLUDE directive, rather than typing text into the configuration console directly. This will save space in the Registry. In fact, you will find that the configuration console will only accept a relatively small amount of text - enough for a short message and a few directives.
The operation of the %INCLUDE directive depends on the Trusted setting. If the mail list is trusted, then the filename should be the full path to a file which is accessible to the mail server. If the mail list is not trusted, only files located in the mail list directory can be included - the filename must not contain the full path.
The %EXECUTE directive only works for trusted mail lists. The commandline can specify any command or batch file.
Note that the Trusted facility is of limited use in this release. It will come into its own in a future release implementing remote management of mail lists, when it can be used to allow non-trusted users to manage their own mail lists.
Some examples may help to make this clear. Suppose a Welcome message for a list abc@mydomain.com (which is not trusted) contains the following text:
Welcome to the abc@mydomain.com mail list!
You have subscribed to the list as %ADDRESS - please remember to unsubscribe using the same address.
%INCLUDE(purpose.txt)
Thank you for joining. Enjoy the list!
When a user joins the list, she will be sent a welcome message containing the above text, with the directives replaced as described above. The file purpose.txt - which presumably contains some information about the purpose of the mail list - must be located on the mail server in the directory ...\lists\~mydomain.com\abc (or, if mydomain.com is the default domain, in directory ...\lists\abc).
Suppose a Goodbye message for the list xyz@otherdomain.com (which we'll assume is trusted) contains:
Thank you for using this list.
%EXECUTE(c:\myutils\goodbye %ADDRESS)
Bye!
When a user leaves this list, she will receive a Goodbye message containing the above text, with the %EXECUTE directive replaced by the output of the program c:\myutils\goodbye. Note that the %ADDRESS is replaced by the user's email address and passed to the program as a command-line argument. (Only %ADDRESS can be used in this way, and only with the %EXECUTE directive.)
Only "console" programs (i.e. programs which you would normally run from the operating system command line) can be used with the %EXECUTE directive. Batch files will work. Interactive programs which prompt for user input, or which have a windowed user interface, will not work.
Suppose a message containing the command HELP is sent to xyz-request@otherdomain.com (as before, we'll assume list xyz is trusted). If the configurable help message for the list contains:
%INCLUDE(c:\special\place\xyzhelp.txt)
The response from the mail list processor will be a message which includes the indicated file. Note that if no help message is configured, a built-in default message will be sent as part of the normal command response (the "journal" message).
Message Prologs and Postscripts
You can also arrange for each message sent to the list to have a prolog or a postscript added. This is very useful (e.g.) for reminding list members how to leave the list. Use the corresponding drop-down items in the Messages page in the mail list configuration dialog to set this up.
You may use the same directives as for Welcome and Goodbye messages, but the %ADDRESS directive will be replaced by the address of the mail list, not the address of an individual recipient. Other remarks in the preceding section also apply to prologs and postscripts.
If a message to a mail list contains a MIME Content-type:header, and the content type is not text/plain, neither the prolog nor the postscript will be added. This is to avoid corrupting data such as image, movie, etc.
Return home
Request processor security
If you are the moderator of a mail list, you may use the REVIEW command in a message to the list-request address. The response will show all the current mail list members.
Because list membership is potentially confidential information, and because it is relatively easy to forge email addresses, the REVIEW command is disabled by default. You have to enable it (for each list in question) using a checkbox in the Security page of the mail list properties dialog.
The operation of the LEAVE and JOIN commands has been changed slightly from VopMail Lerwick. It is no longer possible to send a message to lista-request asking to join or leave listb. (This means that the first parameter of the JOIN and LEAVE commands - the list name - is now redundant, but it is retained for backwards compatibility reasons.)
Following the list name in the JOIN and LEAVE commands, you can now specify a full email address, in any valid RFC822 form. (Previously, the second parameter had to be exactly of the form user@domain.) This "extended" form of the JOIN and LEAVE command is disabled by default, and can be enabled through the Security page in the mail list properties dialog.
Here are some example extended JOIN and LEAVE commands. Note that SUBSCRIBE and UNSUBSCRIBE are still recognised synonyms.
JOIN thelist "John Smith" jsmith@myco.co.uk
LEAVE thelist foo@bar (Foo Bar)
SUBSCRIBE thelist Jane Doe <janed@super-isp.net>
UNSUBSCRIBE thelist peter@my-university.edu
Excluding Addresses From Mail Lists
It is now possible to prevent messages which originate from particular email addresses being sent to a mail list or being processed by the list's -request address. This is done using the two edit fields - "Don't accept messages from:" and "Don't accept commands from:".
The syntax for these fields is:
addressmask, addressmask, addressmask,...
where addressmask can be an email address, possibly containing an asterisk "*" which is treated as a wildcard. You can also have an exclamation mark "!" in front of an addressmask, indicating that matching addresses don't belong in the excluded list. The list is processed from left to right.
Here are some examples:
Don't accept messages from: spammer@spamdomain.com,!knownperson@evildomain,
*@evildomain
means that mail originating from spammer@spamdomain.com and addressed to the mail list will be rejected, as will mail from any user in evildomain (except that mail from knownperson@evildomain would be distributed on the mail list OK). All other messages to the mail list would also be handled as usual.
Don't accept commands from: !me@mydomain,*
means that all mail to the list-request address will be rejected unless it originated from email address me@mydomain.
You should be aware that it is relatively easy for knowledgeable people to "forge" email addresses, so that mail appears to come from a different address. This mechanism will not get round that problem.
This page is present only for Registry, Text, and NT group mail lists. (But note that Text lists can be changed in the Members page only if the configuration console is running on the same machine as the mailserver.) The membership of Text and Database mail lists may be controlled by modifying the text file or database directly. The membership of NT groups is displayed, but cannot be changed by means of this page - NT group membership is controlled through the NT User Manager.
The following commands are provided on the Members page:
Typing an address in the box and clicking on the Add button will add the address to the list.
Selecting one or more addresses and clicking Delete will remove the address from the list.
You can modify the address and/or full name of a list member by clicking on the address. It will appear in the edit field. Make your changes and click the Modify button (the Add button changes its name to Modify).
Mail list members can have a descriptive string associated with them - typically their full name. In the Members page of the mail list property dialog, you can display this information using the "Show full names" checkbox.
Tip: Depending on the type of mail list, the time taken for operations such as sorting, deleting or adding addresses may be significantly greater when full names are displayed. Keep them turned off unless you really need to see them.
The full name is set when a member joins the list using the JOIN command, or it can be set by typing the name and email address into the Members page and clicking the Add button. Any valid RFC822 email address syntax is accepted - see the example list processor commands (above) for examples.
You can Import members from a text file. Each line of the file should be one RFC822 email address. Lines starting with a # are ignored. The Import button brings up a standard “file open” dialog. Similarly, the Export button enables you to output a text file containing the members of the mail list. NB Java applet restrictions normally prevent file i/o. It may be necessary to relax the security restrictions imposed by your broweser before these functions will work.
When you export the mail list members to a text file, the full names will be written using the syntax:
name@domain (full name)
Return homeSuppose you've created a popular mail list called (say) cars, which receives 10 or 20 messages per day. There may be people who would like to subscribe to the list, but don't want to receive every message the moment it is sent. You can set up a "digest" mail list (called in this case cars-digest) which accumulates all the messages received in one day and sends them in a single message.
With VopMail, you can create a digest mail list which is associated with an existing VopMail mail list. To do this, simply select the mail list page in the configuration console, select the domain containing the list you want to create a digest for, and use the normal list-creation mechanism to create a new mail list with the same name as the existing list with -digest appended to it. So, if you wanted to create a digest list for an existing list called myproduct-discuss, you would create a new list called myproduct-discuss-digest. The -digest postfix tells VopMail to treat the list specially.
As far as the mail list subscriber is concerned, the digest list can be subscribed to and unsubscribed from just like other mail lists. For instance, to subscribe, the user would send a JOIN command to myproduct-discuss-digest-request@myco.com. (Note that a digest mail list must be in the same domain as the list which it digests.)
No-one can submit messages to the digest list. Any attempt to do so will result in a non-delivery message being returned. Messages must be submitted to the main list (myproduct-discuss@myco.com). (If you set the "Reply to list" checkbox in the digest mail list property dialog, a Reply-To: header pointing to the main list will be added to digest messages.)
When you double-click on a digest mail list in the configuration console, you will find that there is an extra tab in the property sheet dialog called "Digest":
You can use this page to control the following aspects of the digest list:
· You can control the "digest frequency" - how long the digest accumulates messages for before it sends them out. The default is 1 day.
· You can control whether the digest message will start with a table of contents.
· You can specify the Subject: field of the messages sent out by the digest. To incorporate the date and time from when messages were accumulated, use the percent substitution variables defined below.
|
Variable |
Replacement text |
|
%a |
Weekday name (abbreviated) |
|
%A |
Weekday name (full) |
|
%b |
Month name (abbreviated) |
|
%B |
Month name (full) |
|
%c |
"Short" date and time representation appropriate to the server's locale |
|
%d |
Day of the month as a two-digit number (01-31) |
|
%H |
Hour as a two-digit number (24-hour format: 00-23) |
|
%I |
Hour as a two-digit number (12-hour format: 00-11) |
|
%j |
Day of the year as a three-digit number (001-366) |
|
%m |
Month as a two-digit number (01-12) |
|
%M |
Minute as a two-digit number (00-59) |
|
%p |
AM/PM indicator (appropriate to server's locale) for a 12-hour clock |
|
%S |
Second as a two-digit number (00-59) |
|
%U |
Week of the year as a two-digit number (00-51), counting Sunday as the first day of the week |
|
%w |
Weekday as a single-digit number (0-6), counting Sunday as the first day of the week |
|
%W |
Week of the year as a two-digit number, with Monday as the first day of the week (00-51) |
|
%x |
"Short" date representation appropriate to server's locale |
|
%X |
Time representation appropriate to server's locale |
|
%y |
Year as a two-digit number (00-99) |
|
%Y |
Year as a four-digit number |
|
%z,%Z |
Server's time zone name or abbreviation; empty if the time zone is unknown |
In the General tab, you will find that the fields relating to list moderation have been disabled. This is because list moderation is not necessary for digests.
Also in the General tab, the function of the "maximum message size" field is slightly different for digests. If this is non-zero, then messages will be accumulated until the maximum size is reached, or the normal digest accumulation period is reached, whichever is sooner.
If a mail list has a digest, you can use the "Members and digesters" radio button to specify that members of the list itself and members of the digest list may both submit messages to the list.
VopMail provides a simple script language for controlling the headers of messages sent to a mail list. Script commands are provided to add, rewrite and remove headers, and to test for the presence of specific headers. The script language is not intended to be a comprehensive general-purpose programming language offering full control over all aspects of a message - it is merely a simple means of satisfying the most common requirements for header processing. If a greater degree of control is required, the "message pre-processing" mechanism provided on the General page should be used.
A different header script is used for each mail list. To create a script, double-click on a mail list icon in the Mail Lists page of the configuration console. In the General page of the resulting dialog, click the button labelled "Header processing...". This will display a dialog in which you can enter the script.
A script consists of a series of commands, one per line. The script is executed line-by-line, top to bottom. Script commands are as follows.
Syntax: ADD headertemplate
Example: ADD X-advert: For great widgets, visit
www.widgets.com
Description: Adds the given header text to the end of the headers on the message. Any pre-existing headers of the same type are left unaltered. In the headertemplate, the following combinations have effect: %% is replaced by a single %; %d is replaced by the current date and time.
Syntax: REMOVE header
Example: REMOVE Return-receipt-to:
Description: Removes all headers of the given type from the message. Case is not significant when matching header names. The terminating colon is required.
Syntax: REWRITE header AS headertemplate
Example: REWRITE X-Sender: AS X-OriginalSender:
%v
Description: Replaces the first occurrence of the header with the headertemplate. In the headertemplate, the following combinations have effect: %%is replaced by a single %; %v is replaced by the original value of the header; %d is replaced by the current date and time.
Syntax: IFPRESENT header GOTO label
Example: IFPRESENT Cc: GOTO ccpresent
Description: If the header is present in the message, continue processing the script commands from the label. If the mail list is not "trusted" (see above), only "forward" gotos are possible, to eliminate the possibility of an infinite loop.
Syntax: IFABSENT header GOTO label
Example: IFABSENT Cc: GOTO ccabsent
Description: If the header is not present in the message, continue processing the script commands from the label. If the mail list is not "trusted" (see above), only "forward" gotos are possible, to eliminate the possibility of an infinite loop.
Syntax: ABORT [recipient]
Example: ABORT postmaster@mydomain.com
Description: The message is not sent to the mail list. If the optional argument recipient is present, the message is forwarded to that address.
Syntax: :label
Example: :ccpresent
Description: A colon introduces a label, which can be the target of an IF... GOTO command, as previously described. Label names may not contain space - everything after the space is ignored.
Note that after the mail list header script has been executed, the mail list processor will do its own, built-in header processing. It will rewrite any Sender: headers as Original-sender: and add its own Sender: field. (This is to help prevent mail list loops - your mail list script should never remove any Original-sender: or Sender: headers, otherwise disastrous mailing loops can result.) If the "Reply to list" feature is enabled, the mail list processor will add a Reply-to: field if there isn't one already present.
You should be aware that there are certain headers which can cause "Message delivered" acknowledgement messages to be sent. It is a good idea to remove these headers using a script. As a minimum, therefore, your script should contain:
REMOVE Return-receipt-to:
REMOVE X-Confirm-reading-to:
REMOVE X-pmrqc:
To comply with upcoming mail standards, Resent-* headers are not inserted by the mail list processor.
Return homeWhen SMTPDS receives a message in which the domain name of the recipient address corresponds to one of the virtual domains or the default domains, it assumes the message is for a mailbox or a mail list. It first of all checks to see if a corresponding mail list exists in that domain. If so, the message is temporarily "delivered" to an appropriate subdirectory of the lists directory. If not, it assumes that the message is for a mailbox. (This means that if a mail list has the same name as a mailbox, messages will get sent to the mail list and not to the mailbox.)
SMTPDS will "explode" messages delivered to the mail lists by sending them onward to all list members. It handles messages delivered to -request directories by parsing them for commands and creating a "journal" file which it then returns to the sender.
MlstCmdCommands understood by the mail list processor are as follows.
|
HELP |
Produces summary of commands |
|
JOIN [listname [address]] |
Subscribe to mail list |
|
LEAVE [listname [address]] |
Unsubscribe from mail list |
|
REVIEW |
Show list membership |
|
STOP |
Stop processing commands (e.g. to avoid processing a signature) |
|
SUBSCRIBE [listname [address]] |
Subscribe to mail list |
|
UNSUBSCRIBE [listname [address]] |
Unsubscribe from mail list |