The Mail Server consists of the following components:

SMTP Server	A basic SMTP server for receiving mail and queuing to either local or remote delivery.
POP3 Server	A POP3 server for access to local mailboxes via common mail readers such as Eudora, Microsoft Outlook or Netscape.
Mail Fetcher	A background thread for retrieving local mail from remote POP3 and IMAP4 mail servers.
WebMail	A web-based mail reader for local mailboxes.
IMAP4 Server	An IMAP4 server for access to local mailboxes via an IMAP mail reader such as JavaMail or Outlook.

Quick Start Guide
After purchasing a Sambar Server Pro License and installing the license, the following steps will guide you through the Mail Server configuration:

Initialization

• From the System Administration -> Mail form click on the on link to enable the mail server.

You should see a Mail Server configuration page at this point with the default mail server shown as machinename.foobar.com. You can configure and test the mail server before pointing the MX record to the server.

User Mailboxes

Next, configure one more more user accounts from the System Administration -> Security -> Users forms or, if you have already created a user account, enable the user's mailbox from the System Administration -> Mail > Users forms. Usernames may not contain the period (.) character, however, aliases can be used to support this functionaliaty.

• Select an existing user, "check" the Mailbox field at the bottom of the user form and update the user.
• Create a new user and "check" the Mailbox field at the bottom of the user form.

(Note: The only action associated with creating a user mailbox is to create a directory for the user in the mail/mbox directory (e.g. mail/mbox/billy-bob) and then creating a zero-length file, inbox.fld. If this file does not exist, the the user is determined not to have a local mailbox. You do not need to manually create these files/directories if you use the configuration pages.)

Test your Server

After configuring your mail client to use the Sambar Mail Server as the SMTP and POP3 server, you should be able to send mail to the local mailboxes you created using the default domain foobar.com (e.g. billy-bob@foobar.com). To test/verify your configuration, login to WebMail with a user account and send mail to yourself using the compose form (i.e. billy-bob@foobar.com). If this works, then the only remaining thing to do is configure the Mail Server name and set the MX record.

Several other features you should consider enabling if running an MTA: Allow Localhost, SPAM Greeting Delay, SPAM Greylisting. In addition, the Watcher Service should be enabled under the System Administration -> Services forms. The Watcher service continually monitors the Sambar Server and can restart and/or send email if the server cannot be contacted.

Finally, customize the the Mail Server using the System Adminstration -> Mail -> Configure forms. Features you will wish to customize include: Mail Server and Local Domains. You may also wish to setup a Mail Fetcher to retrieve mail from one or more POP3 mailboxes. Lastly, the Anti-SPAM forms contain some useful spam-blocking functionality you may wish to enable.

mail.ini Configuration File
If Act As Mail Server is set to true in the config.ini the Mail Server is initialized at startup. The parameters of the mail.ini configuration file (below) guides the Mail Server operation.

[mail]

Mail Server	The domain of the mail server (i.e. sambar.com). This symbolic name is used for identifying local mail. The server's fully-qualified domain name is derived by adding the machine name to this domain; if not set, the system name is used which is typically not acceptable for relaying mail.
Mail Server FQDN	The fully qualified domain name associated with the server. This name is used by the MTA when delivering remote mail. If not set, the fully qualified domain name is derived by prepending the machine name onto the Mail Server domain name.
Mail Directory	The directory in which user mailboxes are created (default mail/mbox).
Mailing List Directory	The directory in which mailing lists configuration files are created (default mail/maillist).
Maximum Users	The maximum simultaneous mail users.
Maximum MTA Routers	The maximum simultaneous mail router threads used to deliver mail messages. By default, only a single thread is used; for heavily used mail servers, several MTA routers can be configured.
Maximum Mailbox Size	The maximum size of any individual mailbox. This parameter applies to all mailboxes.
Maximum Fetcher Failures	The maximum consecutive mail fetcher attempts that fail before the fetcher is halted. This parameter can be set to 0 to continue failing fetchers regardless of the success or failure of the download.
CGI Timeout	The maximum time to wait for a mail server CGI script to complete.
Router CGI Script	The full path to the CGI script to run prior to delivery of a mail message. This script is called prior to delivery of the mail message to any mailboxes by the router. The user can rewrite the message, delete or rewrite recipients, or delete the message entirely. On return, if the message file has been deleted, the router assumes there are no recipients and continues.
POP3 Read Timeout	The maximum time to wait for a client POP3 request.
SMTP Timeout	The maximum time to wait for a client SMTP request.
IMAP4 Timeout	The maximum time to wait for a client IMAP4 request.
Run SMTPD	A boolean, true or false, indicating whether the local SMTP Server should be run.
Enable WebMail	A boolean, true or false, indicating whether the WebMail browser-based mail interface should be enabled.
WebMail Date Format	WebMail will display mail message dates in either, received or sent.
Trace SMTP	A boolean, true or false, indicating whether to trace SMTP activity.
Trace POP3	A boolean, true or false, indicating whether to trace POP3 activity.
Trace Router	A boolean, true or false, indicating whether to trace MTA activity.
Trace Fetcher	A boolean, true or false, indicating whether to trace Mail Fetcher activity.
Backup Mailboxes	A boolean, true or false, indicating whether user mailboxes should be backed up daily. If enabled, mailboxes are backed up daily for a one week interval, enabling a rolling one-week backup of user mail. Backups are maintained in the backup directory (found in the user's mailbox directory). Users can recover backups via the WebMail interface.
Safe Save Mailboxes	A boolean, true or false, indicating whether user mailboxes should be backed up on each save. Only a single backup is kept and it is compressed in the user's mailbox directory as mbox-name.bkp.gz. It is recommended you leave this feature enabled to assist in recovering mailboxes in the event of a failure.
Public Mailing Lists	A boolean, true or false, indicating whether users with mailboxes on the server should be allowed to create their own mailing lists. If enabled, the mailing list management interfaces are exposed to users via WebMail.

[smtpd]

Relay Delivery	An identifier: ondemand, never, hourly or daily that indicates how often remote mail delivered to the local SMTP Server should be relayed to your ISP's SMTP Server or sent via the MTA for internet delivery. If set to never only local mail (mail destined for a local mailbox) will be accepted by the SMTP Server for delivery. For full-time internet mail servers, this should be set to ondemand.
Relay FROM User	The user mail address (i.e. tod@sambar.com) that should be use when relaying mail to the remote server. By default the SMTP router uses the mailbox sender as the FROM address to the relay SMTP server. However, if the relay SMTP server does not permit relay of anonymous or unknown users, the mail may be rejected. This parameter ensures that all remote mail is delivered using a valid address. (Note: This does not affect the "From:" address the mail recipient sees).
Relay AUTH Protocol	The SMTP AUTH protocol to use when relaying mail using an AUTH mechanism. The options for this field are: PLAIN | LOGIN.
Relay AUTH Username	The SMTP AUTH username to provide when relaying mail. The SMTP AUTH feature is only used when mail is delivered via a remote SMTP daemon.
Relay AUTH Password	The SMTP AUTH password to provide when relaying mail.
Local Domains	A space separated list of mail servers that should be treated as "local" to the SMTP Server. When mail is received by the SMTP Server, the Mail Server, Local Domains and Relay Domains are compared with the mail recipients to determine whether the recipient is "local" or "remote". The wild-card star (*) character may be used for pattern matching, i.e. *sambar.com Important! You can have multiple Local Domains lines in the config/mail.ini file if you have more domains than can fit on a single line (1000 bytes); if using multiple lines, you cannot use the mail configuration interface to update the mail configuration (only the last local domain line will be saved.)
Relay Domains	A space separated list of mail servers that should be treated as peer SMTP Servers. Mail destined for servers in the "relay domains" list are accepted by the server and forwarded. This directive allows for the creation of multiple mail servers that act in a peering relationship with one another for receiving and forwarding mail. The wild-card star (*) character may be used for pattern matching, i.e. *sambar.com Important! If a Local Domain is also added to the Relay Domains parameter, any mail destined for an "unknown" mailbox is forwarded to the "primary" SMTP server (which is assumed to be a remote server).
Maximum Message Size	This parameter restricts the maximum size of any single message accepted by the SMTP server. For WebMail use, the Sambar WWW Server parameter Maximum Content-Length determines the maximum WebMail attachment that can be uploaded to the server. To allow large mail attachments via WebMail, both the Maximum Message Size and Maximum Content-Length must be increased.
Spool Directory	The directory in which all incoming mail is spooled by the SMTP server before delivering to either local mailboxes or the remote ISP mail server. An internal "Mail Router" runs periodically to deliver mail in the spool directory. In the event of a server crash, files in the spool directory are delivered at startup.
Failures Directory	The directory in which mail that cannot be delivered is deposited.
Require AUTH	If true, all mail sent to the SMTP server must be bound for a local user (the address must be for a local domain) or the client sending the mail must be authenticated as a local user via the SMTP AUTH command. This is an anti-spam feature that over-rides the Restrict Relay IPs to ensure that only "valid" mailbox users can use the SMTP server to send outgoing mail. (Note: WebMail always authenticates via AUTH.)
Verify Sender	If true, all mail users that AUTH via the SMTP server must send the proper FROM envelope (prevent spoofing). This does not prevent the user from modifying the From: header in the DATA portion of the message, but does maintain the integrity of the FROM envelope. (Note: The SPAM Check 'FROM' can be used to prevent a mismatch between the FROM envelope and From: header). Administrator users accounts are allowed to bypass this restriction.
Always Allow localhost	A boolean, true or false, indicating whether to override the "Require AUTH" directive for mail sent from "localhost". If true, all mail from localhost is delivered regardless of the To or From addresses.
Restrict Relay	A boolean, true or false, indicating whether mail from users other than those with local accounts should be relayed. This is an anti-spam feature that should be used in conjunction with the Restrict Relay IPs to ensure that only "valid" mailbox users can use the SMTP server to send outgoing mail. If set to true the FROM address must be a valid local account, or mail must be destined for local users only.
Restrict Relay IPs	The host(s) who are allowed to send mail via the SMTP server to outside mail addresses. This is an anti-spam feature (Restrict Relay must be set to true) which restricts internet users from using the SMTP server to relay their mail. You may provide a space separated list of IP addresses which identify valid SMTP users. If left blank, an SMTP user may login from any host. The wild-card star(*) character may be used for pattern matching, i.e. 140.175.165.*
Use MTA	A boolean, true or false, indicating whether mail should be sent via the internal mail transfer agent (MTA), or the users ISP SMTP server. If set to true, the internal MTA is used (this requires access to internet MX records for direct mail delivery). Important! When the MTA is used, the DNS Primary and DNS Secondary from the config/config.ini are used for MX record resolution. These entries must point to DNS servers that accept and respond to MX record lookup requests.
Return Delivery Warning	A boolean, true or false, indicating whether mail that could not be delivered on the first attempt should return a warning message to the user. If set to false, the user will recieve no notification of message delivery issues unless all attempts to deliver the message have been exhausted and a failure notification is generated.
Unknown Mailbox	The mailbox that all "unknown" mail is deposited into. This mailbox is used if mail is directed to the Mail Server or a Local Domain for which there is no corresponding local mailbox (similar to the "catch all" email address available in sendmail.) If this paramenter is not set, mail is rejected if a local mailbox does not exist. With the 5.3 release, unknown mailboxes can be configured on a per-domain basis in the mail.ini file. The section [unknown-mailboxes] can be used to mail uknown mailboxes to specific domains, i.e. [unknown-mailboxes] admin@sambar.net = sambar.net admin = sambar.com sambar.org Important! Unknown mailboxes configured in the [unknown-mailboxes] section will override the Unknown Mailbox parameter in either the smtp or fetcher configuration parameters.
Maximum Recipients	The maximum recipients (including alias expansion) that any single message can be directed to.
Maximum Received Hops	The maximum mail server hops that a message can traverse before being deemed in a loop. An improperly configured mail agent might forward mail in a cycle until the maximum hops are achieved and the message is removed from the system.
Maximum Retry	The maximum number of (4 hour default) intervals that the server should attempt to retry message delivery upon server delivery failure. By default this is 12, or 2 days for the MTA (retry for the MTA can be modified by changing the Maximum Retry Interval from the 4 hour default). Important! if a mail relay server is used, the retry interval is actually every 10 minutes, the total interval is still calculated based on the retry interval period.
Maximum Retry Interval	The retry interval, in seconds. By default, mail messages that could not be delivered correctly the first time are retried every 4 hours (14400 seconds). Important! if the maximum retry is left at 12 and the interval is changed to 10 minutes for example, then the mail router will retry every 10 minutes 12 times for a total duration of 2 hours. Should the recipients mail server suffer an outage longer than 2 hours, the mail will bounce to the sender.
Total SPAM Protection	A boolean indicated with the Total SPAM Protection feature can be enabled by users.
Total SPAM Password	The server-side Total Spam Protection that overrides any user-specified passwords.
SPAM Greylisting	A boolean indicated with the SPAM Greylist is enabled on the SMTP server.
Greylist Wait Period	The time in seconds to wait between the first contact from a new mail server and the acceptance of mail from that server. The default is 10 minutes.
Greylist Save Period	The time in seconds to write out the greylist to disk. By default this is every 8 hours.
Greylist Purge Period	The time in seconds after which a server is purged from the greylist if they have not sent a followup message (retry). By default this is every 8 hours. Purging only occurs during a save to disk, so the save period should be at least as frequent as the purge period.
Enable Plus Addressing	A boolean indicating whether the SMTP server should support plus-addressing. Plus addressing allows direct delivery to a particular mailbox (other than an INBOX). This allows delivery to a subfolder of a specific user. This is done via an address of the form: username+mailfolder@domain, which will deliver to the user's mailfolder folder.

Mail all server users
The special mailbox everyone can be used to deliver a mail message to everyone who has a mailbox on the server. Only the system administrator can deliver a mail message to 'everyone' and the administrator must use SMTP AUTH to authenticate their identity.

Help Stop Mail Abuse!
If possible, the Require AUTH parameter in the [smtpd] section should be set to true. This is the surest way to protect your mail server from being used as a mail relay by spammers.

User aliases
The mail.ini file may contain user aliases. Aliases are used to identify a local mailbox by different names or to direct mail sent to a single account to multiple mailboxes. The following example illustrates how aliases are used to direct mail to a LAN with two local accounts: tod and stacia:

[aliases]
Tod.Sambar = tod
Stacia.Sambar = stacia
all = tod stacia
webmaster = stacia
support@microsoft.com = null


The last alias above demonstrates two "special" features. The first is the ability to alias complete mail addresses, and the second is the null mailbox. The null mailbox does not actually exist; any mail directed to this mailbox is quietly disgarded. So any mail sent to, aliased to, or forwarded to null is dropped by the server.

Wildcards
Mail aliases may contain the wild-card characters: star(*) and question-mark (?). The star (*) matches one or more characters and question-mark (?) matches a single character. So the alias: *help* = tod matches any mail addressed to a mailbox containing the string "help" and sends it to the tod account.

Wildcarding can be very powerful in terms of aliasing for users as well as aliasing for entire mail domains. For example, you can setup a mailbox for a user sales and then alias all mail to the domain buynow.com with the following alias:

[aliases]
*@buynow.com = sales


Important Mail aliases are (re)read for each mail message delivered to allow for dynamic modification of user aliases without restarting the server (a caching mechanism is used for efficiency).

The System Administration forms have a graphical interfaces for configuring mail aliases.

Forwarding accounts
The mail.ini file may contain mail forwarding accounts. Mail forwarding is useful when people leave an organization, are temporarily located at another site, or for sending mail to a group of people. The following example illustrates how mail forwarding is used at Sambar Technologies:

[forward] chuck = sambar@earthlink.net mirrors = niclas@skyweb.se sirjames@jalyn.com stacia

The System Administration forms have a graphical interfaces for configuring mail forwarding accounts.

Important Mail forward aliases are (re)read for each mail message delivered to allow for dynamic modification of user aliases without restarting the server (a caching mechanism is used for efficiency).

Port 25 Blocked
Many ISPs including Earthlink, MSN and Prodigy have recently blocked all outbound port 25 traffic in an attempt to prevent spam from being sent by people who gain access to the internet via their lines. With port 25 blocked, every attempt that is made to contact any e-mail server outside the ISP's own network failes without explanation.

If you are in this situation and must configure the Sambar Mail server to route outgoing mail via the ISPs SMTP server, you must set Use MTA in the [smtpd] section to false and configure the SMTP Server in the config.ini file to your ISPs SMTP Server.

Lastly, if your mail server is not accessible and your ISP does not appear to be blocking port 25, verify that the firewall that comes with Windows XP is not prohibiting access. By default, the Windows XP firewall will prevent access to your mail server if it is enabled.