Mercury FAQ

Your question has probably already been answered. Look here for some great answers!

0
-1
closed
PiS posted Aug 21 '11 at 2:19 pm

Mercury is a server program that interacts via connections, and has it's own storage. Therefore Mercury needs to be allowed to write to disk and be allowed to communicate over tcp-ports.

This means practically that you should open your firewall and the OS-firewall to allow traffic to and from Mercury, and,

allow Mercury to write to the Disk. On Windows 7+ machines, the path %ProgramFiles% is meant to hold only readable program files, and not changeable data. The best advice is to install Mercury outside %ProgramFiles%, and allow the user account Full access to the directory/ies where Mercury and it's data resides.


0
-1

4. Paste the following command on a line after '.' and before 'exit 0':

iptables -t nat -A PREROUTING -p tcp --dport 25 -j REDIRECT --to 2525

This works for the other standard ports as well, here's what I've entered in the /etc/rc.local and I've made connections to the POP3 and IMAP4 host via the normal ports as well.

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

iptables -t nat -A PREROUTING -p tcp --dport   25 -j REDIRECT --to 8025
iptables -t nat -A PREROUTING -p tcp --dport 143 -j REDIRECT --to 8143
iptables -t nat -A PREROUTING -p tcp --dport 110 -j REDIRECT --to 8110

exit 0

The only thing that does not work in Mercury/32 with Wine is the SSL/TLS and you can use STunnel for Linux to allow the MercuryC SMTP client to connect  to a relay host and have the MercuryS, MercuryP and MercuryI servers support SSL connections.  See

 

0
-1

> Can mercury be configured to retrieve email ad then spool it to another mail server ?

Yes.

> This way the mail can be processed through mercury's content, transaction and spam filtering before being passed
> to another server.

Yes.

>
> Is that possible ?

You are talking about Mercury/32 as a MX host. Mercury/32 currently does not provide MX services.  David's looking into this for a future enhancement but until that happens here's 3 possible work arounds.   

These are NOT a true MX host function since it does not queue and wait for the receiving system to be online to send the mail.  That said, WSMTPEx will keep retrying if the connection to the server and port cannot be made.  I have not tested how long it will continue retrying.   

1.  First of all is the simplest, you simply re-write the domain in the mercury.ini [Rewrite] section.

[Rewrite]
none-tstephenson.com: [192.168.1.3]

I really was surprised when this one worked since it truly simple and has been there
all along.  You learn something new every day.  The brackets are required when using
an IP address.  This forwards all mail for anyuser@none-stephenson.com to
anyuser@[192.168.1.3] using the normal Mercury/32 send process via port 25. 
Works quite well when using MercuryE, cannot work when using MercuryC unless the
IP address is a routable IP address.  You must re-boot Mercury/32 for each change
since this is only read at startup.  

2.  The second one is the daemon MercFwd and it essentially does the same thing as
the rewrite but this can be done dynamically by changing the domains section.  The
[Domains] entry of  

daemon:c:\mercury\mercfwd.dll;[192.168.1.3]: none-tstephenson.com

does essentially the same thing as the rewrite above.  Again it uses Mercury to deliver
the mail via port 25 and so you cannot use this with MercuryC when using non-
routable IP addresses.  

3.  The third one is the program WSMTPEx.exe (SMTPEX.NLM for Netware)  and this a a
separate program that takes mail for a email account and forwards it to any port and
any hostname/IP address.  I use this with my domains to forward the mail to a Linux
system (must use high ports as non-root) and to a second instance of Mercury/32
running on my system (can't share port 25)  Here's a sample of the ini file I use for
forwarding all mail to Mercury/32 running on Ubuntu v8.10 and Wine.  

 #  You can rename this tool, but name of following section must remain [WSMTPEx]
[WSMTPEx]
Version=0.10
#  TCP port, on which SMTP server listens
Port=8025
#  Number of seconds to delay between searches for emails
LoopDelay=30
#  Folder, under which is most of user's mailboxes
UserFolder=
Domains=1
# Users mail address domain part
Domain1=linux-tstephenson.com
LogName=c:\Mercury\WSMTPEx.log
SMTPServer=192.168.1.4
MailBoxes=1
Badmails=c:\pmail\mail\BadMail

[linux-tstephenson.com]
# When user name start with "DM:", WSMTPEx will try to find SMTP envelope address in mail file
Mb1addr=dm:ubunto
Mb1dir=c:\pmail\mail\ubunto


This takes all the mail in the domain account "UBUNTO"  and sends it to port 8025 on
192.168.1.4 to be received by MercuryS.  The directory BADMAIL I have specified
must exist.  You can run multiple instances of this tool and and it can be run as a
service.  If run as a service and running multiple instances the name of the program
should be changed.  I use WSE-UBUNTO to rename the program and ini file for this
one.  

Many thanks to Petr Jaklin for the development of these tools.  You can get these
tools at the community download areas or directly from Petr Jaklin's site
 


0
-1
closed
Phil posted Oct 21 '08 at 10:06 am

[quote user="arnaudherve"]It would perhaps be interesting to move the messages on Mercury to the Mercury category.
[/quote]

You're perfectly right. Done.

0
-1
closed
Phil posted Oct 21 '08 at 10:06 am

[quote user="arnaudherve"]It would perhaps be interesting to move the messages on Mercury to the Mercury category.
[/quote]

You're perfectly right. Done.

0
-1

We have a gaming clan that has members worldwide. We want to have the

ability to email freely between all members registered with the server

from anywhere in the world but only from their clan email address.

Another idea.  Put all of the valid addresses in a distribution list and then use a scan list filter to only accept mail from the email addresses on the list. The filter would look like the following rule.  In this case is the address is not in the dist. list friends'pml is gets moved to a spam user mail directory.  I use this with another rule to block mail to a mailing list.

If not ListScan "@c:\\pmail\\mail\\thomas\\friends.pml" Move "@s:\\pmail\\mail\\spamscan"

 

0
-1

If you are using Mercury/32 with personal names that use high bit characters you should replace the ~p with the ~o in the user defined gateway.  This will allow your highbit characters to be used properly.  Here's what the UDG should look like when viewed with pconfig.exe run from the WinPMail program directory.

 

 Gateway name :  MERCURY
            *New mail path :
    Is ? a program to run? :  N
     *New mail search mask :
       *Outgoing mail path :  C:\MERWIN\QUEUE
    *Run for outgoing mail :
          *Filename format :  ~d~d.101
   Run to validate address :
     *Reply address format : ["~o" <~L~L~8@merwin.tstephenson.co?
   Accepts SMTP addresses? :  Y
   Simple message headers? :  'Glue' headers
     UUEncode attachments? :  Y
           Burst messages? :  N    Gateway processes BCC? : N
       Strip gateway name? :  Y
   Force all mail through? :  N

  Format Pegasus Mail should use to compose the 'From' field for
  the message. ~8 or ~n indicate where the name should be placed.
0
-1
closed
Rolf Lindby posted Aug 3 '07 at 10:49 pm

No complications whatsoever, just make sure the path to the Mercury folder is the same. Remember to copy empty folders in the Mercury folder as well. And keep a backup copy of the original folder just in case.

/Rolf 

0
-1

For those that need a wrapper that works with Netware as well I recommend NT Wrapper.  It allows you to run as as a specific user and still maintain the GUI interface.

 

The NT Wrapper allows standard Win32 applications or scripts to be run as a Windows NT/2000/XP/2003 Service. 

Features:
    ·    Easy configuration thru a GUI and simple INI files. 
    ·    Prioritization of sub-processes. 
    ·    Custom environments. 
    ·    CPU binding 
    ·    Redirecting of Stdout/Stderr to file 
    ·    Logging to the event log and to disk. 
    ·    The capability to run multiple applications in a single NT Wrapper service instance. 
    ·    Monitoring of a service in the sys-tray. 

http://www.duodata.de/ntwrapper/



 

0
-1
closed
Pmail.Com posted Apr 22 '07 at 4:16 pm

Q: I need a way to easily filter spam at the mail host rather than only at the mail client. Does Mercury/32 provide such a feature?

A: Yes, Mercury/32 includes a Content Control feature that can help you easily filter out spam and other undesirable content (e.g. viruses, urban legends, and virus warning hoaxes). This support document will help you better understand how Mercury/32's content control feature works and how to properly use it.

Looking at the Mercury/32 message processing flowchart , you'll notice that Content Control filtering takes place early on in the message processing at step 5, before Global Filtering takes place. Only Mercury/32 Deamons and pre-filter Policies get processed beforehand.

When the Content Control step happens, Mercury/32 processes each Content Control Set in order from top to bottom. You can have many different sets defined for different purposes. For instance, you may have a top-level set as a virus and hoax filter while having a second set that checks for spam. The top set would simply search for exact matches of known subject and body content used by popular viruses, such as the Klez variants, as well as well-known virus hoaxes, such as the jdbgmgr.exe hoax. The second set would search for words or phrases or e-mail addresses known to be indicative of spam.

When each content control set gets processed in turn, the following events happen:

  1. If a content control set is marked as disabled, then it is bypassed and processing continues with the next content control set.

  2. If the current control control set is not disabled, then the message is checked to determine whether or not it is applicable to this content control set's message origination setting. A content control set can be configured to only apply against mail originating locally, non-locally, or both. For purposes of defining local origination, Mercury checks whether or not the sender's address can be considered local (meaning that it has a local mailbox associated with it on the Mercury system or is defined within a Mercury alias or synonym). If the message is not considered applicable for this content control set, the next content control set takes over.

    Note: At the time of this writing, the latest release of Mercury/32 (currently v4.01) incorrectly considers all incoming mail via the MercuryD POP3 client to be originating from a local address. Thus if you obtain your incoming e-mail via MercuryD's POP3 client module, then you will need to configure your content control sets to be applicable to all incoming mail, not only from non-local addresses.

  3. The content control set's whitelist (if specified) is searched first to see if the sender of this message is in the whitelist. If specified, be sure to type in a full directory path and filename for the whitelist text file.

    The whitelist can contain wildcards (e.g. *@mydomain.com, *@*.mydomain.com, *support*@*). If the sender matches a whitelist entry, no further content control processing is performed against this message for this specific content control set (the next content control set becomes active at this point).

  4. If no match was found above, then the content control set's blacklist (if specified) is searched to see if the sender of this message is on the blacklist. If specified, be sure to type in a full directory path and filename for the blacklist text file. The blacklist can contain wildcards, just like with the whitelist above. If the sender matches a blacklist entry, the message automatically gets treated as undesirable (the filter rules are skipped) and any specified action for this content control set is performed before the next content control set becomes active.

  5. If no match was found above, then the content control set's filters (if specified) are processed to see if the message triggers any of the filters. If specified, be sure to type in a full directory path and filename for the content filter text file. If any filters are triggered, the message's weight score is increased by each matching filter's weight parameter. e.g. 10 + 30 + 40 = 80

    The filter rules are very finniky and you can end up disabling a lot of rules in the set if you have a syntax error in a filter statement higher up in the filter rule file. You can use the Check Syntax button within Mercury/32's built-in rule editor dialog to quickly have Mercury/32 scan the filter rule file for any errors.

    Note: At the time of this writing, the built-in rule editor dialog in the latest release of Mercury/32 (currently v4.01) has a 32KB text buffer limit. However you can use an external pure-text editor, like WordPad, if your filter rule file gets too big, but you will no longer be able to use the Check Syntax function.

    Note: Verions of Mercury/32 older than v4.0 do not support decoding of BASE64-encoded content within e-mail messages. Thus, in older versions of Mercury/32, it is possible for obvious spam messages to sneak past the message body filters if the spam message is BASE64-encoded. Additionally, a filter rule that is searching for a single small word may find a hit within a large harmless BASE64-encoded attachment to a valid e-mail message and thus cause a false positive against the message. Adding a leading and/or trailing space to such small words in your filters will help reduce the chance of such false positives occurring.

  6. Once the filter rules have finished processing against the message, the message's resulting weight score is compared to the specified weight threshold defined in this content control set. If the message's weighted score is greater or equal to the set's defined weight threshold, then any specified action for this content control set is performed before the next content control set becomes active.

Tip: By using different weights in your filters effectively, you can reduce the number of false positives produced by your filters. For instance, some words or phrases by themselves do not necessarily indicate spam unless other similar words or phrases are also found in the message. Additionally, you can use negative weights in filter rules to lower a message's weight score when certain words or phrases are found that most likely indicate a valid message and not a spam message. For example, you can use this technique to allow humor messages to score lower due to a negative weight by looking for "humor" or "joke" or a similar word within the subject header or in one of the standard sender fields (From, Reply-to, and Return-path).

The action specified in the content control set is performed against the message only if either the message's sender was found in the blacklist or the message's weighted score is greater than or equal to the content control set's weight threshold. Otherwise, processing continues with the next content control set. A content control set can have only one action from the following list:

  • Take no further action: Nothing is done to the message, but the corresponding System Statistics counters are incremented.

  • Add an identifying header: Adds the specified header and value to the message (e.g. X-SPAM: Yes); if no header is specified, Mercury will add an "X-UC-Weight" header to the message, and will assign the weight of the message as the value of this added header. We recommend that each content control set use a different header so that you know which content control set(s) triggered an action for a message. You can use filters in Mercury/32 (or Regular Expression filters in Pegasus Mail) to search for these special headers and process the messages accordingly. Using a combination of identifying headers and filter rules gives you the most control over the possible actions that can be applied to a message, even allowing you to perform multiple actions against the message.

  • Copy the message to another address: A copy of the message is sent to the e-mail address you specify in the parameter field. The original message will not be altered in any way.

  • Forward the message then delete it: The message is redirected to the e-mail address you specify in the parameter field. This action will cause all content control processing to terminate for the original message because it will be deleted from the message queue.

  • Move the message to a directory as a file: The message is saved as a file (using a random filename with no filename extension) in the directory specified in the parameter field. This action will cause all content control processing to terminate for the message because it will be deleted from the message queue.

  • Delete the message: This action will delete the message permanently and all content control processing for this message will be terminated.

The following is an addendum to and re-emphasizes some major points from the Help file in Mercury/32 concerning the syntax and usage of content control rules:

  • Regular Expressions (Regex) are only available in rules that use the "MATCHES" clause, not the "CONTAINS" clause. All RegEx metacharacters will be treated as regular text characters within a rule that uses the "CONTAINS" clause.

  • Rules using the "MATCHES" clause must match the whole text of the subject, header, sender, or body of the message (depending upon what is actually being checked); otherwise, use "*" characters before and after the string being searched in order to search for only a subset of the whole text. e.g. "*day job*"

    If this search text should only be found at the front of the text, leave off the "*" at the front of the search text. e.g. "day job*"

    If this search text should only be found at the end of the text, leave off the "*" at the end of the search text. e.g. "*day job"

    If this search text should be an exact match of the subject text or whatever, leave off the "*" at both ends of the search text. e.g. "day job"

  • Since "*" and "?" are all treated as special regex metacharacters in rules containing a "MATCHES" clause, you must preface these characters with a "/" character if you want them to be treated literally. e.g.

    "COPY /*.AB/? TESTDIR"

  • Since "/" and "[" are treated as a special regex qualifier character (as shown above) in rules containing a "MATCHES" clause, you must enclose the "/" and "[" in square brackets if you want the "/" and "[" characters to be treated literally. e.g. "his[/]her" "[[]surrounded by brackets]"

    This requirement also applies to "+". e.g. "A[+]B=C"

  • Since the double-quote character (") encloses the text strings used in all content control rules, you must preface a double-quote character with a "\" character if you want the double-quote character it to be treated as part of text string. e.g. "charset=\"\""

  • Since "\" is treated as a special text string processing character (as shown above) in all content control rules, you must use two "\" characters if you want one "\" character to be treated literally. e.g. "c:\\test.txt"

Note: Proper handling of the /w and /W regex metacharacters has been fixed as of Mercury/32 v4.01a.

0
-1

.QCL files are no longer used in Mercury/32 v4.5; once you have upgraded to v4.5, you can delete any of these files that might have been left lying around by older versions of the program.

.QJD files are Job-wide Diagnostic files - they are created to contain diagnostic or error report information applying to the job as a whole, as opposed to information specific to a particular address element in the job. Unlike .QIF files, which will almost always have a filename part different from the job they belong to, .QJD files will always have the same base filename part as the .QCF and .QDF files.

Peter's comment about deleting files needs some amplification: you must always shut down Mercury before attempting to delete any files in the queue directory - but in fact you should avoid doing this altogether unless you are very sure of what you are doing. The Mercury queue was never intended to be manually manipulated, and if you get it wrong, the consequences can be quite unappealing.

-- David --

0
-1
closed
PiS posted Apr 22 '07 at 3:02 pm

Mercury/32 uses a control file to store the process information, needed for each message, the codes used in the files are as follows.

NOTE: The use of the various codes can change without further notification in future releases of Mercury/32!

Code Description
ST: Start time

Example: R 020528160331 12 000032 000030 000001

The R says this is a retry, the next string is a date, time line,tells you when it will next be processed. 2005 March 7 09:58:32 . The next one is the number of tries, 3. The structure is critical, the data can be all zeros.
FR: From field

Example: user@jassing.com

The used from address in simplest format.
DF: Data file

Example: MO00018F.QDF

Name of the file, the basename is the same for the QCF and QDF files.
FL: Flags field

Example FL: 2

This field contains bit values that store information about the state of the job. The following values are defined:
#define JF_NOFILTER     0x100    //  Do not apply filtering to this job

#define JF_EXPIRE 0x200 // Expire the message when writing it

#define JF_SCANNED 0x400 // The message has been externally scanned

#define JF_LOCAL 0x800 // The message was submitted locally

#define JF_VERPJOB 0x1000 // Process this message as a VERP probe

As a general rule, *only* Mercury should modify this field.
OS: Original Submission

Example: 020528125939

The time the message originally entered the queue.
BA: Begin address

Example: user@jassing.com

Indicates the beginning of a single delivery element for the message. A "delivery element" is a single address to which the message is addressed, and it has a number of subsidiary fields - in particular an

  • ES: "Element status" field

  • RI: "Resolver information" field

  • DI: "Diagnostic information" field.

  • The element always ends with an EA: ("End address") marker.
0
-1
closed
PiS posted Apr 4 '07 at 8:57 pm

IS WORKING
Windows Mobile Version 5.1.195 (Build 14874.2.0.0), tested by Peter Strömblad
Windows Mobile Version 5.1.195 (Build 14932.2.2.2), tested by Rory Kallfelz

IS NOT WORKING
Windows Mobile Version 5.1.1702 (Build 14366.1.0.1), tested by Peter Strömblad

0
-1
closed
Slab posted May 8 '07 at 10:59 pm

[quote user="Peter Strömblad"]

Some probe mailers only send headers, or when communication is interrupted you can end up with an e-mail without a body content. Many client software have BIG trouble getting these e-mails over POP3. If you add a global filtering rule to RULES.MER with the following line:

If not expression body matches "*" Delete ""

These e-mails are dumped before getting into the user-mailbox.

[/quote]

 

I've gotten the same thing happen when my virus scanner kills part of the message.

0
-1
closed
PiS posted Feb 15 '07 at 10:39 pm

Problem: I am using the MercuryE end-to-end delivery module but it's failing to deliver to some addresses I know are good.

Solution: If your workstation connects to the Internet via a dialup connection, or if it uses DHCP to determine its IP address, you will have to configure MercuryE explicitly to use a specific name server via its configuration dialog. MercuryE sometimes cannot determine a name server automatically on dialup or DHCP-configured systems.


Problem: Mercury/32 does not see my Novell NetWare system

Solution: To run in NetWare mode, Mercury/32 must be run on a Windows 95 or 98 workstation equipped with Novell's Client32, or a Windows NT workstation equipped with Novell's Workstation Manager; the default Microsoft Client for NetWare Networks does not support 32-bit NetWare-aware applications. Novell's clients are available from the Novell web site,


Problem: In Bindery mode, Mercury/32 does not log in to my NetWare server to deliver incoming mail

Solution: Mercury/32 requires a username and password to be able to connect to the target NetWare server. NetWare demands that this information be supplied in uppercase characters; if you entered this information in lowercase or mixed-case characters in Mercury/32, it will be unable to connect to your NetWare server to deliver mail.


Problem: I have Client32 installed, and have specified the NetWare login name and password in uppercase letters in the Mercury/32 configuration, but mail still does not get to my NetWare Bindery Mode system

Solution: Check the Local Domains you have defined in the Mercury core module configuration dialog - when running in NetWare Bindery mode, Mercury/32 uses the left-hand side of the equations to specify which NetWare file servers correspond to the domains given on the right-hand side. This is a new feature in version 2.0 - previously, the left-hand side of each equation was ignored.


Problem: I get errors like "503 Need recipient" from Mercury

Solution: This error (and any error like it starting with a 3-digit number) is actually being issued by the mail host which Mercury uses to relay mail, not by Mercury. It usually indicates an addressing problem in your message, but you should refer it to the system manager on the mail host.


Problem: I can send mail out, but no-one can send mail to me

Solution: This usually means that your server's Internet name is not being advertised on the Internet. You must have an entry in a DNS (Domain Name Server) system somewhere which allows other sites to work out your server's address from its name. Contact your IP network manager or Internet Service Provider for details.


Problem: Mail goes out with the wrong "From" address even though I've changed the "Internet name for this system" value in the core module configuration dialog..

Solution: You also need to change the Pegasus Mail configuration information to reflect the new Internet name. Use the Pegasus Mail PCONFIG or NCONFIG program to do this.


Problem: 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.

Solution: You almost certainly have an incomplete or inaccurate Local Domains page your Core Module configuration dialog. You must list in your [Domains] section every possible Internet name by which your file server could be addressed. 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.


Problem: Error messages from mailing lists are returned to the sender of the original message.

Solution: This is an area where usage is vague on the Internet and it is difficult to provide a general solution. Try adding an "Errors-to:" field to the definition for the list in Mercury's "List of Lists". This will force error notifications to go to the specified address in many cases, but unfortunately not all Internet mail systems follow the rules.

0
-1
closed
PiS posted Feb 15 '07 at 10:38 pm

Problem:  I'm using Mercury under NDS on a NetWare 4.11 server. Sometimes it starts rejecting mail as "user unknown" even though the user exists and the address is valid.

Solution:  As far as we can determine, this is the result of a problem in NDS itself. If you are using a version of Mercury earlier than v1.44, upgrade to v1.44: it contains a number of workarounds to deal with this weakness in NDS. If the problem persists after you have upgraded, add the following statement to the [MercuryS] and [Mercury] sections of your MERCURY.INI file:

nds_reauthenticate: 1

This statement tells Mercury that it should perform regular NDS login and logout operations. In short, it appears that on widely-spread NDS trees, NDS sometimes gets confused about the status of Mercury's NDS login and "deauthenticates" it without telling Mercury. This effectively logs Mercury out of NDS, resulting in the "user unknown" errors. The problem appears to be exacerbated if you have NDS servers that crash or go offline frequently. Having Mercury login and logout regularly appears to work around this problem in NDS, at the risk of Mercury possibly not being able to secure a login to the server.

NOTE: You should not apply the "nds_reauthenticate" option as a matter of course - it should only be applied if it fixes this specific problem for you.


Problem:  I recently upgraded to NetWare's SP7 or SP8 Patch Pack on my NetWare 4.11 server and now I'm getting regular "CPU Hog" abends in the MercNDSP POP3 Server.

Answer:  We are currently trying to work out what is causing this problem - it appears to be a thread safety issue within NDS, but we have not been able to tie it down. We are currently doing all we can to find a solution to this problem, but have no workaround or solution at this stage.


Problem:  When I unload Mercury, NetWare issues an error about unreleased resources. What do I do about this?

Solution:  Nothing. The warning is completely benign and can be ignored. NetWare recovers the unreleased resources as a matter of course and it is quite normal for a program to have a few data structures left over at exit. In actual fact, in NDS mode, the unreleased resources are allocated by NetWare itself, not by Mercury. This warning is only significant if the numbers it reports are very large (for instance, more than 75,000 small memory allocations, or more than 20 BSD Sockets).


Problem:  When I load PMUSER.NLM on my NetWare 4.11 server it abends.
Problem:  When I unload PMUSER.NLM on my NetWare 4.x or 5.x server it abends.

Answer:  PMUSER uses low-level features of NetWare that appear to change from version to version of the operating system. At the present time, we have no solution for this problem other than to recommend that you do not use PMUSER, or that you use the manual mailbox configuration utilities (MAKEMBOX or NConfig) instead and do not install PMUSER.


Problem:  I can't send to or receive mail from Mercury

Solution:  This and numerous variants of it make up over 95% of the problems reported with Mercury. In general, this is a configuration problem, in NetWare TCP/IP, in MERCURY.INI, 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.
- Make sure your name server 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.


Problem:  I get "Loader could not find symbol 'inet_addr'" or similar loader errors from NetWare when I try to load MercuryS or MercuryC

Solution: You have not loaded NetWare TCP/IP (TCPIP.NLM). Examine MGUIDE.EXE for a brief description of installing and configuring TCP/IP on your server, and in the NetWare Red manual entitled "NetWare TCP/IP Transport Supervisor's Guide" for more detailed information.


Problem:  I get one of the following errors:   "Socket read/write timeout or error";  "Connection error during handshake with xx.xx.xx.xx";  "TCP/IP error during processing"???

Solution:  These errors all typically indicate a routing or traffic problem on your IP network. Make sure that the "BIND IP" line of your server's AUTOEXEC.NCF includes a "GATE=" parameter (we suggest you ignore the Novell recommendation not to use GATE= when using RIP), and that all IP routers on your network are aware of your server and how to find it.


Problem:  I get errors like "503 Need recipient" from Mercury

Solution:  This error (and any error like it starting with a 3-digit number) is actually being issued by the mail host which Mercury uses to relay mail, not by Mercury. It usually indicates an addressing problem in your message, but you should refer it to the system manager on the mail host


Problem:  I can send mail out, but no-one can send mail to me

Solution:  This usually means that your server's Internet name is not being advertised on the Internet. You must have an entry in a DNS (Domain Name Server) system somewhere which allows other sites to work out your server's address from its name. Contact your IP network manager or Internet Service Provider for details.


Problem:  Mail goes out with the wrong "From" address even though I've changed the MYNAME value in MERCURY.INI's [General] section.

Solution:  You also need to change the Pegasus Mail configuration information to reflect the new Internet name. Use the Pegasus Mail PCONFIG program to do this.


Problem:  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.

Solution: You almost certainly have an incomplete or inaccurate [Domains] section in MERCURY.INI. You must list in your [Domains] section every possible Internet name by which your file server could be addressed. 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.


Problem:  Error messages from mailing lists are returned to the sender of the original message.

Answer:  This is an area where usage is vague on the Internet and it is difficult to provide a general solution. Try adding an "Errors-to:" field to the definition for the list in Mercury's "List of Lists". This will force error notifications to go to the specified address in many cases, but unfortunately not all Internet mail systems follow the rules.

0
-1

Background:

There is no single right way to install Pegasus Mail for Windows (WinPMail) and Mercury/32 in multi-user standalone mode or in a non-NetWare network (such as WinNT, Lantastic, Win95/98 peer-to-peer, etc.). However, we do recommend that you use a network with advanced rights capability, like WinNT or NetWare or Lantastic. When you use Win95/98 peer-to-peer technology, you are limited to only three possible security rights: none, read-only, and full access. To provide the best security, your network must also support add/create rights (sort of an "incoming" or "drop-box" right that allows you to create files in a directory, but not see anything within in the directory, including the file you just created. Create rights are used by WinPMail in order to deliver mail directly into other local user's mailboxes and to spool outgoing SMTP messages to Mercury/32. If you decide to not allow users to send mail directly to other local users (forcing them to go through Mercury/32 instead) and do not care whether or not users can view spooled outgoing SMTP messages from all users on the system (or if you plan to force all users to send outgoing mail to Mercury/32 via the built-in SMTP client feature), then a Win95/98 peer-to-peer network will do just fine.

For SMTP mail, Mercury/32 can either be configured to:

  • receive incoming mail directly from other Internet mail hosts; or

  • use POP3 to download mail from one or more POP3 mailboxes (including domain mailboxes) on your ISP's mail host.

 

The method you decide to use above normally depends upon the type of Internet connection you have. Having a full-time Internet connection (even if only a dial-up 56K modem connection that is always active) is the most versatile, allowing you to choose either option above, although using Mercury/32 as your SMTP server for incoming mail instead of using your ISP's POP3 server would be the preferred method of operation. Even if you choose to use Mercury/32 as your SMTP mail host, you should still request that your ISP's mail host serve as a secondary backup mail host on behalf of your domain in case your server or connection goes down; this allows incoming mail to queue up on the ISP's server and when your connection is re-established, the ISP's server can quickly transfer the mail to Mercury/32. Full-time connections include full-time dial-up regular modems or ISDN modems, cable modems, xDSL modems, frame relay, T1 or T3 leased lines, etc. Note that you'll also need a fixed IP address for your Mercury/32 machine so that it can be assigned to your domain name for incoming mail.

If you can only afford a standard part-time dial-up modem connection, then you'll most likely be using the ISP's mail host for POP3 mailbox services using either separate POP3 mailboxes for each user (preferred to reduce the chance of mis-directed mail and to enhance privacy/security) or a single POP3 domain mailbox that stores all incoming mail for your network. Domain mailboxes may have a limited number of defined aliases (or usernames) that can be used with the domain (attempting to use any other alias username would fail) or may be unlimited, allowing any username to be used whether or not that username actually exists in your network.

POP3 domain mailboxes can be problematic when a message's recipient list is suppressed, such as in the case of receiving mail from mailing lists as well as spam mail. In such cases, manual intervention by the default user (usually your network's sysadmin) will usually be required in order to redirect the message to the appropriate user.

If your ISP's SMTP mail host supports the ERTN standard and your ISP is willing to queue incoming SMTP mail on behalf of your network, then you can have Mercury/32 send an ERTN command to the SMTP host immediately after the dial-up Internet connection becomes active so that the SMTP host will know it can start transferring any queued incoming SMTP mail it has for your network. In this scenario, incoming SMTP mail is queued on your ISP's host while your Internet connection is down. If supported by your ISP, this solution is much better than using POP3 mailboxes on your ISP's mail host.

You also need to decide whether to have Mercury/32 simply relay all outgoing mail to your ISP's mail host (using the MercuryC SMTP relay module) or to have Mercury/32 actually attempt the transfer of outgoing mail to the recipients' mail hosts (using the MercuryE SMTP end-to-end delivery module). The MercuryE module requires that you have access to a DNS name server in order to perform DNS domain host name resolution. Due to the abuse of mail relaying by spammers (those who send unsolicited commercial junk e-mail), most ISPs use anti-relay code on their SMTP hosts; thus, you'll need to ask whether or not your ISP to allow mail relaying from your domain if you decide to use the MercuryC SMTP relay client. MercuryC has the advantage of pumping messages out very quickly to the SMTP relay host, which is helpful in locations where time online or on the phone is an extra expense. MercuryE has the advantage of not having to mess with an ISP's policy and particular (possibly proprietary) implementation for relaying SMTP mail through their mail host. However, MercuryE requires more online time for delivery since it has to lookup the domain host names for the recipients and actually transfer the outgoing messages separately to each recipient's mail host.

Preparation:

Once you've determined the type of Internet connection and mail technology you're going to use, you need to determine where you will store the user mailboxes and on which machine you will install Mercury/32. The user mailboxes normally need to be on a generally accessible machine (usually a server) that is always running and to which all users have the required rights to work with their mailbox and (optionally) to deliver mail to other local user mailboxes. The rights requirement above doesn't apply if all users will be accessing their mailboxes via POP3 and/or IMAP4. This machine should be fast (although any Pentium PC capable of running a Win32 OS will generally do fine for small installations of up to 25 users), have plenty of disk space available, and be able to handle the large number of network connections that will be accessing files from its drive(s) and polling the mailboxes for new messages. Note that IMAP4 places the largest amount of load on the Mercury server in terms of network and disk activity as well as memory usage. Content control, filtering rules, and policies (especially anti-virus policies) cause the most CPU utilitization and cause the most delay in processing incoming mail.

Mercury/32 usually must be installed onto the PC that has the dial-up modem, if applicable. If there are multiple PCs with modems, you might want to pick the one on which the user mailboxes reside for quicker response time and higher reliability. If you happen to have an external dial-on-demand dial-up router providing your Internet connection and you have IP addresses defined on your network, then you can install Mercury/32 on any Win32 PC on your network. Mercury/32 requires full rights to the user mailboxes as well as to the Mercury queue directory. Such rights normally mean that Mercury/32 should either be installed onto an NT server as a service, on the sysadmin's PC, or onto a secured machine. Mercury/32 can be installed as a service under Windows NT using the SRVANY utility available from Microsoft.

WinPMail can be either installed on all the workstations or just on a central file server with WinPMail shortcut icons created on each of the user workstations.

Installation:

Start by installing WinPMail (if applicable to your environment) onto your workstations or onto a central file server. For increased performance, you may install WinPMail on each of the workstations. However large sites may want to use central file servers to save the time of installing onto each individual workstation and for easier upgradeability to newer versions and patch installations.

While logged in on one of the workstations with administrative rights over the network to the "mail server" machine, run WinPMail. When prompted for the type of installation (single-user or multi-user), choose a "multi-user network" installation. When prompted for the root mailbox directory path, type in the UNC path to root directory of the multi-user mailbox on the "mail server" machine. WinPMail will create the directory structure if it doesn't already exist. e.g.

\\mailpc\c-drive\mail

 

WinPMail creates a PMAIL.CFG configuration file in the WinPMail program directory once you've completed this step of the configuration process. Rather than having to respecify this configuration on each of the other workstations in your network, you can simply copy this PMAIL.CFG file to the WinPMail program directories on each of the other workstations (if applicable).

Next, you will be prompted to create each of your users. A list of these users will be created in a PMAIL.USR file in the root mailbox structure (e.g. \\mailpc\c-drive\mail). You need to create at least one administrative user account so that you can run WinPMail with that account and perform future user management functions (such as adding, modifying, or deleting users). WinPMail uses the usernames as the user mailbox directory names. e.g.

user1 ---> \\mailpc\c-drive\mail\user1

 

Additionally, WinPMail is normally limited to using 8-character dos directory names (for compatibility with Win16 and DOS systems), so each of the usernames you create may need to be 8 characters long or less. WinPMail won't allow you to create usernames longer than 8 characters; you also cannot use spaces nor other characters in the username that would be considered illegal in a dos directory name. While this may all seem limiting, you can get around the limitation to provide such extravagant e-mail addresses as firstname.lastname@domain.com by using synonyms, which will be discussed later in this document.

Note: Mercury allows you to create usernames and mailbox directories longer than 8 characters. If you plan to be using Mercury in your Pegasus Mail environment, you must use Mercury to manage the local users.

You should then assign network rights on the "mail server" machine for each of your users. Users will require full rights to their own mailbox directory (e.g. \\mailpc\c-drive\mail\user1), read rights to the root mailbox structure (e.g. \\mailpc\c-drive\mail) in order to be able to read the PMAIL.USR user file, and (optionally) create rights to each of the mailbox subdirectories below the root mailbox structure so that they can send mail locally to other users. You can use the Everyone group or another mailusers-related group to assign rights for all users. At this point WinPMail is fully set up for local internal mail purposes.

For SMTP/POP3 mail services, you should now install Mercury/32 onto the "SMTP gateway" machine. Choose New Installation when prompted and then choose No NetWare Support. Next the installer will ask you for the path into which to install Mercury/32. By default Mercury/32 will be installed into the C:\MERCURY directory and will contain a C:\MERCURY\QUEUE subdirectory for outgoing queued SMTP messages. Since WinPMail on each workstation needs to be able to write outgoing messages into the queue subdirectory, you might need to reconfigure Mercury/32 to reference a queue directory on the "mail server" machine instead (we'll explain how to do this later on).

The installer will next ask you to type in the directory path to the WinPMail program so that a PMGATE.SYS Mercury gateway definition file can be created within the WinPMail program directory to allow WinPMail to integrate with Mercury/32. If you have installed WinPMail locally on all your workstations, you'll later need to copy this PMGATE.SYS file to the WinPMail program directory on each of your workstations.

If you specified the correct directory above for the WinPMail program files, the next prompt concerning the mailbox directory location should already point to the proper directory where the root mailbox directory structure is location on the server. The path here can be entered in as a UNC network path or a local drive path if the mailboxes actually reside on the Mercury/32 machine.

The next installation dialog window prompts you to check those protocol modules of Mercury/32 that you wish to use. There are currently ten different modules to Mercury/32:

  • Mercury core module (always required, not listed in this dialog)

  • Mercury SMTP Server module (MercuryS)

  • Mercury SMTP Relay Client module (MercuryC)

  • Mercury SMTP End-to-end Client module (MercuryE)

  • Mercury POP3 Server module (MercuryP)

  • Mercury POP3 Client module (MercuryD)

  • Mercury Task Scheduling module (MercuryX)

  • Mercury Finger Server module (MercuryF)

  • Mercury PH Query Server module (MercuryH)

  • Mercury PopPass Server module (MercuryW)

 

Note: The two SMTP Client protocol modules listed above are actually prompted for in the next dialog rather than in this dialog. There is a "?" Information button next to each module to give you more info about that module.

So which protocol modules do you select? Well, you can usually select all of them without adverse problems, just in case you decide to use one later. It's also simple enough to add a module in later on by modifying the MERCURY.INI file in the Mercury/32 program directory with a text editor like Windows Notepad and adding a statement for the respective protocol module's dll file within the [Protocols] section. Knowing this, you can decide initially to only install those modules you really know you need. If you have a full-time Internet connection, you will most likely need only MercuryS and MercuryC or MercuryE. If you have a dial-up connection and are using SMTP with ERTN , you need MercuryS, MercuryC, and MercuryX. If using POP3 mailboxes over a dial-up connection, you'll need MercuryC, MercuryD, and MercuryX. If you will have users dialing into your network from home to download their new mail mail via POP3 or some of your users run a different POP3 mail client or run WinPMail remotely from another location over your full-time Internet connection, you'll also need the MercuryP and MercuryS modules (regardless of the type of Internet connection you have). The MercuryF, MercuryH, and MercuryW modules are all optional. MercuryF provides a FINGER server capability similar to those found on unix systems. MercuryH provides a CSO-PH directory service ability that can be configured to use a Pegasus Mail address book as its directory source and that can be accessed by Pegasus Mail's or some other PH directory client. The MercuryW module provides a way for users to remotely change their mailbox password (useful if users access their WinPMail/Mercury mailbox remotely via POP3).

After selecting the desired protocols, the next dialog prompts you for which SMTP Client protocol you wish to use: MercuryC SMTP Relay Client or MercuryE SMTP End-to-end Delivery Client. After selecting the desired SMTP Client protocol, the next step of Mercury/32's installation regards setting up the basic working configuration. You'll need to know or obtain the following info from your ISP:

  • the host name or IP address of this Mercury/32 machine (it can also just be your domain name).

  • WinPMail username to use as your local Mercury Postmaster.

  • the host name or IP address of your ISP's SMTP relay host, if you will be using the MercuryC SMTP Relay Client.

  • which level of anti-relaying to enable, if any (only required if MercuryS is installed). Normal anti-relaying is usually sufficient. Other options include Strict and None.

 

The last thing the installer needs from you is the directory path to the mail queue location. This path is used by both Mercury/32 and WinPMail. We recommend that the queue directory reside on your "mail server" PC; you should use a UNC network path to reference it (e.g. \\mailpc\c-drive\mail\outgoing).

Once the installation is completed, you should copy the PMGATE.SYS file (mentioned earlier) to the WinPMail program directory on each workstation. If you want to first verify that the PMGATE.SYS gateway definition file is okay before copying it to all of your other workstations, run

PCONFIG.EXE -S
within the WinPMail program directory where the PMGATE.SYS file was created and go to the user-defined gateways section. You shoud see an entry for MERCURY. When you view this MERCURY gateway definition, you should see a screen similar to the following:
           Gateway name : MERCURY

*New mail path :

Is ^ a program to run? : N

*New mail search mask :

*Outgoing mail path : \\mailpc\c-drive\mail\outgoing

*Run for outgoing mail :

*Filename format : ~d~d.101

Run to validate address :

*Reply address format : "~p" <~L~L~8@domain.com>

Accepts SMTP addresses? : Y

Simple message headers? : 'Glue' headers

UUEncode attachments? : Y

Burst messages? : N Gateway processes BCC? : N

Strip gateway name? : Y

Force all mail through? : N

 

Make sure the Outgoing mail path specifies the UNC network path to your Mercury/32 spool directory, as seen by your workstations. Also check the Reply address format field. This field shows you how your From: header will look on outgoing SMTP mail messages. The "~p" represents your full name, as defined within the Personal Name field within the General Settings options of WinPMail. The two "~L" sequences can optionally have a filename between them referencing a synonym file (SYNONYM.MER is the default filename if none is specified, as shown above); the synonym file should be placed into both the Mercury/32 program directory as well as the WinPMail program directory wherever it is installed (on central file server and/or on all of the workstation PCs). More about synonyms shortly. The "~8" represents your WinPMail username (8-char max). Make sure the host name given after the "@" (e.g. "domain.com") is listed exactly how you want it to look in e-mail address. e.g.

"John Doe" <user1@domain.com>

 

If this form of e-mail address formation is too restrictive for you or you need to map POP3 user aliases to WinPMail usernames or you wish to standardize on a formal username structure, like "Firstname.Lastname", you can set up personalized synonyms for each user so that their username looks however you need it to look. e.g.

Jonathan.Doe@somedomain.com == jdoe

POP3-username@domain.com == User1

 

If you wish to create synonyms for your users, read further below in the section entitled Synonyms.

You can also set up aliases within Mercury/32 so that incoming mail to certain e-mail addresses will be redirected as necessary to either local or external addresses. e.g.

support@domain.com ---> fred

someone@domain.com ---> ex-employee@another.company.com

 

Note that aliases have no effect on how the From: field looks in outgoing messages--although you can reference your alias address as your default reply-to address.

If you wish to create aliases for your users, read further below in the section entitled Aliases.

At this point, the general setup of WinPMail and Mercury/32 is complete. However, there is much more required to get Mercury/32 operational, such as configuring MercuryD for POP3 downloads from your ISP's mail host, setting your timezone value (we recommend just enabling the Auto setting), configuring the MercuryX task scheduler to set up dial-up intervals, etc. These topics are covered below.

Configuring MercuryD to download POP3 mail from your ISP's mail host:

If you will be using POP3 mailboxes on your ISP's mail host, you'll need to configure the MercuryD POP3 client module to download your users' POP3 mail. The POP3 account information section lists the different POP3 accounts you've defined already. Each entry can be configured for one of two possible types of POP3 accounts:

  • a regular single-user POP3 mailbox account, or

  • a POP3 domain mailbox account.
It's quite possible to have both types of POP3 mailbox accounts defined within MercuryD's POP3 Account Information list.

 

To configure a single-user POP3 mailbox account, you'll type in the host name or IP address of your ISP's POP3 host, the POP3 port number used by the POP3 host (defaults to 110 if left blank), the POP3 username and password for this mailbox, and the WinPMail local username for which this POP3 mailbox belongs. The Default User field should be left blank.

To configure a POP3 domain mailbox account, you'll type in the same info as above, but leave the Local User field blank. This will force Mercury/32 to scan the To:, CC:, and BCC: message header fields of the POP3 messages to locate any e-mail addresses it recongizes as local users (it also scans against the Mercury synonym file and alias file when determining if an address is local). Any messages for which a local user cannot be found is discarded, unless you type a local username into the Default User field, in which case these messages will be delivered to the default user for manual distribution or deletion.

Configuring the MercuryX Task scheduler:

The MercuryX Task Scheduler module has the job of coordinating the online/offline periods of Mercury/32's modules as well as starting and disconnecting the dial-up connection. We recommend that you enable the two checkbox options to "Use Win98/MS IE 4 dialling functions" (WinInet.dll) for both dialing before and hanging up after.

If you'd rather use an external dialer utility to dial and/or disconnect the connection or when you need to dial a DUN connection other than the default one or if you don't have access to WinInet.dll, Mercury/32 includes an external utility in the RESOURCE subdirectory called RASDIAL95 that can be used for this purpose, or you can choose your own external RAS dialer.

It is usually also a good idea to enable the option to allow the processes to finish completely (drain) before disconnecting (there is a max wait timeframe though, in case a process gets locked up).

If you will be using the MercuryS SMTP Server module along with an ETRN mail queue on the ISP's mail host, you'll need to enable the SMTP ETRN (RFC1985) checkbox to start the remote queues when MercuryX goes online. Click on the Specify button to modify the ETRN.DAT configuration file within the Mercury program directory. The syntax of the ETRN.DAT file is as follows:

Supplier SMTP host name

Your SMTP host name (as your provider expects it to be)

 

(Make sure the second line is indented with at least one space or a tab character.)

For example,

mail.isp.com

mail.local.domain.com

 

The last configuration item for MercuryX is setting up the actual schedule. You can set a separate schedule for each day of the week and you can effortlessly copy schedules from one day to another day if you want to set up multiple days with the same schedule.

To set up a schedule, pick a day of the week first. You have the ability to schedule two different sets (peak and off-peak) of start intervals and connection durations. Be sure to specify all times in 24-hour military time. e.g.

11:05am == 1105

5:30pm == 1730

 

Specifying an interval of 0 leaves the connection active continuously throughout that specific (peak or off-peak) schedule set. Setting it to -1 will disable any connection activity throughout that period of time.

Synonyms:

Many sites need to use custom address formats where the user's e-mail address is quite different from the actual user name on the system. For example, you may want your addresses to have the form Firstname.Lastname@host.domain. Simple aliasing won't allow you to do this kind of addressing easily; it will handle incoming mail well enough, but in order to get mail going out from your system to use the alternative address forms requires the co-operation of your mail client.

Pegasus Mail and Mercury/32 can combine to support alternative address formats like this (referred to as synonyms) using a special database called a synonym database: Mercury needs this database so it can work out the recipient for incoming mail, while Pegasus Mail needs it to work out what address it should write into outgoing messages for this user. Here are the steps to configure Pegasus Mail and Mercury/32 for synonyms in non-NetWare mode:

  1. Create a synonym source file (e.g. SYNONYM.TXT). This is a text file where each line has the form:
    synonym@domain.com == username
    

    So, on the right-hand side you place the user's local name, and on the left-hand side his or her e-mail address as you want it to appear in outgoing mail. Note that each line must begin hard against the left-hand margin.

  2. Compile the source file using the FSYNONYM.EXE commandline program. FSYNONYM.EXE takes your input file and creates a synonym database file. This file is included with Mercury/32.

  3. Copy the synonym database somewhere accessible by Mercury/32 and make sure the Synonym database file entry of the Files tab preferences page of the Mercury/32 core module configuration dialog refers to that file.

  4. Copy the synonym database file into the same directory as your copy of the Pegasus Mail executable file (either WINPMAIL.EXE or WINPM-32.EXE), making sure it is called SYNONYM.MER. If Pegasus Mail is installed locally on all the user workstations, you'll have to copy this file to each of the workstations.

  5. [Only required once] If you didn't see a MERCURY user-defined gateway definition specified earlier when running PCONFIG.EXE -S, you can use the Pegasus Mail option on the Mercury/32 configuration menu to configure your copy of Pegasus Mail. This operation is only required if you have upgraded your copy of Mercury/32 from an earlier version or have never installed Mercury/32 until now, and only needs to be done the one time: it creates a new version of PMGATE.SYS that instructs Pegasus Mail to use the synonym file (SYNONYM.MER) if it exists in the Pegasus Mail program directory. If Pegasus Mail is installed locally on all of the user workstations, this PMGATE.SYS file will also need to be copied to each of the workstations.

 

Aliases:

An alias is a virtual e-mail address that stands in for another e-mail address on your system for incoming mail only. Aliases are often used to create addresses which do not vary, even though the person who receives the mail may change. For example, say you want to offer your customers an e-mail address they can use to obtain support; it is clearly much better to use an address like support@mydomain.com than to give the address of a specific user on your system (like Fred@mydomain.com). That way, if the user leaves or is transferred, you can simply redirect the alias for "support" to someone else without having to contact all of your customers to change the e-mail address required for support. It also is useful for when a user's name has changed (e.g. marriage/divorce) or when a user's name is easily mispelled and you want to provide alternatives that match the most common mispellings (e.g. Villarreal, Vilareal, Villareal, etc.).

A synonym is a specialized form of alias that effectively replaces a user's real e-mail address with an alternative form. Using synonyms, you can adopt consistent addressing schemes that differ from your users' actual login names. For more information on creating and using synonyms, see above in the section about Synonyms.

Mercury/32 has very powerful aliasing features: you can access them either from the Configuration -> Aliases... menu option, or by using the commandline import/export tool MALIAS.EXE supplied with Mercury/32. An alias simply consists of two parts - the alias (or, the address people use to send mail) and the real world address (the address to which Mercury should deliver any messages it receives addressed to the alias). The real world address does not have to be a local address - it is perfectly valid to have an alias for an address on a remote system (this approach is often used to redirect mail to someone while they are absent, or if they leave the organization).

Keywords: WINPMAIL WINPMAIL/16 WINPMAIL/32 MERCURY/32 INSTALL INSTALLING INSTALLATION CONFIGURE CONFIGURING CONFIGURATION WINDOWS NT WINNT LANTASTIC PEER NETWORK

Date Created: &nbsp;
7/1/2000, 8:36:31 PM
Last Updated: &nbsp;
9/26/2004, 1:33:36 PM
Document ID: &nbsp;
C1523317-4EC6-11D4-8B6B0008C709E5EC
17
31
1
Actions
Hide topic messages
Enable infinite scrolling
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft