E-mail |
|---|
| ||||||||
|
|
Version 5.2 |
||||||||||||||||||||||||||||||
|
|
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 @ symbol) 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 company.com should be sent to the computer mail.company.com, and mail to the domain enduser.com should be sent to the computer provider.com.
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.
Use the WebAdmin Interface to configure the SMTP module. Open the Mail pages in the Settings realm, then open the SMTP pages.
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 SMTPI tag for incoming connections, with the SMTP tag for outgoing connections, and with SMTPW tag for connections used to wake up the back-up server.
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.
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.
Select the Forward to option and specify the name or the IP address of the forwarding server. The SMTP module will forward all outgoing messages to that mail server for delivery.
Note: the name of the forwarding mail server should be the name of the real computer (as specified in an A-type DNS record), not a mail domain (MX-type) name. While your provider domain name can be provider.com, the name of the provider mail server can be something like mail.provider.com. Consult with your provider to get the exact name of the forwarding mail server you can use.
Note: you can specify the IP address of the forwarding server instead of its name. You can also specify several IP addresses, separated with the comma (,) symbol. If an SMTP connection to the first specified address cannot be established, the SMTP module will try the next specified address.
Note: when configuring a Cluster Backend Server, you can specify the asterisk (*) symbol in the Forward To setting. In this case, all Cluster Frontends (specified on the Cluster Settings page) will be used as the forwarding mail servers.
Note: when a recipient domain name is specified as an IP address (as in user@[12.34.56.78]), the SMTP module delivers messages directly to the host with the IP address 12.34.56.78, even if the Forward to option is selected. You may use this feature for message exchange between several mail servers on a LAN that does not have its own Domain Name Server.
This type of configuration is used when your server has a "dynamic IP address", and receives mail from the same forwarding server using the ATRN method. Usually the username and password used for mail forwarding are the same as the username and password used for ATRN receiving.
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 "forwarding mail server" performance.
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.
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.
If an attempt to deliver a message fails, the SMTP module can delay delivery of that message, or it can delay delivery of the entire host queue (if a connection with the host could not be established or an established connection was broken, etc). The Retrying panel allows you to control how the SMTP module makes attempts to deliver messages:
You can configure your CommuniGate Pro Server SMTP module to use secure (encrypted) connections when sending 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:
The specified names can contain a wildcard - the asterisk (*) symbol.
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. Then 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 using
the specified set of the Trusted Certificates.
The remote relay 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
relay1.company.dom, but the computer with the relay1.company.dom address
has the "main" DNS name smtp.company.dom and its Certificate is issued to that
name (its Certificate subject contains smtp.company.dom in the
cn field).
To solve this problem, you should explicitly route all traffic to the company.dom domain via the smtp.company.dom relay, using the following Router record:
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:If the domain is listed in the Send Secure To Domains list, and the receiving server does not support the STARTTLS command, or the remote server certificate cannot be validated, or the remote server certificate Subject does not match the domain or domain relay name, all messages to that domain are rejected, ensuring that no message is sent via a potentially insecure link.
If your server sends all outgoing mail via a forwarding server, you can enter the
asterisk (*) symbol into the Send Encrypted field to encrypt
all communications with the forwarding server.
The CommuniGate Pro SMTP module does not check the Subject of the forwarding server certificate.
If an outgoing connection is made to the port 465 (see Sending to Non-Standard Ports section), then the SMTP module initiates the secure (SSL/TLS) protocol immediately after establishing a TCP/IP connection.
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.
Click the Receiving link on any SMTP Settings page to open the SMTP Receving settings page.
Note:The CommuniGate Pro SMTP module never converts non-ASCII messages into the MIME form itself, and (according to RFC1652) it should not advertise the 8BITMIME capability. But the modern Internet is completely 8-bit transparent and clean, so it is safe to enable the Advertise 8BITMIME option, preventing other servers from doing unneeded 8bit-to-MIME message conversion.
If a message sender (the message Return-Path specified with the MAIL FROM protocol command) is a local Object - an Account, or a Group, or a Mailing List in a local Domain, that Domain is opened, and its SMTP Force AUTH option is checked.
If this option is enabled, the message will be rejected if the client mailer has not sent the SMTP AUTH command first.
The option value specifies for which sending mailer IP addresses this feature should be used.
Note: this option checks for the "fixed" Client IP Addresses only - it does
not pay attention to the "temp-client" addresses added with the Process as a Client Address feature.
Note: use this option carefully. Some users may use different mail relays
to submit their messages with their CommuniGate Pro Account names as the message Return-Paths.
If this option is enabled and those messages are directed to your Server, they will be rejected,
because mail relay servers are not able to authenticate the senders on your Server.
Note: most mailers will send the AUTH command only when the server advertises its SMTP AUTH capability. Make sure that your server does advertise it (see above).
When an incoming recipient address (RCPT TO) command addresses a local Account,
the Account Domain settings can instruct the SMTP Module
to check the current status of that Account.
If E-mail to the Account can not be delivered immediately (Account is over quota, etc.),
the recipient address is rejected with a "temporary failure" (4xx) response code.
If your Server has a dial-up link, its domain name 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.
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 provider.com, the name of the provider mail server can be something like mail.provider.com. 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.
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.
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 number in the Send Wakeups To setting field.
Use the colon symbol to separate the server name and the port number:
mail.provider.dom:366
You can use secure communications with the backup server if you include the backup server name into the Send Encrypted list.
When the backup server name is specified, the SMTP Settings page displays the Wake Up Now button. Click that button to initiate a wakeup session immediately.
The SMTP module implements the LMTP protocol. It supports this protocol on all its ports, and it is not required to configure additional ports just to support LMTP.
The SMTP module switches to the LMTP mode when it receives the LHLO LMTP command.
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.
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 client.com to mail.client.com in your Router Table, all mail to the client.com domain will be kept in the mail.client.com queue. Since the ETRN command parameter is processed with the Router, too, the ETRN client.com command will correctly release the mail.client.com queue.
In a Dynamic Cluster environment, the ETRN command received by any cluster member releases domain queues on all cluster members.
When the 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 established) 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.
For compatibility with legacy Microsoft Exchange servers, the TURN SMTP command is supported, too. It is processed in the same way as the ATRN command without a parameter, and it requires authentication, too. The name of the queue to release is the same as the name of the authenticated user.
The SMTP module supports an alternative wakeup method: a dial-up system can send any message to domainName-wakeup@serverDomain to release the domainName message queue. The serverDomain name should be the Main Domain name of the CommuniGate Pro Server.
In a Dynamic Cluster environment, the Wakeup E-mail received by any cluster member releases domain queues on all cluster members.
You can ask the SMTP module to hold mail for 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.
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.
If a message is to be delivered to the hostName host via a particular 12.34.56.78 Local IP Address, the message is not placed into the hostName SMTP queue. Instead, the Server places it into the @12.34.56.78|hostName SMTP queue.
This technique allows the Server to process messages from different Domains independently. If the IP Address of one of your Domains is blacklisted by remote hosts (because that Domain users have abused the mail system), messages to the same remote hosts from other Domains will not be delayed or rejected.
If the hostname name is included into the Hold Mail for Domains list, the Server never adds the @12.34.56.78| prefix, so all messages to that host are always enqueued into a single queue, and that queue can be used with the ATRN command.
The ETRN command releases not only the hostname queue, but all hostName queues with preferred IP prefixes (@12.34.56.78|hostName queues).
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.
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:.
| Router Table | |
|---|---|
| SMTP protocol |
C: MAIL FROM: user@host
S: 250 user@host sender accepted C: RCPT TO: somebody@somehost S: 591 Your host [10.1.1.1] is blacklisted. No mail will be accepted C: RCPT TO: abuse@somehost S: 591 Your host [10.1.1.1] is blacklisted. No mail will be accepted C: RCPT TO: blacklist-admin@somehost S: 591 Your host [10.1.1.1] is blacklisted. No mail will be accepted .... |
| Router Table |
<abuse*@blacklisted> = postmaster |
| SMTP protocol |
C: MAIL FROM: user@host
S: 250 user@host sender accepted C: RCPT TO: somebody@somehost S: 591 Your host [10.1.1.1] 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 .... |
| Router Table |
<blacklist-admin*@blacklisted> = postmaster |
| SMTP protocol |
C: MAIL FROM: user@host
S: 250 user@host sender accepted C: RCPT TO: somebody@somehost S: 591 Your host [10.1.1.1] is blacklisted. Send your questions to blacklist-admin@mycompany.com. C: RCPT TO: abuse@somehost S: 591 Your host [10.1.1.1] is blacklisted. Send your questions to blacklist-admin@mycompany.com. 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 addressed 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 [xx.yy.zz.tt]. 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 parts ending with the .smtp suffix. This suffix is processed in the same way as the .via suffix. The .smtp suffix is deprecated.
The SMTP module immediately accepts addresses that have domain parts ending with the .smtpq suffix. This suffix is processed in the same way as the .relay suffix. The .smtpq suffix is deprecated.
On the 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 are rerouted to the specified Forwarding Server domain.
Before accepting an address, the SMTP module checks if the address does not contain any @ symbol, but contains one or several % symbols. In this case, the rightmost % symbol is changed to the @ symbol.
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:The Monitors realm of the WebAdmin Interface allows Server Adminstrators to monitor the SMTP module activity. The SMTP Monitor page contains three frames - the sending frame, the waiting frame, and the receiving frame.
The Sending frame displays the active outgoing SMTP connections: