What is Mercury? **************** Mercury is a mail transport system designed to work with Pegasus Mail and compatible mail clients. It is intended as a "drop-in" replacement for the Charon SMTP gateway developed by Brad Clements of Clarkson University, but can do more and doesn't require a dedicated PC. Release 1.11 of Mercury provides a complete SMTP client and server implementation which uses the NetWare TCP/IP stack provided with NetWare 3.11. It also includes a comprehensive mail server which can handle automatic mailing list management, file transmission, user verification and more. Like Pegasus Mail, Mercury is free software - you may install it on as many servers as you wish without obligation or cost. Like Pegasus Mail, manuals are optionally available for Mercury at very reasonable prices, but there is absolutely no requirement that you purchase them. Mercury & Charon **************** Brief summary of the differences between Charon and Mercury. 旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� 旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴커 � Mercury v1.11 � � Charon v4.0a � 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴켸 - Serves one server only - Can serve up to eight servers - Does not require a dedicated PC - Requires a dedicated PC - Supports only SMTP and POP3 - Supports other TCP/IP protocols - Has a comprehensive mail server - Has no mail server - Distribution lists can be managed - No distribution list management remotely, by mail - Automatic subscription and unsubscription from lists - No distribution list management - Distribution lists can be - No distribution list management moderated and restricted - User lookup and validation both - SMTP VRFY command supported by e-mail and SMTP VRFY command. - Disk-based aliasing for almost - Memory-based aliases unlimited numbers of aliases - Automatic reply (like the Unix - No automatic reply function vacation command) with memory - Error messages and notifications - Messages cannot be customized. can be tailored to the site. - BITNET address rewriting - No address rewriting - Mailing lists can be added and - Mailing lists cannot be added updated while the system runs or updated while the system runs - POP3 server supplied - No POP3 server supplied - Broadcast notification messages - Broadcast messages only show include subject and urgency the sender of the message Contacting the Author ********************* Although Mercury is free software, I support it rigorously and welcome reports and comments about it. The best way to contact me is via electronic mail: Internet: david@pmail.gen.nz CompuServe: >internet:david@pmail.gen.nz I'm not currently addressable via MHS, but hope to be in the future. If you wish, you can fax me at (+64) 3 453 6612: although I will try to answer your fax in good faith, the volume of paperwork I have to manage means it may be 10-14 days before you get a reply. I can be phoned at (+64) 3 453 6880, but please remember that New Zealand is GMT+1200... I am generally pretty grumpy about being woken at 4am by ANYONE! Because of the volume of information I have to deal with, faxing me, or sending me paper mail will generally not elicit a fast response - I apologise in advance for this, but there's only so much one person can do. My postal address is: Pegasus Mail, c/o David Harris, P.O. Box 5451, Dunedin, New Zealand. Important Information ********************* Notes about this release:  All sites using Mercury should add the following line to the Server's STARTUP.NCF file: SET MAXIMUM PHYSICAL RECEIVE PACKET SIZE=2048 Note that you can set a higher value if you wish, but you should not set it lower than 2048.  Sites which use the SWITCH keyword in MERCURY.INI should change the setting from the old default (110) to either 1 or 2 for Mercury 1.1. The old value results in almost no load on the server but very slow transmission of large messages. The new value causes some increase on load for large messages but results in nearly 5 times faster processing.  Novell made changes to some versions of CLIB which can seriously affect Mercury's operation. Mercury 1.11 includes logic to work around these problems, but if you find mail messages appearing in your mail queue with odd job numbers, please read the file IMPORTAN.T! provided in this archive.  A very rare, intermittent problem can occur which can send MercuryS into a never-ending loop receiving the same line over and over again. The DISCARD keyword in the [MercuryS] section of MERCURY.INI is designed to safeguard against this problem and should not be removed, although you can set it to a higher number than the default (30000) if you wish.  Mercury 1.1 can only service the file server on which it runs.  Mercury 1.1 does not support the SMTP EXPN command.  Mercury 1.11 does not work with NetWare 4.0 in queue mode: in order to use Mercury 1.11 with NetWare 4.0, you must use the spool directory option. Mercury currently only operates under NetWare 4.0 servers in Bindery Emulation mode - support for NDS should be ready for the next release. What's new in 1.1 ***************** Mercury 1.1 includes the following new capabilities:  Mail to NetWare groups. You must enable group mail on a group-by-group basis in Mercury.INI. See the section on MERCURY.INI under Installing Mercury for more information.  Restrictions on connections. It is now possible to force MercuryS to restrict connections to explicit machines. For more information, see the section on MERCURY.INI under Installing Mercury.  Much better timeout handling. You can control the timeout value for MercuryS, MercuryC and MercuryP using TIMEOUT entries in each one's section in Mercury.INI  A new, improved console screen.  Support for the SMTP VRFY command. This cost 5K of code but I've had sufficient requests that it seemed important.  Limited ESMTP support. Mercury now recognizes the RFC1425 EHLO command and supports the 8BITMIME keyword defined in RFC1426. Support for the SIZE keyword (RFC1427) is coming shortly.  Limited address rewriting capability. It's now possible to have Mercury rewrite the domain portion of most outgoing addresses in the message envelope (although not in the message itself). You might use this to force addresses in the form "user@host" to be rewritten as "user@host.domain".  Considerably improved error handling and reporting.  Support for the SMTP HELP command. The Help command displays the name of the MAISER account as part of its output.  The Mercury NLMs should now load even if MERCURY.INI is not flagged SHAREABLE.  Distribution list container files no longer need to exist before use - Mercury will now create them as necessary.  Messages with From: fields which extend across multiple lines are now handled correctly.  Mercury can now be told not to validate the From: field of incoming mail messages via the "gullible" keyword in the [Mercury] section of Mercury.INI.  MercuryS and MercuryC can now announce themselves during the connection phase using a name different from "Myname", via the "helo" keyword in their respective INI sections.  Messages which include quoted quotes in the Qtext part of an address are now handled correctly (for example an address like: "David \"Shotgun\" Harris" ).  Messages with attachments are now passed through correctly by Mercury when sent to distribution lists.  Messages where the RCPT TO: field is given in source-routed form are now parsed correctly. Note that sending source-routed addresses in the RCPT TO: stage of the SMTP transaction is now considered illegal on the Internet - I have supported it under duress. What's new in 1.11 ****************** Mercury 1.11 is a consolidation release which fixes several small problems in the 1.1 release - there is no appreciable new functionality. The following changes have been made:  MercuryS should receive messages anything up to twenty times faster than in 1.1 and problems with Mercury tying up 100% of the server's resources should no longer occur.  Mercury can now be told to use a file server directory for queuing mail instead of a NetWare Queue; in order to use this functionality you MUST be running PMail for DOS 3.0, WinPMail v1.02 or later or PMail/Mac v2.1 or later. The spool directory can be on any volume. Spool directory support is enabled using the FILE_API keyword in MERCURY.INI. In order to run Mercury on NetWare 4.0x, you MUST use the spooler interface.  When sending mail to a mailing list the To: address is now handled more tidily when the list is burst.  Two new list definition keywords are available: - Restricted: if set to 'Y', only list members and moderators may mail to the list. - Errors_to: attempts to set an address to which errors and problems associated with list mail delivery should be sent.  If a distribution list is NOT set to force replies to go to the list, then reply-to fields in incoming messages will now be preserved when the list is burst.  Broadcast message notification of new mail can now be turned off globally using the BROADCAST keyword in the [Mercury] section of MERCURY.INI ("Broadcast: 0" will disable notification).  Mercury now incorporates considerable loop detection logic - it should not be possible for it to get into an infinite processing loop with a message. Mercury achieves this by counting the number of RFC821 "received" headers in the message and discarding it once a certain number is reached. The default limit is 30 "received" headers, but this can be changed using a new MAXHOP keyword in the [Mercury] section of MERCURY.INI. A side effect of this addition is that Mercury itself now generates more "Received" headers than it used to which increases the size of messages slightly.  MercuryC is now much more tolerant of connection failures and TCP/IP errors when despatching mail. When MercuryC gets a hard error it now requeues the job correctly and will continue to do so at five minute intervals indefinitely until the message is deleted by an operator or the user, or is successfully delivered. SMTP 500-series errors still result in immediate failure by Mercury.  MercuryP has had the revised console added and now tracks the messages you have read via POP3; messages which are read during a session will not be offered to you in subsequent sessions even if they are not deleted. This behaviour is configurable using the new MARK_READ keyword in the [MercuryP] section of MERCURY.INI. If 1 (the default) then MercuryP WILL remember the messages you have read; if 0, it will NOT remember and will present you with all new mail in your mailbox each time a connection is established.  The problem in previous versions of Mercury which required the use of JOB statements in MERCURY.INI has been worked around and should no longer be a problem. JOB statements in MERCURY.INI are now ignored, although the same facility for remapping form numbers can still be achieved using FORM statements instead. Note that the format of the FORM statement is different from the JOB statement, although it should never be an issue in any case since the problem should no longer occur. Upgrading Mercury ***************** If you are already running a previous version of Mercury, you can upgrade your installation either by running MINSTALL, or by copying *.NLM from the distribution file into SYS:SYSTEM. Note that there are many new features and capabilities in this release of Mercury, many of which will only be enabled when certain changes are made to MERCURY.INI. You should read this guide carefully for information on the changes you might need to make. ******************* Installing Mercury ******************* System Requirements ******************* Mercury requires NetWare 3.11 with the NetWare TCP/IP transport module loaded and correctly installed. It is not fussy about the particular details of the TCP/IP settings, provided the transport is running. In normal use Mercury will take approximately 70KB of server RAM and 2 BSD sockets, and should not significantly slow the per- formance of the server. Mercury runs under NetWare 4.0 in Bindery Emulation mode only, and only using the spool directory interface. (I'm still working towards native NetWare 4.0 NDS support). Queue or Spooler? ***************** Mercury can interface with Pegasus Mail (and compatible mailers) in one of two ways: 1: Via a NetWare queue: This has the advantage that familiar NetWare tools such as PCONSOLE can be used to manage the mail queue; as well, it is very difficult to forge mail when using the queue interface. 2: Via a spool directory (a directory on the file server in which all users with access to SMTP services have [C] rights). The spool directory has the advantage that it places little extra load on the server, can be located on any volume, and has no limits on the maximum number of simultaneous jobs in the queue. It is also an easier interface to write to for compatible mailers and gateways, requiring no NetWare API calls or awareness. The choice of which interface you use is up to you, but there are some specific caveats: * If you are installing Mercury on a NetWare 4.0 server, then you can ONLY use the spool directory interface. * To use the spool directory interface, you must be using PMail for DOS v3.0 or later, WinPMail v1.02 or later, or PMail/Mac v2.1 or later. Earlier versions cannot access the spool directory interface. Spooler Interface ***************** To install Mercury to use a Spool Directory interface on your server, follow these steps: 1: Create a directory somewhere on your server into which mail files are to be spooled. 2: Create a NetWare group which contains those people who are to have access to SMTP mail services (you can use the group EVERYONE if all users are to have access) and grant the group [C] rights to the directory. 3: Edit MERCURY.INI and add the following line in the [GENERAL] section of the file: FILE_API : 1 4: Alter the MAILQUEUE and SMTPQUEUE entries in the [GENERAL] section of MERCURY.INI so that they contain the path to the directory you created in step 1, in NETWARE format (for example, SYS:MERCURY/SMTPQUEUE). 5: DO NOT RUN ADDQ! It is NOT necessary if you are using the spooler interface, and will not run under NetWare 4.0 in any case. Queue Interface *************** Mercury services mail from a NetWare Queue, which must exist the first time you load Mercury - it will not create it. If you are currently using the Charon Gateway and Pegasus Mail, then Mercury can use your existing Charon queue - PROVIDED that Charon is not using it as well. If you intend to keep Charon running for a time while testing Mercury, then you must run Mercury on a separate queue. To create the mail queue for Mercury, simply use the NetWare PCONSOLE command as you would normally to create a print queue. Once you have created the queue, run ADDQ.EXE from the Mercury archive - the syntax is "ADDQ ". Addq simply makes user SUPERVISOR a valid server for the queue, which allows Mercury to service the queue from connection 0. Quick install ************* The sample MERCURY.INI supplied with the distribution archive turns on almost every Mercury feature, and is suitable for most sites with only a couple of changes. If you want to get Mercury up and running as quickly as possible, use the MINSTALL batch file to install the system, then alter the following entries in SYS:SYSTEM/MERCURY.INI In the [General] Section: Myname - Set this to the canonical name of your server. Timezone - Set this to your time zone Mailqueue, - Set this to the name of the queue you create SMTPqueue for Pegasus Mail. If you are replacing a Charon server you will probably enter "MAILQUEUE" for both entries. If you are using Mercury's spooler interface, set the value to your spool path. In the [Mercury] Section: Postmaster - Set this to the NetWare UIC of the user who is to be postmaster on this server. In the [MercuryC] Section: Host - Set this to the IP address of the machine which will relay outgoing mail for you. Note - it MUST be an IP address, not a name. In the [Domains] Section: Place an entry in the form : , where is the NetWare name of this file server, while is the Internet domain name which other sites will use as an address for the server. You should also add an entry which says : (ie, both sides of the ':' are the same) to allow local delivery. That should be all it takes! If you have entered the correct values, Mercury should load and run without further problems. Using MINSTALL.BAT ****************** The Mercury archive includes a simple batch file called MINSTALL which will do the file-shuffling part of the Mercury installation for you. To run MINSTALL, make sure you are in the directory in which you unpacked MERC100.EXE, then type MINSTALL. *** NOTE: MINSTALL will attempt to map drive K: to SYS:SYSTEM; *** edit the batch file if you want it to use another drive letter. MINSTALL moves the NLMs into SYS:SYSTEM, creates SYS:SYSTEM\MERCURY and copies the Mercury support files there, and flags MERCURY.INI as shareable. Once MINSTALL has completed, you should modify MERCURY.INI as described in this guide. Manual Installation ******************* Mercury can be installed from DOS by running the MINSTALL batch file from the directory in which you unpacked MERC100.ZIP, or by hand using the following instructions: 1: Copy the 3 Mercury NLMs (MERCURY, MERCURYC and MERCURYS) and the sample MERCURY.INI file into SYS:SYSTEM. 1a: If you intend to use Mercury's POP3 support, copy MERCURYP.NLM into SYS:SYSTEM as well. 2: Create SYS:SYSTEM/MERCURY, and copy the remaining files from the Mercury archive into this directory. 3: If you are using Mercury's default NetWare Queue Interface, run the ADDQ.EXE program supplied in the archive. This program simply makes the user SUPERVISOR a valid server for the queue you specify. This is necessary for Mercury to be able to run. If you are using Mercury's Spooler interface you should NOT run ADDQ. 4: Make any changes necessary to MERCURY.INI (see next topic). 5: From the NetWare console, issue the commands: LOAD MERCURY LOAD MERCURYS LOAD MERCURYC (You will probably also want to add these commands to the end of your AUTOEXEC.NCF file). 6: Flag SYS:SYSTEM/MERCURY.INI Shareable (this is important). Mercury Console *************** Each Mercury module opens a console screen where it logs progress messages and general operation information. You can cycle between the various console screens on the server by pressing if you are at the console, or the Grey <+> key if you are using RCONSOLE. Each console screen has a header section which identifies the module and provides some ongoing statistics. The statistics provided in each header are as follows: Mercury.NLM Name: The name of the host (MYNAME in Mercury.INI) Q: The name of the mail queue Mercury is serving Domains: The number of entries in the [Domains] section, which equates to the number of possible addresses Mercury is currently servicing. J: The number of mail jobs Mercury has processed since it was loaded. E: The number of errors which have occurred since Mercury was loaded. MercuryC.NLM Name: The name of the host (MYNAME in Mercury.INI) Q: The name of the mail queue MercuryC is serving Host: The IP address of the machine which MercuryC is asking to relay mail. J: The number of mail jobs MercuryC has processed since it was loaded. E: The number of errors which have occurred since Mercury was loaded. MercuryS.NLM Name: The name of the host (MYNAME in Mercury.INI) Q: The name of the mail queue MercuryS is serving J: The number of mail jobs MercuryS has processed since it was loaded. X: The number of RFC1425 ESMTP connections which MercuryS has accepted since it was loaded. R: The number of times MercuryS has refused to accept a connection since it was loaded. ***************** MERCURY.INI ***************** About MERCURY.INI ***************** MERCURY.INI is a text file located in SYS:SYSTEM which is read by all the Mercury NLMs when they load. It MUST be flagged Shareable or else you will get unsynchronized load errors when you load the NLMs from AUTOEXEC.CNF. MERCURY.INI can be edited with any text editor, and is not held open while Mercury is running - it is only interrogated at the time the system loads. The [General] Section ********************* The [General] section contains settings common to all modules; Myname: Domain name for your server; Mercury can derive the server's IP number from the OS, but it cannot derive the name. Enter here the name which your Name Server returns as the IN A entry for this file server. Unlike Charon, Mercury ONLY requires MX entries if you wish to provide aliased names for your servers. File_API: If this keyword is present and has a non-zero parameter, then Mercury will use a spool directory interface instead of a NetWare queue for mail management. If omitted (the default) Mercury will expect to use a NetWare queue. Mailqueue: The name of the queue into which outgoing mail should be placed. If you have previously installed the Charon gateway, you can use the Queue you created for Charon. This is the queue into which Pegasus Mail and compatible clients will place mail for processing. If you are using Mercury's Spooler interface, then give the path to your spool directory in this field. Timezone: The timezone string the Mercury modules should add to Date: fields in messages. This string must not be longer than 10 characters. Example: "timezone: GMT+11" yields the date "Mon, 29 Mar 93 23:10:33 GMT+11" SMTPQueue: The name of the queue in which the SMTP client should look for jobs to send off-server. This queue can be the same as the mailqueue, and usually should be except on exceptionally busy servers. If you are using Mercury's Spooler interface, then give the path to your spool directory in this field. The [Mercury] Section ********************* The [Mercury] section contains settings for MERCURY.NLM, the central delivery engine. MERCURY.NLM is responsible for examining mail in the mailqueue and deciding whether it is to be delivered locally (which it will then do), or else passed to the SMTP client to be sent off-server. It also contains a simple Mail Server, and the aliasing and synonym mechanisms. Failfile, Confirmfile: Template files, the first for Delivery failure notifications, the second for Delivery confirmations. Sample versions of these files are provided and can be used without changes. The template file format is described later. Aliasfile: Points to a file of aliases. Aliases are equations for full addresses, and are created and maintained with MALIAS.EXE. The alias file may be updated while Mercury is running - for an example of the format of the source file used for aliasing, see the file ALIAS.SRC. Syn_file: Points to a synonym file. Synonyms allow a user to have a From: address in messages which is different from their NetWare UIC (which is the normal mail address when using Mercury and PMail). Synonyms might allow the user "DAVID", for instance, to have the address "D.Harris". Synonyms are created and maintained using the PMail PMGRANT program, and the synonym database is created using CH_SYN.EXE. The difference between a Synonym and an Alias is that a Synonym is bi-directional - that is, PMail uses it in outgoing messages and Mercury recognizes it in incoming messages. Aliases usually only work in one direction. A user may have only ONE synonym, and need not have any if you choose not to use them. Listfile: The name of the "List of lists" - a file defining distribution lists managed by Mercury. For more information, see the section below entitled "Distribution lists". Logfile: The name of a file where Mercury should record mail traffic. The sender, addressee, time, date and size of the messages are stored. If you do not specify a logfile field, no logging will be done. Logwidth: Optional integer specifying the maximum width of address fields in the log file. The default value is 30 characters for each field. BitnetHost: Mercury can perform limited, simple-minded address rewriting of BITNET addresses, which many smart mailers cannot mail directly. If you specify a value here (in the sample file, for instance, it is "cunyvm.cuny.edu"), then addresses in the form "USER@HOST.BITNET" will be sent as "USER%HOST.BITNET@cunyvm.cuny.edu". Poll: How often (in seconds) Mercury should check for new jobs in the mailqueue. Once every ten seconds is a good setting. Broadcast: An integer value (1 or 0, default 1). By default, Mercury sends a NetWare broadcast message to users if they are logged in when new mail arrives. Individual users can disable this feature using CASTOFF or PMail's extended preferences options, but you can also disable it for the entire server by including this optional keyword and setting it to 0. Gullible: An integer value (1 or 0) which determines whether or not Mercury should check that a message has a valid From: address before delivering it. If Mercury is to operate in Gullible mode (1), then it will accept any message and attempt to deliver it. Scratch: Where Mercury can create temporary files. Usually the location in which you store your template files is a good choice. You may want to consider using the NetWare FLAGDIR command to set this directory's auto-purge flag. Returnlines: How many lines Mercury should write from the original message when it encounters the ~G substitution in template files. Job1, Job2, Job3: These allow you to change the form numbers (job types) which Mercury uses to create and scan for jobs. You should use these fields only to solve NetWare API problems - they are not provided for any other purpose. Job1 specifies the job number Mercury should use when scanning the mail queue for jobs it should service. Job2 specifies the job number Mercury should use when creating messages to be sent off-server by the SMTP client module; and Job3 specifies the job number Mercury should assign to jobs for itself. As noted above, these values are NOT required parameters, and should only be used on instruction from the author. For more information on these fields, see the file IMPORTAN.T!! in this archive. Switch: Is an optional integer telling Mercury how many times to yield the processor per operation during intensive I/O. The default is 0, which may be too low for very busy servers. Setting SWITCH: 1 will usually result in a marked improvement in server performance. Mercury should almost never need this entry, although MERCURYC may need it on occasion. Postmaster: NetWare UIC of the user on this server who is to receive messages delivered to Postmaster. This cannot be an alias or synonym. ** Note: PostMaster is a MANDATORY setting. Mercury will NOT run ** correctly if it is omitted. The [Domains] Section ********************* The [Domains] section is used to bind a particular domain address to a particular NetWare server. You must supply at least one domain for Mercury to function. The format of the Domains section is: NetWare_server_name : domain_name As an example, if you have a NetWare server for which the NetWare name is THALIA, and the Internet name is URANIA.PMAIL.GEN.NZ, then your [Domains] entry will look like this: THALIA : urania.pmail.gen.nz To allow local delivery, you should always add an entry which equates your server name to your server name - like this: THALIA : THALIA Mercury will NOT add this entry automatically in case you have unusual duplicate naming schemes at your site. You can repeat a server name with several different domain addresses, but you may not repeat a domain name for several different servers; so - THALIA : urania.pmail.gen.nz THALIA : pmail.gen.nz is a legal [Domains] list, but - THALIA : urania.pmail.gen.nz URANIA : urania.pmail.gen.nz is not. Domain Literals *************** There is a seldom-used address format called a domain-literal form, which consists of the IP address of the target machine in square brackets (example user@[192.156.225.2]). Although the domain-literal form is discouraged in standards documents, some older mail systems use it from time to time. Mercury will accept domain literal references, but will not do so automatically - to allow domain literal forms, you must add an equation for them to your domains section, like any other domain reference. The form of the entry should be as follows: SERVER : [www.xxx.yyy.zzz] Example - your server's IP address is 192.156.225.16: you would enter this in your [Domains] section - THALIA : [192.156.225.16] The [Rewrite] Section ********************* Mercury can perform limited rewriting on addresses in the envelope portion of outgoing mail; typically this will be used to ensure that addresses in the message envelope go out as FQDN forms, although it can also be used to perform a certain amount of crude domain rewriting as well. Entries in the [Rewrite] section consist of a domain portion to match and the substitution to perform. For example, the [Rewrite] entry: myserver : myserver.pmail.gen.nz tells Mercury to rewrite any addresses where the domain portion consists of "myserver" to a fully-qualified form. The match (left- hand side) is not case-sensitive, but otherwise must match exactly. You can define a special "default rewrite" by specifying "*" as the match: this rewrite ADDS the substitution to any domain which does not contain a period in its domain portion. So the rewrite entry: * : pmail.gen.nz Would cause the address "david@parnassus" to be rewritten as "david@parnassus.pmail.gen.nz". Restrictions: because the address rewriting facility is really just a string match and replace, there are certain restrictions on its use and capabilities:  Source-routed address forms cannot be rewritten.  Bang-style (uucp) addresses (anything containing a '!') will not be rewritten.  The rewrite occurs ONLY in the ENVELOPE to the message, not in the actual message headers themselves. The [MercuryC] Section ********************** The MercuryC section contains settings for the Mercury SMTP client - the module which transfers mail from your server to the outside world using the SMTP protocol. Scratch, failfile, returnlines, poll: Are all the same as in the [Mercury] entry, and may have the same values, or may differ. The Poll parameter in particular will usually be longer than the Poll time in the [Mercury] section. Helo: Allows you to define a name different from "Myname" which MercuryC should use when connecting to the smart mailer. Most sites will not need to use this parameter. Host: The Internet address of the host which MercuryC will ask to relay mail. Like the Charon SMTP gateway, MercuryC does not actually attempt to deliver mail itself - it passes it to a "smart" mailer which will do so. Typically the smart mailer is a UNIX machine. The Host address must be specified in dotted numeric format - for example "192.156.225.2", because NetWare's TCP/IP does not implement a proper name resolver. Switch: Is an optional integer telling MercuryC how many times to yield the processor per operation during intensive I/O. The default is 0, which may be too low for very busy servers. Setting SWITCH: 1 will usually result in a marked improvement in server performance on busy servers. Timeout: Specifies the number of seconds MercuryC should wait without seeing data on the socket before timing out. The default value is 300 seconds. Job1, Job2: These allow you to change the form numbers (job types) which MercuryC uses to create and scan for jobs. You should use these fields only to solve NetWare API problems - they are not provided for any other purpose. Job1 specifies the job number MercuryC should use when creating messages for local delivery (such as failure notifications). Job2 specifies the job number MercuryC should use when scanning the mail queue for jobs it should service. These fields are NOT normally required, and should be used only on instruction from the author. The [MercuryS] Section ********************** Seven keywords exist for MercuryS, the SMTP listener. Debug: If non-zero, then MercuryS will display more information about incoming connections on its screen. Helo: Allows you to define a name different from "Myname" which MercuryS should use when accepting connections from other systems. Most sites will not need to use this parameter. Switch: Is an optional integer telling MercuryS how many times to yield the processor per operation during intensive I/O. The default is 0, which may be too low for very busy servers. Setting SWITCH: 1 will usually result in a marked improvement in server performance. Refuse: The parameter is an Internet address in dotted format. This keyword defines an address or range of addresses from which MercuryS should NOT accept connections. (See next section) Allow: The opposite of Refuse - specifies an address or range of addresses from which MercuryS SHOULD accept connections. Timeout: Specifies the number of seconds MercuryS should wait without seeing data on the socket before timing out. The default value is 300 seconds. Discard: Specifies the maximum number of lines a message may have before MercuryS will refuse to accept it. This keyword is provided to work around a rare intermittent problem in MercuryS.NLM and hence should not be removed, although you may set its value to a larger or smaller number than the default (30000). When MercuryS detects that the line limit has been breached it will perform an emergency close on the connection and discard all data received up to that point. Job1: Allows you to specify the job number MercuryS should use when creating jobs in the mailqueue. The job number should equate to the value which the Mercury core module expects to service. This field is only provided to resolve possible conflicts with the NetWare API set, and is not usually required. You should add it only on instructions from the author. MercuryS does no validation on incoming addresses - it simply places them as jobs in the Mailqueue, and allows MERCURY.NLM to decide what to do with them. MercuryS DOES support the SMTP VRFY command though. Restricting Connections *********************** It is possible to tell MercuryS to refuse or accept connections only from specific addresses or ranges of addresses. By default, MercuryS will accept connections from anywhere. To create an access control list for MercuryS, use REFUSE and ALLOW keywords in the MercuryS section of Mercury.INI. You can use REFUSE and ALLOW as often as you wish in the section. A '0' anywhere in the address you provide to either keyword is taken as a wildcard - so the address 139.80.0.0 is taken to mean "Any address in the class B domain 139.80.x.x". Note that the order in which REFUSE and ALLOW entries appear in the [MercuryS] section is CRITICAL. MercuryS evaluates them in order when deciding when assessing a connection, and stops evaluating on the first match. Example: Permit only 139.80.128.2 in the 139.80.x.x domain to connect to Mercury [MercuryS] Allow : 139.80.128.2 Refuse : 139.80.0.0 Example: Allow only connections from 139.80.x.64 [MercuryS] Allow : 139.80.0.64 Refuse : 0.0.0.0 Note that there is an implicit rule "Allow 0.0.0.0" at the end of the list, so if an address drops through the bottom of the restriction list (that is, matches no entry), Mercury will allow it to connect. The [Groups] Section ******************** Mercury can deliver mail to NetWare user groups on your server. Because this is a potential security risk (imagine someone sending malicious mail to group EVERYONE), you have to enable mail to groups on a group by group basis. To allow mail to a group, create a [Groups] section in your .INI file, using the following syntax: address : group_name Address is the address which Mercury will associate with the group. It can be the same as the NetWare groupname if you wish. Group_name is the actual NetWare name of the group. Example: to enable group mailing to group MAILUSERS using the address "everybody", enter: [Groups] everybody : MAILUSERS You may have as many entries in the GROUPS section as you wish. The [Maiser] Section ******************** As mentioned above, MERCURY.NLM incorporates a simple mail server, which can respond autonomously to a limited number of commands in response to a mail message. The [Maiser] section controls the Mail Server. If it is absent, the Mail Server functions will be disabled. Maiser: The name of the address which MERCURY.NLM should interpret as being the mail server. This should NOT be a valid account on your server - it is a fictitious address to which mail is never directly delivered: setting MAISER to point to a real account effectively prevents the real account from ever receiving mail. The value in the sample INI file is MAISER, and I STRONGLY urge you to use this name unless you have extremely solid reasons for altering it. Helpfile: The name of a file which the mailserver should send back in reply to the message body "HELP". A sample file is provided which you may use if you wish. This file is NOT a template file. Lookupfile: The name of a template file which the mailserver should use to form replies in response to the LOOKUP command. This IS a template file, and should contain the substitution "~R" at the point where the mail server should enumerate the successful matches. If you do not supply a value for Lookupfile, the Maiser's lookup function will be disabled, and anyone requesting a lookup will receive a failure notification to this effect. Logfile: The name of a file where MAISER should record traffic. The sender, time, date and commands issued are recorded. If you do not specify a logfile field, no MAISER logging will be done. *** DO NOT set the Maiser log file to the same file as the *** Mercury log file. Send_dir: The name of a directory containing files which users may ask the maiser to send using the SEND command. Files in this directory must be ASCII text files, so if you want to make binaries available you will have to uuencode or binhex them yourself. If you choose to make files available by mail, you should place a file called INDEX.TXT in this directory: this is the file Maiser will send in response to the INDEX command, and usually contains descriptions of the available files (although it can contain anything). The send command is quite secure - it will ONLY accept filenames in the specified directory. If you wish to disable the send command, then make sure that there is no Send_dir field in your MAISER section. ***************** Mercury Features ***************** Automatic Replies ***************** Mercury can manage auto replies for Internet mail, much the same way the UNIX "Vacation" program does. To enable auto-reply for a user, create a file in his/her SYS:MAIL subdirectory called AREPLY.PM, containing the message to be returned to the sender. Mercury will look for this when delivering mail to the account, and will return its contents immediately the message is delivered locally. To avoid the possibility of mail storms (which can happen when two accounts start auto-replying to each other, or when an autoreply is sent to a list server), Mercury remembers every address from which a message has been successfully delivered for the account in the last 48 hours; if more than one message comes in from the same address in any 48 hour period, Mercury will generate only one auto-reply. The auto-reply memory is stored in a file called AREPLY.KFL in the user's SYS:MAIL directory. PMail extended features *********************** Mercury recognizes and honours all PMail extended features applicable to it. To enable autoforwarding by Mercury for an account, an address should be placed in the "Internet AF" field in PMail's extended features (just like Charon). Mercury recognizes and honours Charon Synonyms. Template files ************** Mercury is capable of generating a certain number of messages autonomously: good examples are Delivery Confirmations and Delivery Failure messages. Rather than use hard-wired messages (like sendmail's awful delivery confirmations), Mercury allows you to create Template Files - pre-written models which it will use to write the messages, filling in the blanks as necessary. Template files are complete messages, including headers, and must be formatted as such. Template headers must conform to RFC-822, but the message body of a template can contain anything you wish. You can tell Mercury to substitute certain values in a template by placing a tilde followed by a code at the point in the message where you want the substitution to occur. The following Template substitutions are supported by Mercury: ~D - Replaced with the current time and date in full RFC-822 date format, without the "Date:" keyword. ~T - Replaced by the "to" address of the message, without the "To:" keyword. ~S - Replaced with the "Subject:" field for the message, without "Subject" keyword. ~R - Indicates the point in the template at which Mercury should print its result file. For delivery failure, the result file contains the errors; for user lookups, it contains the result of the search; for delivery confirmation, it contains the addresses to which the message was successfully delivered. Its value for other templates is undefined. ~M - Indicates that Mercury should dump the entire original message into the outgoing message. ~G - Indicates that Mercury should dump lines from the original message, up to the value defined in "returnlines" in MERCURY.INI, into the outgoing message. ~N - Replaced with the domain name of the server. ~~ - Replaced with a single tilde. Other substitutions may be added in future versions. The Mercury distribution includes the following sample template files which you can use unmodified at your site if you wish: FAILURE.MER (Delivery failure notification), CONFIRM.MER (Delivery success notification) and MAISER.LKP (template for a successful MAISER lookup operation). Distribution lists - Terms ************************** Mercury can expand distribution lists automatically, and includes facilities for list moderation and automatic subscription. 1: Terms List of lists: The master file describing all the lists managed by Mercury on this host. Specified in MERCURY.INI. Public list: A public list is one to which anyone may subscribe by sending a subscribe message to the maiser. If a list is not public, then only the list moderators may add to it by e-mail. A non-public list with no moderator can only be added to by manually editing the list file. Moderator: The address of a person who has control over the list. If a list is "moderated" (see below) then mail can only be sent to the list by a moderator. If a list is "non-public" (see above), then only a list moderator may add subscribers to it. A list may have a practically unlimited number of moderators. A moderator need not be a subscriber to the list. Restricted list: If a list is restricted, only its members and moderators may send mail to it. Moderated list: A moderated list can only be posted to from addresses specified as moderators of the list. The intention is that mail is sent to a moderator who then decides whether it should be posted to the list. Moderated lists may or may not be public as well. Distribution lists - The List of lists ************************************** The "List of Lists" is pointed to by the "listfile" entry in MERCURY.INI. It is a simple text file containing information about the lists available on this host, and may be updated at any time. List names start at the extreme left margin, and all subsequent lines describing the list must be indented at least one space. Description lines for a list are read until a blank line or another list name is encountered. The name of a list may not have a domain attached - lists can be reached on any domain served by the host. Example: test-l file: sys:system/mercury/testl.lst title: Test List welcome: sys:system/mercury/testlw.txt moderator: david@urania.pmail.gen.nz moderator: dlh@urania.pmail.gen.nz This entry defines a list called "test-l", with two moderators, a title, and a greeting file for new subscribers. The following qualifiers are supported by Mercury: FILE: A required qualifier - the name of the file which actually contains the current membership of the list. The file need not exist before use - Mercury will create it automatically if necessary. TITLE: Optional. Text added to the "to" field of messages sent out to list subscribers. WELCOME: Optional. The name of a file to send to new subscribers to this list. The file is plain text, not a template file. MODERATOR: The minimal-form address of a list manager. List managers may add users to the list and may be the only people able to mail to the list. You may have as many MODERATOR entries as you wish, one address per entry. The FIRST moderator entry has special significance - it is the "primary" moderator, the one to whom MAISER will refer users. PUBLIC: Optional, Y or N (Default Y). Indicates whether the list is public or not. Non-public lists will not accept SUBSCRIBE requests. RESTRICTED: Optional, Y or N (Default N). If 'Y', then only list members and moderators may send mail to the list. MODERATED: Optional, Y or N (Default N). If 'Y', then only the list moderators may post to the list. LIMIT: Optional, number (default 0). The maximum number of subscribers the list may have. If 0 (the default) then there is no limit. ERRORS_TO: Optional, no default. Supplies an address to which errors generated by list mail should be sent. Note that this merely tells Mercury to generate an Errors-to: header in the message, which is quasi-standard. There is NO standard way of controlling or directing list errors, but this is as good as there is. Whether it has any effect depends on the receiving mailer. REPLY_TO_LIST: Optional, Y or N (Default N). If 'Y', then Maiser will add a "Reply-to" field in messages to the list which will direct replies to the list rather than the sender. ENUMERATE: Optional, Y or N (default N). If 'Y', then Maiser will accept ENUMERATE/REVIEW requests for the list. Distribution lists - Using lists ******************************** Users can subscribe to Public lists by sending a message to the MAISER account on the server with the body set to SUBSCRIBE . Users can unsubscribe from a list using the command UNSUBSCRIBE . If a list is not public, then moderators can add users to it by mailing to MAISER with the message body set to ADD , and may remove users by setting the message body to REMOVE . The command ENUMERATE will return the current list membership. If a moderator has been specified for the list, then ENUMERATE will only work for moderators, even if the list is not flagged as moderated. Summary: SUBSCRIBE Add the sender's address to the list also SUB UNSUBSCRIBE Remove the sender from the list also UNSUB , or SIGNOFF ADD
Add a user to a list (moderators only) REMOVE
Remove a user from a list (only list moderators may use this command) ENUMERATE Return the list membership also REVIEW LIST Returns the lists available at this host Aliasing ******** Mercury supports disk-based aliasing for addresses. Aliases may be created, added or updated while Mercury is running. To use aliases, create a text file containing the alias equations then compile it using MALIAS.EXE. The resulting file should be placed in the location specified in MERCURY.INI. For an example of the format MALIAS expects, examine the file ALIAS.SRC provided in the distribution archive. POP3 Server *********** Mercury includes a mail forwarding server which conforms to RFC-1225 (POP3, or Post Office Protocol v3). The POP3 NLM is called MERCURYP.NLM, and can be loaded with or without the other Mercury components. MercuryP is a full implementation of all commands in RFC1225 (although RPOP is treated no differently from USER), and any legal POP3 client should be able to access it on port 110. MercuryP has one limitation at this stage - it does NOT deal correctly with locally-delivered messages from PMail which have attachments: only the message is sent - the attachments are left behind, and are not deleted correctly if the message is deleted. This problem does NOT apply to PMail attachments which are received via Mercury or Charon, and will be fixed in a future release. Other Maiser commands ********************* Mercury's mail server also recognizes the following commands: HELP Returns the helpfile defined in the MAISER section of MERCURY.INI to the sender. BOUNCE Returns the message to the sender, headers intact. LOOKUP Searches the NetWare bindery for user names matching , which can contain '*' and '?' wildcards. If you wish to disable lookup, make sure that there is no LOOKUPFILE entry in the MAISER section of your MERCURY.INI. VERIFY
Returns a message indicating whether the address specified is valid on the local host. INDEX Sends the file INDEX.TXT from your "files to send" directory (identical to the command SEND INDEX.TXT). SEND Sends the named text file from your "files to send" directory. If you do NOT want this facility to be available on your system, make sure that there is no SEND_DIR entry in the MAISER section of MERCURY.INI. The send command is VERY secure - you cannot specify paths of any kind in , and Mercury will ONLY look in the directory specified in SEND_DIR. Troubleshooting *************** Here are a few common problems and solutions when using Mercury. I can't send to or receive mail from Mercury This and numerous variants of it make up over 95% of the problems reported with Mercury. In general, this is a configuration problem, either in NetWare TCP/IP or in your smart mailer. Things to check include:  Make sure you are actually loading TCPIP.NLM on the server  Make sure your netmask is correct - it must agree with every other host on your network.  Make sure you have the correct address specified in [MercuryC] for your smart relay host.  If you have a name server, make sure it is advertising the correct IP address for your server.  If you have used Charon in the past, make sure you don't have invalid MX entries lying around on the network. I can receive mail on Mercury but when I try to send I get a message like "Error connecting to xx.xx.xx.xx; error 0 connecting to server". This situation usually indicates a TCP/IP routing error of some kind on your network. Make sure that you have specified a GATE= parameter on the BIND line in your AUTOEXEC.NCF which ties IP to an Ethernet card. If you are using a Domain Name Server at your site, make sure that it knows about your server, and make sure that any routers which might need to know about your server have been configured correctly. Mercury is properly installed but mail isn't being processed Run PCONSOLE and examine the queue. All jobs in the queue should have either form number 101 or form number 110. If there are any jobs in the queue with other job numbers, then you have a version of CLIB.NLM in which Novell generously changed their APIs without telling anyone. Read the file IMPORTAN.T!! in the Mercury distribution archive for details on how to fix this problem. NOTE: the PCONSOLE queue list only displays the first four digits of the form number - to see the real form number, you must actually select a job and press to see its full details. MercuryS appears to timeout after the DATA statement from a host which is trying to send it mail. This usually means one of two things:  The client is sending packets which are too large for your Server to accept. Try adding the command "set maximum physical receive packet size = 2048" in your AUTOEXEC.NCF before you load your LAN driver.  Your LAN driver or card cannot correctly handle IP packets. Some older versions of the WD drivers exhibit this problem. Upgrading to the most recent version of the driver (SMCPLUS for the WD family of cards) usually fixes it. Every time I receive a mail message I get a "message loop" - the message just bounces around between the smart host and Mercury until eventually one of them discards it. You almost certainly have an incomplete or inaccurate [Domains] section in MERCURY.INI. You must list in your [Domains] section every possible Internet name your file server could have. Mercury uses the [Domains] section to determine whether mail is local or remote: if you omit a possible name for your server then Mercury will not know that the mail is local and will refer it back to the smart host, which in turn will send it back to Mercury... and so on.