If the internal MTA is not enabled, a remote SMTP server must be configured in the config.ini (this should point to your ISP's SMTP server). If a remote SMTP server is not configured only mail destined for a locally configured user will be received (all other mail will be rejected).

Local mail is determined by using the Local Domains configuration entry of the [smtpd] section. When receiving mail, the SMTP server examines the destination address to determine if it is in the "local domain" of the mail server; so even if your ISP holds all mail for your domain (i.e. sambar.com), the Sambar SMTP server can be configured to route all local mail into the user mailboxes rather than sending to your ISP (and then fetching via the Fetcher).

With a Remote SMTP server configured, the mail server acts just like the SMTP proxy for remote mail with the following differences:

• Mail is first queued to a spool file on the Sambar Server. The message spool is specified by the Spool Directory configuration parameter. This directory acts as a staging post for messages. In the event of a server failure, all files in the spool directory are delivered when the server is restarted.
• Local mail is dispatched to the appropriate mailboxes by the router daemon.
• Delivery to the remote SMTP server can be delayed for delivery at specified intervals (i.e. never, on-demand, hourly or daily)
• If a connection to the Remote SMTP server fails, it will be retried every 10 minutes for a 2 day period. If the mail message is still not delivered after 2 days, the message will be moved to the failures folder and an error will be logged.

It is important to understand that the SMTPD component of the Mail Server need not be configured to run if you do not wish to use the local-mail delivery. If the SMTP proxy is configured instead, all mail is routed to your remote mailer (i.e. your ISPs mail server) where it is delivered. The Fetcher daemon will retrieve mail queued for local users from their respective ISP accounts. The advantage of using the Sambar SMTPD server is that local mail is not routed to your ISP, resulting in much quicker delivery.

MTA
The MTA uses DNS (domain name servers) MX-Records to get the address for each message recipient and then directly sends the mail message to the distination mail server(s). If mail cannot be delivered to all recipients, the mail message is moved to the mail/retry directory and retried every 4 hours for a 2 day period. If the mail message is still not delivered to all recipients after 2 days, a bounce message is returned to the sender.

Important! To use the Sambar Server MTA, the DNS Primary and DNS Secondary must be properly configured in the config.ini file. These entries indicate the DNS servers that should be used for MX-Record lookup. The System Administrator pages include an MTA / DNS Test utililty you can use to verify the MX lookup is functioning.

The DNS Server MX records can be overridden using a local mxhosts file to specify MX records. This can be useful for testing the mail server configuration.

The MTA uses the error codes from the remote SMTP server to determine if the mail message should be bounced from the user or retried. Specifically, 5yx error responses are bounced immediately. The following is from the SMTP specification idicating the meaning of SMTP errors:

The three digits of the reply each have a special significance. The first digit denotes whether the response is good, bad or incomplete. An unsophisticated sender-SMTP will be able to determine its next action (proceed as planned, redo, retrench, etc.) by simply examining this first digit. A sender-SMTP that wants to know approximately what kind of error occurred (e.g., mail system error, command syntax error) may examine the second digit, reserving the third digit for the finest gradation of information.

There are five values for the first digit of the reply code:

1yz Positive Preliminary reply

The command has been accepted, but the requested action is being held in abeyance, pending confirmation of the information in this reply. The sender-SMTP should send another command specifying whether to continue or abort the action. Note: SMTP does not have any commands that allow this type of reply, and so does not have the continue or abort commands.

2yz Positive Completion reply

The requested action has been successfully completed. A new request may be initiated.

3yz Positive Intermediate reply

The command has been accepted, but the requested action is being held in abeyance, pending receipt of further information. The sender-SMTP should send another command specifying this information. This reply is used in command sequence groups.

4yz Transient Negative Completion reply

The command was not accepted and the requested action did not occur. However, the error condition is temporary and the action may be requested again. The sender should return to the beginning of the command sequence (if any). It is difficult to assign a meaning to "transient" when two different sites (receiver- and sender- SMTPs) must agree on the interpretation. Each reply in this category might have a different time value, but the sender-SMTP is encouraged to try again. A rule of thumb to determine if a reply fits into the 4yz or the 5yz category (see below) is that replies are 4yz if they can be repeated without any change in command form or in properties of the sender or receiver. (E.g., the command is repeated identically and the receiver does not put up a new implementation.)

5yz Permanent Negative Completion reply

The command was not accepted and the requested action did not occur. The sender-SMTP is discouraged from repeating the exact request (in the same sequence). Even some "permanent" error conditions can be corrected, so the human user may want to direct the sender-SMTP to reinitiate the command sequence by direct action at some point in the future (e.g., after the spelling has been changed, or the user has altered the account status).

The second digit encodes responses in specific categories:

x0z Syntax -- These replies refer to syntax errors, syntactically correct commands that don't fit any functional category, and unimplemented or superfluous commands.

x1z Information -- These are replies to requests for information, such as status or help.

x2z Connections -- These are replies referring to the transmission channel.

x3z Unspecified as yet.

x4z Unspecified as yet.

x5z Mail system -- These replies indicate the status of the receiver mail system vis-a-vis the requested transfer or other mail system action.

The third digit gives a finer gradation of meaning in each category specified by the second digit. The list of replies illustrates this. Each reply text is recommended rather than mandatory, and may even change according to the command with which it is associated. On the other hand, the reply codes must strictly follow the specifications in this section. Receiver implementations should not invent new codes for slightly different situations from the ones described here, but rather adapt codes already defined.

For example, a command such as NOOP whose successful execution does not offer the sender-SMTP any new information will return a 250 reply. The response is 502 when the command requests an unimplemented non-site-specific action. A refinement of that is the 504 reply for a command that is implemented, but that requests an unimplemented parameter.

Unknown Mailbox
An Unknown Mailbox controls what the Sambar SMTP Server does when e-mail arrives for an account which does not have a mailbox (Note: This only applies to accounts local mail.) By default, if no Unknown Mailbox is configured, the mail sent by the client to a local mailbox that does not exist is rejected in real-time.

One of the commonest ways to handle "unknown" mail is to setup an auto-responder which returns a standard message to the sender indicating that they have used an incorrect address. The Sambar Server is able to reject such mail in real-time, eliminating the need for an auto-responder.

Plus (+) Addressing
If enabled, mail can be routed directly to a user's mail folder by appending the plus sign (+) and folder name to the recipient's email address. For example, mail to stacia+amazon@sambar.com will go directly into the user stacia's folder called amazon. If the folder amazon does not exist, the message will be rejected as if the user account did not exist. This feature can be effective when signing up for mailing lists, subscription sites or other services that you might wish to unsubscribe to easily later on (by simply deleting the folder).

The other option is to accept mail from the client and place the mail in a "special" mailbox for later review. To operate in this mode, create a mailbox, e.g. uknown, and configure the Uknown Mailbox as unknown.

Message Size Limits
The Maximum Message Size controls the size of incoming messages. By default, this is set to 5MB. By setting this parameter to zero (0), there is no limit to the size of mail messages. Note: When used as a forwarding mail server, the message size limit applies both to mail destined for local mailboxes as well as remote mail.

Features

• SMTPD can be configured to handle multiple domains (regular expressions can be used to for domain configuration, i.e. Local Domains = *sambar.com *sambar.net).
• Mail senders can be restricted to "local" mail users.
• Mail senders can be restricted by IP address.
• Unqualified addresses are accepted for local delivery (invalid local mailbox recipients results in real-time client notification).
• Remote mail can be queued for immediate or delayed (hourly or daily) delivery (local deliveries are always immediate).
• Individual mailbox size limitations are enforced.
• Maximum size of message can be specified.
• Simple mailing lists (mail alaises) are supported.
• A queue run can be manually started to delivery remote mail.
• Delivery failure messages can be customized.
• Mail forwarding for individual users.
• The maximum number of simultaneous incoming SMTP calls can be configured.

Anti-spam filters are planned for a future release, as are mailbox "folder" routing based on sender, subject or body content. SMTPD contains no header re-writing functionality and none is planned at this time. Lastly, VRFY, EXPN and ETRN are not supported, and presently, there are no plans to add this functionality.

Operation

When SMTPD receives a message, it writes the message to the Spool Directory along with expanded/verified RCPT lists and mail contents. The RCPT lists are designated as local or remote and updated upon successful delivery. Mail aliases and .forward handlers are evaluated as the RCPT commands are processed; in order to avoid loops, the recipient-expansion funcitonality ignores any addresses which have an identically-named ancestor that was processed previously. The maximum number of recipients (after alias expansion) defaults to 1000, but can be specified in the mail.ini configuration file.

Mail messages with more than 100 hops ("Received:" headers) are presumed to be undeliverable, and are placed directly in the Failures Directory; no attempt is made to notify to the sender of the message.

A message remains in the spool directory until it is completely delivered to its recipients or to an error address. If the message contains non-local addresses, it is passed to a SMTP-forwarding routine which uses the remote SMTP server configured in the config.ini for delivery. In the event that the remote STMP server cannot be contacted, the message is deferred for later delivery. After a failure, remote delivery is retried every 5 minutes if on-demand delivery is specified.

If one or more local addresses have full mailboxes, the sender is notified that the message could not be delivered to the adressee.

In cases when delivery cannot proceed (i.e. the message can't be delivered or returned to its sender), the message is moved to the Failures Directory for administrator intervention. Upon successful delivery of the message to all recipients, the spool file is removed from the machine.

When forwarding remote messages via the remote SMPT server, the message recipients are broken into blocks of at most 50 (RCPT) at one time. The remote SMTP server connection is kept open until all remote recipients of a message are delivered to; in fact, the remote SMTP connection is kept open until either all spooled messages are delivered, or 100 messages are transmitted (at which time the remote SMTP connection is terminated and a new connection is attempted). Local mail delivery is processed individually by appending the mail message onto the user's inbox.new mbox file which is appended to the inbox folder (inbox.fld) the next time mail is checked by the user.

In the event of a server restart, message in the spool directory are re-queued for delivery automatically. All message system failures and internal errors are logged to either the server.log or mail.log files in the log directory where the Sambar Server is installed.

The SMTP Server implements the SMTP protocol defined in RFCs 821 & 1123. The following SMTP commands are supported:

• AUTH LOGIN
• DATA
• EHLO
• HELO
• NOOP
• MAIL
• QUIT
• RCPT
• RSET

Authenticated SMTP

The SMTP Daemon supports a subset of the SMTP Service Extension for Authentication (RFC 2554). The extension allows the client to authenticate prior to sending messages. (Note: The AUTH=authinfo parameter is not added to the FROM line of outgoing email. AUTH support is only used for client verification.) Authenticated clients bypass the anti-spam restrictions used to limit unauthorized mail relay.

The Sambar Server supports the "AUTH LOGIN" extension which uses a base64 encoding of the username and password. Future releases will support stronger authentication methods. The following is a sample dialog between a client and server:

S: 220 Sambar ESMTP Server 4.4 ready
C: ehlo tsambar-pc
S: 250-www.sambar.com
S: 250-8BITMIME
S: 250-SIZE 100000
S: 250-AUTH LOGIN
S: 250-AUTH=LOGIN
C: auth login
S: 334 VXNlcm5hbWU6     base64 "Username:"
C: bXluYW1l             base64 "myname"
S: 334 UGFzc3dvcmQ6     base64 "Password:"
C: GFzc3dvcmQ6          base64 "secret"
S: 235 Authentication successful


SMTP Server & SMTP Proxy

If the SMTP Daemon is active, the SMTP proxy is not used. You can set the SMTP Proxy to true or false and it will have no effect because all SMTP traffic is routed to the SMTP daemon for delivery. (Note: Make sure SMTP remote delivery is enabled or mail to non-local accounts will get bounced with a 501 error message).

SMTP Issues
The Simple Mail Transport Protocol is designed to transfer e-mail quickly and efficiently, however, there are several issues you should be aware of:

• All e-mail is transferred in a plain text, so anyone could read the message you are sending (unless some form of encryption is used).
• Anyone can "fake" a message. The Sambar Mail Server contains only primitive reverse lookup functionality to prevent mail spoofing. This functionality will be enhanced in the future.
• Messages can be lost or duplicated. While the vast majority of messages sent are delivered, delivery of every message cannot be guaranteed.

Receiving mail via the Internet
By default, you will not be able to receive mail from users on the internet. If you'd like to put the SMTP server on the internet to receive mail, you will need access to the DNS Primary and DNS Secondary servers for your domain (and you need to have a registered domain name). There are DNS records called MX records which indicate what SMTP server to connect to for mail to a particular domain. Presently, your ISP has likely configured the MX record for your domain to their mail server. You would need to have your ISP setup this MX Record to point to your SMTP server. You also need to have your SMTP server running full-time or you risk losing mail.

The Sambar Server supports using MX records for outgoing mail (so the SMTP relay server can connect directly to remote SMTP servers). There is also minimal anti-relay and anti-spam functionality in the server.

Unless you are confident you can maintain a full-time mail server connected to the internet, I recommend using your ISPs mail server for incoming mail and configure the Mail Fetcher to load mail into your local accounts.

Relay Domains
In general, the SMTP server should be configured to not allow the receipt of mail for users without local mail accounts. However, it may be desirable to configure the server to accept mail for another mail server in a "peering" arrangement in case the other server is unavailable to receive mail. If the unavailable server has a peer that accepts mail for it via the Relay Domains directive and has MX records which identifies the peer as a backup server, i.e.:

IN MX 10 mail.jalyn.net
IN MX 20 mail.jalyn.com

mail destined for the unavailable server will be queued to the backup server until the unavailable server is back online.

Another important use for the Relay Domains parameter is to forward mail to the "primary" SMTP server when acting as a personal mail server. If a mail server is found in both the Local Domains and Relay Domains any mail messages for which a local mailbox could not be found is forwarded to the remote server which is assumed to be the primary SMTP server.

The Relay Domain Options parameter allows you to configure the server to accept only incoming and/or outgoing mail message which match the relay signature.

SMTP Security
There are several security mechanisms that should be used to prevent unauthorized use of the SMTP server by spammers. These include:

Require AUTH	The Require AUTH parameter requires that all users of the SMTP server authenticate prior to sending mail to users not identified as "local users". By default, this parameter is set to true. Not all mail clients support SMTP authentication, but if at all possible, you are strongly encouraged to leave this feature enabled.
Restrict Relay	The Require Relay parameter requires that, by default, all mail messages sent to the SMTP server be either From a local mail server user to To local mail server users. If disabled, your mail server will operate as an open relay. Unless you are behind a firewall, this parameter should never be disabled.
Restrict Relay IPs	The Restrict Relay IPs are a space separated list of IP addresses (wildcarding may be used), that are permitted to use the SMTP server as an open relay. Great care should be used before allowing any IP address to bypass the SMTP security provisions.
Relay Domains	The Relay Domains are a space separated list of mail server domains (wildcarding may be used) that the SMTP server will act as a relay for. This means that mail coming From one of these domains or To users in one of these domains will be accepted by the SMTP server and forwarded on.