SMTP Module

Data Files

The CommuniGate Pro SMTP module implements E-mail message transfer using the SMTP and ESMTP Internet protocols via TCP/IP networks.

The Simple Mail Transfer Protocol allows computers to transfer messages using network connections. A computer that has a message to send connects to the recipient's computer and establishes a network link. Then it sends one or several messages and closes the network connection.

Mailer applications (such as Eudora®, Netscape® mailer, and many others) use the SMTP protocol to submit messages to the mail servers, and mail servers then forward the submitted messages to the recipients. All mailers have a setting called SMTP Host Address that specifies the network address of the mail server computer. Mailer applications open connections to that address when they have a message to submit.

The CommuniGate Pro SMTP module supports the STARTTLS extension and can receive incoming mail via secure (encrypted) connections.

The CommuniGate Pro SMTP module supports the AUTH extension and allows remote users to authenticate themselves before submitting messages.

Simple Mail Transfer Protocol (SMTP) and DNS

The mail servers use the global Domain Name System to find the network address of the recipient computer or the recipient mail server. Each domain (part of the E-mail address after the @ sign) should have a special so-called MX-record in the Domain Name System. That record specifies the name of the computer that actually receives mail for that domain. For example, MX records can specify that mail for the domain should be sent to the computer, and mail to the domain should be sent to the computer

There can be several MX-records for one domain (with different priority values). If one (high-priority or primary) computer cannot receive mail, mail is sent to lower-priority computers (called Back-up Mail Servers). Back-up mailer servers then try to deliver the message to the primary server.

When the name of the recipient computer is retrieved from the DNS, the sending mail server consults the DNS again. Now it uses the DNS to convert the receiving mail server name into its network address. The so-called DNS A-records contain the pairs that link a computer name to its global Internet network (IP) address.

When the network address of the recipient mail server is received from the DNS, the sending mail server opens an SMTP connection to that server and transfers the message(s). When all messages to that domain are transferred, the connection is closed.

When a message contains several addresses within the same domain, the SMTP module can transfer only one copy of the message to the mail server serving that domain, and that server delivers messages to all recipients in that domain. But if there are too many addresses, the SMTP module can break them in several portions and send several copies, each containing only a portion of the address set.

If there are several messages to one domain, the SMTP module can open several connections to the mail server serving that domain and send those messages simultaneously.

If you want to receive messages from the Internet with your own mail server, you should register your domain name, and ask your provider to register that name with the Domain Name System. The DNS records should point to the computer running your mail server.

Configuring the SMTP module

To configure the SMTP module, use any Web browser to connect to the CommuniGate Pro Server, and open the SMTP section. To configure the SMTP module, you should have the Can Modify Settings access right.


Use the Log setting to specify what kind of information the SMTP module should put in the Server Log. Usually you should use the Major (message transfer reports) or Problems (message transfer and non-fatal errors) levels. But when you experience problems with the SMTP module, you may want to set the Log Level setting to Low-Level or All Info: in this case protocol-level or link-level details will be recorded in the System Log. When the problem is solved, set the Log Level setting to its regular value, otherwise your System Log files will grow in size very quickly.

The SMTP module records in the System Log are marked with the SMTP tag for incoming connections, with the SMTPO tag for outgoing connections, and with SMTPW tag for connections used to wake up the back-up server.

Sending Messages via the Internet

If you want to send messages over the Internet, your server should have a TCP/IP link to the Internet. When a message should be transferred to some remote host, the SMTP module connects to that host via the TCP/IP network, and it transfers the message using the SMTP protocol .

Sending Channels Limit:
Send Directly Forward Forwarding Server:
Retry Every: Keep Trying for:
then Every: After:
Channels/Host: Add Channel after:
Channels Limit
If you do not plan to use the Internet E-mail (a LAN-only, one-server configuration), set the number of Channels Limit to zero in the Sending Options field, and skip this Sending section.
If you do plan to send messages over the Internet, specify a non-zero value for the Channels Limit setting. This setting limits the number of SMTP connections the module is allowed to open simultaneously.

Retry Every
Use this setting to tell the SMTP module when it should retry to send a message if a connection fails. If you use a foreign mail server, this option specifies when the module should retry to connect to that server if the previous connection failed for any reason. If you use the Directly to Recipients method, and a connection to some remote host (domain) fails, all messages directed to that domain will be suspended for the specified time. Usually SMTP systems suspend messages for 30 minutes.

Keep Trying
Use this setting to limit the number of attempts to deliver a message. If a message cannot be delivered within the specified period of time, the message is rejected and an error report saying that the host is unavailable is sent back to the message sender.

then Retry ... After
Use these settings to tell the SMTP module when and how it should change the retry interval. Usually, you would tell the SMTP module to increase the retry interval to 1-2 hours after a message has spent more than 2 hours in the queue.

When sending messages over the Internet, the SMTP module can forward them to some other mail server, or it can deliver messages directly to the recipients, using the DNS MX-records to find the recipient hosts on the Internet.

Sending via a Foreign Mail Server

When this option is selected, the SMTP module connects to the specified "foreign" mail host and sends all queued messages to that host. Since the foreign mail server host is usually "close" to your server, messages leave your system quickly. But this method can cause additional delays in message delivery, since messages are queued on the foreign server and those queues can be processed slowly. This method is recommended when your server is connected to the Internet using a slow link, or when you use a dial-up link and you want messages to leave your server as soon as possible to keep the connection time short.
Select the Forward option and specify the name or the IP address of the "foreign" server. The SMTP module will forward all outgoing messages to that mail server for delivery.

Note: the name of the "foreign mail server" should be the name of the real computer (as specified in an A-type DNS record), not a mail domain name. While your provider domain name can be, the name of the provider mail server can be something like Consult with your provider to get the exact name of their mail server.

Note: when a recipient domain name is specified as an IP address, i.e. user@[], the SMTP module delivers messages directly to the host with the IP address, even if the Forward option is selected. You may want to use this feature for message exchange between several mail servers on a LAN that does not have its own Domain Name Server.

Sending Messages Directly to Recipients

When this option is selected, the SMTP module uses the DNS (Domain Name System) to convert message recipient addresses into the names and addresses of the receiving hosts. A receiving host can be the recipient host itself, or a relay host. The information about the proper relay host is stored in so-called MX records on Domain Name Servers. For each destination host several records can exist, each record having a priority value. If the SMTP module fails to connect to the relay host with the highest priority, other MX records are used and other relay hosts are tried. If no relay host is available, the message remains in the SMTP queue, and more attempts to deliver it (and all other messages to the same host) are made later.

This method allows the system to deliver a message either directly to the recipient computer or to a relay host that is "very close" to the recipient computer. Recipients can read your messages almost immediately, and your messaging system does not rely on any "foreign mail server" performance.

Multi-channel Delivery

When the Server queue contains several messages to be directed to the same domain, the SMTP module opens a connection to that domain mail server and sends messages one by one. If the established connection is slow and there is a large message in the Queue, other messages would wait too long before being delivered. You may want to allow the SMTP module to open additional connections to the same mail server and send other messages in parallel.

Use this setting to limit the number of TCP connection the SMTP module is allowed to establish with one domain mail server.
Add Channel after
Use this setting to specify the "reasonable wait" time period.

Additional connections to a domain mail server are opened if:

Sending via Dial-up Links

The SMTP module sending activity can be limited using the TCP Activity Schedule. Outgoing messages wait in the SMTP queue till the TCP Activity Schedule allows the Server to initiate outgoing network connections.

When outgoing activity is allowed, the SMTP module tries to send all submitted messages accumulated in its queue.

Receiving Messages

The SMTP protocol is used to receive messages from the Internet and from the client mailer applications. If you want to receive messages from the Internet, you need a TCP/IP link to the Internet, and your server domain name and the IP address should be included into the DNS records.

Receiving listenerChannels:
Message Limits: Size: Recipients:
Advertise AUTH capability to: 
Verify HELO and Return Paths for: 

Send Wakeups Every: to:
 Use ATRN login name: password:
Channels Limit
When you specify a non-zero value for this setting, the SMTP module creates a so-called "listener". The module starts to accept all SMTP connections that other mail servers establish in order to send mail to your Server. This setting is used to limit the number of simultaneous connections the SMTP module can accept. If there are too many incoming connections open, the module will reject new connections, and sending mail systems will retry later.

This link allows you to tune the SMTP Listener. You can specify which TCP ports to use for SMTP incoming connections (by default, the port 25 is used), which local IP addresses to use for incoming connections (all available addresses are used by default), and which remote addresses should be granted access to your CommuniGate Pro SMTP server (by default, all addresses can connect to the SMTP port).
Note: to allow Microsoft® Outlook Express 4.x users to submit messages using secure connections, you should configure the SMTP listener to accept connections on the TCP port 465, and enable the SSL/TLS option for that port.
Note: Netscape® Messenger and modern versions of Microsoft Outlook and Outlook Express products do not need any special port for secure communications, since these products use the STARTTLS command to initiate secure communications after establishing a regular, clear text SMTP connection to the standard port number 25.

Message Size Limit
This settings tells the module to reject all incoming messages that are larger than the specified limit.

Message Recipients Limit
This settings limits the number of message recipients the module can accept. Specifying a lower value makes your server less attractive for spammers.

Verify HELO and Return-Path
This options specifies if the parameters of HELO/EHLO commands and the Return-Path (MAIL FROM) addresses should be verified. You can set the module to verify these addresses only in the messages sent from hosts not included into the Client Hosts list. If Return-Paths are not verified, the domain names specified in the HELO/EHLO commands are not verified either. This is useful if:
  • many of your clients use mailers that send bogus names in the HELO/EHLO commands;
  • your Internet connection is a dial-up one, and you do not want any outgoing (DNS) traffic to be generated when receiving mail from your own client computers (Client Hosts).

See the Anti-Spam chapter for more details.

Advertise AUTH
If a server reports (in its initial EHLO prompt) that it supports SMTP Authentication, some mailer clients (including Netscape® Messenger 4.x) force users to authenticate themselves before sending messages. If you select the Non-Clients value, and a connection is accepted from an address included into the Client IP Addresses list, the SMTP module will not report that it supports the AUTH command. If the Nobody value is selected, the SMTP module never reports that it supports SMTP AUTH. This option does not disable the SMTP Authentication feature itself.

Waking up the Backup Server

If your Server has a dial-up link, its domain should have at least one additional DNS MX record, specifying a "back-up" mail server (usually, your ISP mail server). When your Server is off-line, all messages directed to your domain(s) are sent to that back-up mail server.

The back-up mail server tries to deliver collected messages to your server. Usually, the retry period is 30 minutes, so your system should stay on-line for at least that period of time in order to receive messages from the back-up server.

To avoid this delay, the SMTP module can be configured to send the Remote Queue Starting ("ETRN") command to the back-up server. When the back-up server receives that command, it immediately starts to send the collected messages to your Server.

Send Wakeups
Use these settings to specify the address of the Back-up Server, and to specify how often the Remote Queue Starting command should be sent.

Note: the name of the back-up server should be the name of the real computer (as specified in an A-type DNS record), not a mail domain name. While your provider domain name can be, the name of the provider mail server can be something like Consult with your provider to get the exact name of your back-up server, or just examine the DNS MX records for your domain: your back-up server is specified with the MX record that has the priority next to your own Server MX Record priority.

The SMTP module wake-up activity is limited with the TCP Activity Schedule.

On-demand Mail Relaying (ATRN)

The ETRN command can be used to release your domain queue on a remote backup server only if your server has a static IP address.

If your server has a dynamic IP address, the ETRN method does not work, since the backup server does not know the IP address your server is using, and the backup server is not able to open a connection to your server.

If your server uses a dynamic IP address, it should use the On-demand Mail Relaying method to retrieve mail from the backup server.

When On-demand Mail Relaying method is used, your server connects to the backup server, authenticates itself, and then it issues the ATRN command. Then the servers exchange their roles and the backup server starts to send your server your domain mail via the same channel. This eliminates a need for the backup server to open a connection to your server.

Since the backup server does not open a connection itself, it has to verify that the server that sends the ATRN command and wants to retrieve your domain mail is really your server. Your server should provide some name and password that should be accepted by the remote server and that should allow your server to issue the ATRN command.

Consult the remote server administrator to learn the name and the password your server should send before sending the ATRN command.

select this option to use the ATRN (On-demand Mail Relaying) method instead of the ETRN method.

login name and password
this pair of strings is sent to the remote server using the AUTH command. The access rights granted to this login name on the remote server should allow your server to use the ATRN command.

The CommuniGate Pro SMTP module uses the AUTH CRAM-MD5 authentication method to send passwords in an encrypted form. If the remote server does not support the CRAM-MD5 method, the clear-text AUTH LOGIN method is used.

If your backup server does not support On-demand Mail Relaying, you should use the Unified Domain-Wide Account method implemented with the RPOP module.

The RFC2645 suggests to use the special TCP port number 366 to provide the ATRN services. If your backup mail server provides the ATRN services on that port (or on any port other that the standard SMTP port 25), you should specify the port name in the Send Wakeups To setting field. Use the colon sign to separate the server name and the port number:

Serving Dial-up Client Hosts

The CommuniGate Pro Server can be used as a back-up mail server for dial-up systems. Dial-up systems receiving mail via SMTP expect their back-up servers to receive and keep all their messages when these systems are off-line. When a dial-up system connects to the Internet again, it connects to its back-up mail server and either issues the special Remote Queue Starting command (ETRN, RFC1985), or sends a dummy E-mail message to a special address on the back-up server.

Remote Queue Starting (ETRN)

When your server receives the ETRN command, it tries to send out all messages collected for the host specified as the ETRN command parameter. This method allows a dial-up system to get its messages immediately, instead of waiting for your server to make the next attempt to deliver the collected messages.

The SMTP module supports the ETRN command, so CommuniGate Pro can be used as a back-up mail server. No special setting is required, since this feature is always enabled.

The SMTP module uses the Router to process the ETRN parameter (domain name). It adds the wakeup fictitious user name to that domain to get a regular E-mail address wakeup@etrn-parameter and runs it through the Router. If the address is routed to an SMTP host, the SMTP module releases (wakes up) that host queue.

If you have routed the domain to in your Router Table, all mail to the domain will be kept in the queue. Since the ETRN command parameter is processed with the Router, too, the ETRN command will correctly release the queue.

On-Demand Mail Relaying (ATRN)

When the CommuniGatePro SMTP module receives the ATRN command, it checks that the connected party has authenticated itself. Then the module releases the specified domain queue and sends all its messages directly via this, already exatblished, connection. No special settings is required to enable the ATRN feature of the CommuniGate Pro SMTP module. There are some notes about the ATRN implementation:

The ATRN command parameter (if any) is processed in the same way the ETRN command parameter is processed.

The RFC2645 suggests to use the special TCP port number 366 to provide the ATRN services. CommuniGate Pro SMTP module provides the ATRN services on all ports its Listener is using. To comply with the RFC2645 standard, you may want to add the port 366 to the SMTP Listener settings.

Waking up via E-mail

The SMTP module supports an alternative wakeup method: a dial-up system can send any message to domain name-wakeup@serverdomain to release the domain name message queue. The servername should be the main domain name of the CommuniGate Pro Server.

Holding Mail in Queue

You can ask the SMTP module to hold mail to certain hosts in its queue, and not to try to deliver that mail until the receiving server issues the ETRN command or sends a wake-up E-mail. This can be useful if the receiving server is on a symmetric dial-on-demand line and its provider brings the link up automatically when there is any traffic for that receiving server.

Message Relaying

The situation when the SMTP module receives a message from a remote system and then sends that message to some other host is called relaying.

To avoid Server abuse, some relay restrictions can be specified.

Relay for Clients Only Relay to All Hosts We Backup
Release Queues for Clients Only  
Hold Mail for Domains:

Relay for Clients Only
See the Protection chapter for the information about this setting.

Relay to All Hosts We Backup
This option allows the SMTP module to relay messages to any domain, if the MX records for that domain includes this CommuniGate Pro Server (its main domain) as a back-up mail relay.

Release Queues for Clients Only
This option tells the SMTP module to accept ETRN commands and wake-up messages only from the hosts included into the Client Hosts list.

Hold Mail for Domains
When the SMTP module builds a queue for one of the domains (hosts) listed in this field, it immediately places that queue "on hold", waiting for the ETRN command or any other external action that releases that queue. This method should be used for the sites that receive mail via your server, and that want to receive it only when they issue the ETRN command.

Secure (encrypted) Message Relaying

You can configure your CommuniGate Pro Server SMTP module to use secure (encrypted) connections when relaying messages to certain remote sites. This feature is especially useful if your company has several offices and E-mail traffic between the offices is sent via the public Internet.

You should simply list the domain names that should receive mail from your server via secure connections:

Send Encrypted (SSL/TLS)
to Domains:

When the CommuniGate Pro SMTP module connects to a relay of one of the listed domains, it checks if that relay supports the STARTTLS protocol extension command. The SMTP module uses this command to initiate a secure connection with that relay.

The CommuniGate Pro SMTP module checks the validity of the remote relay Certificate. The Certificate subject must contain the cn (Common Name) field that matches either the domain name of the remote site, or the name of this relay. This can often cause a problem, since the domain company.dom may have the MX record, but the computer with the address has the "main" DNS name and its Certificate is issued to that name (its Certificate subject contains in the cn field).

To solve this problem, you can explicitly route all traffic to the company.dom domain via the relay, using the following Router record:

company.dom =

See the Routing section for more details about SMTP routing.

Note: this feature ensures that messages between your server and a remote relay are transferred securely. To provide complete end-to-end security, you should verify that:

Processing Mail from BlackListed Addresses

When a BlackListed host connects to the SMTP module, the module does not reject a connection. Instead, it receives the MAIL FROM SMTP command, and starts to process the recipient (RCPT TO) addresses sent from the blacklisted host. The module adds the domain blacklisted to each recipient address received from a blacklisted host, i.e. the received address user@domain is converted into user%domain@blacklisted. Then the address is processed with the Router as usual. If the Router Table does not contain special rules for the blacklisted domain, the address is rejected with a special error code.

The default Router Table contains the following line:
<blacklist-admin*@blacklisted> = postmaster
All messages from blacklisted hosts sent to the blacklist-admin address in any domain, are routed to the postmaster, so these messages are accepted. This "white hole" feature allows the blacklisted host users to contact the postmaster on your server if they want to discuss the blacklisting issue. If you remove this line from the Router Table, no address will be accepted from blacklisted hosts.

When rejecting addresses sent from blacklisted hosts, the SMTP module verifies if the blacklist-admin@blacklisted address can be routed with the Router. If the Router Table contains such records (a default one or a different one), the error code sent back to the blacklisted host explains that mail to blacklist-admin@serverdomain name is accepted even from that blacklisted site.

If you want to provide a "white hole" feature, but you do not want the information about the white-hole address to be included into the error code, simply use a different name for the "white hole" address.

For example:
<abuse*@blacklisted> = postmaster

The following table contains samples of SMTP sessions established from a blacklisted host. The host commands are marked with C:, the SMTP module responses are marked with S:.

C: MAIL FROM: user@host
S: 250 user@host sender accepted
C: RCPT TO: somebody@somehost
S: 591 Your host is in our Black List. No mail will be accepted
C: RCPT TO: abuse@somehost
S: 591 Your host is in our Black List. No mail will be accepted
C: RCPT TO: blacklist-admin@somehost
S: 591 Your host is in our Black List. No mail will be accepted
<abuse*@blacklisted> = postmaster
C: MAIL FROM: user@host
S: 250 user@host sender accepted
C: RCPT TO: somebody@somehost
S: 591 Your host is blacklisted. No mail will be accepted
C: RCPT TO: abuse@somehost
S: 250 abuse%somehost@blacklisted will leave Internet
C: RCPT TO: blacklist-admin@somehost
S: 591 Your host is blacklisted. No mail will be accepted
<blacklisted-admin*@blacklisted> = postmaster
C: MAIL FROM: user@host
S: 250 user@host sender accepted
C: RCPT TO: somebody@somehost
S: 591 Your host is blacklisted. Send your questions to
C: RCPT TO: abuse@somehost
S: 591 Your host is blacklisted. Send your questions to
C: RCPT TO: blacklist-admin@somehost
S: 250 blacklist-admin%somehost@blacklisted will leave Internet


The SMTP module immediately (on the first Router call) accepts messages addresses to domain name-wakeup local addresses. When these messages are enqueued into the SMTP module queue, they are processed as wake-up requests for the domain name domain message queue.

The SMTP module also immediately accepts all addresses with IP-address domains, i.e. with domain names like []. Please note that the Router adds brackets to the IP-address domain names that do not have them, and the Router changes the IP addresses of local domains to those domain names. The Router performs these operations before calling the modules.

The SMTP module immediately accepts addresses that have domain names ending with .smtp . The .smtp suffix is removed, the domain name is used as the target host name, and the address "local part" is used as the envelope address to pass to that host.

Sample 1:
The Server main domain is
Mail for the domain should be sent to a separate server via SMTP, while mail to all other subdomains of should be processed as mail addresses to the main domain, i.e. should be the same as
You can specify this routing as: = ; explicitly direct to SMTP
*     =            ; all other subdomains are rerouted
You can also specify this routing using IP addresses (depreciated): = []            ; explicitly direct to the IP address via SMTP
*     =            ; all other subdomains are rerouted
Sample 2:
All mail to the domains, client2, and should be sent to the site
You can specify this routing as: = = =
or, in a more flexible way: = = =
relay =

Note: You can specify just instead of here (given there is no other router record for the, but in this case mail to will be sent to the as By specifying the .smtp suffix you not only tell the SMTP module to accept an address immediately, but you also force the SMTP module to send only the "local part" of the address to the remote host.
Without .smtp suffix
user @ client1.hostRouter converts @ relay @ relayRouter converts @ @ host.comRouter stopsno rule for @ host.comSMTP acceptsfor
With .smtp suffix
user @ client1.hostRouter converts @ relay @ relayRouter converts @ @ acceptsfor

On a final call, the SMTP module accepts mail to any domain if that domain name contains at least one dot (.) symbol. If the Forward option is selected, all these addresses (except those with IP-address domains) are rerouted to the specified Forwarding Server domain before the addresses are accepted.

Before accepting an address, the SMTP module checks if the address does not contain a '@' sign, but contains one or several '%' signs. In this case, the rightmost '%' sign is changed to the '@' sign.

Sending to Non-Standard Ports

Some mail servers can be configured to receive incoming SMTP mail on a non-standard port. The CommuniGate Pro SMTP module can send messages to those servers, if the domain part of an E-mail address contains the port number or is routed to an address that includes the port number.

There are two methods to include the port number into an E-mail domain:

CommuniGate® Pro Guide. Copyright © 1998-2000, Stalker Software, Inc.