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)

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.

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.

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. 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" arangement 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.