SMTP Module

Use the WebAdmin Interface to configure the SMTP module. Open the Mail pages in the Settings realm, then open the SMTP pages.

Processing
Log Level: Crashes OnlyFailuresMajor & FailuresProblemsLow LevelAll Info			Channels: off12357101530501003005001000300010000other

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.

Channels

This setting (see above) limits the number of outgoing SMTP connections the module is allowed to open simultaneously.

Processing
Send Directly to Recipients		Default IP Address:	OS default[213.33.180.10][10.1.0.1][10.1.0.51][10.1.1.1][127.0.0.1]
Forward to
Channels/Host:	12345710152025other	Add Channels after:	10 sec15 sec20 sec30 sec40 sec60 sec90 sec2 min3 min5 min10 min20 min30 min60 min2 hour(s)3 hour(s)4 hour(s)5 hour(s)6 hour(s)7 hour(s)8 hour(s)10 hour(s)12 hour(s)
		or when Queue size is:	12351015203040501003001000other
Recipients/Message:	unlimited12345710301003001000300010000other		Hide 'Received' fields
			Always try 'EHLO'

Default IP Address

When CommuniGate Pro receives a message, it can assign one of its local network addresses to that message, and if the SMTP module needs to send such a message, it will send it via the assigned local address. See the Domains section for more details. All other messages are sent out via the Default SMTP IP Address. Set this setting to OS Default to let the server OS pick the proper local network address itself.

Recipients/Message

This setting specifies how many recipients can be sent with one message. If a message has too many recipients, the specified number of recipients is sent, then the message body is sent, and then the module repeats the sending procedure with the same message - for the remaining recipient addresses.

Hide Received Fields

If this option is selected, the SMTP module modifies all Received header fields in the messages it sends to non-client network addresses. Only the time stamp values are left in those fields, while all other field values are replaced with some dummy data.

Always use EHLO

If this option is selected, the SMTP module always sends the EHLO command to remote servers, trying to establish the extended SMTP (ESMTP) protocol.
If this option is not selected, the SMTP module checks the remote server greeting line. The SMTP module sends the EHLO command only if this line contains the ESMTP word.

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.

When the SMTP module sends a message from a Domain with an assigned IP address:

• the connection to the remote server can be made from the Domain IP address, see Domain Settings section
• the module sends the HELO/EHLO command using that Domain name. If this name does not resolve to the Network IP Address of this CommuniGate Pro Server, some receiving systems may reject SMTP connections coming from your Server.
  In this situation you can update the Domain Settings to specify an alternative name to use with the HELO/EHLO command.

When the SMTP module sends a message from a Domain without any assigned IP address:

• the connection to the remote server is made from the Default IP address
• the module sends the HELO/EHLO command using the Main Domain name. If this name does not resolve to the Network IP Address of this CommuniGate Pro Server, some receiving systems may reject SMTP connections coming from your Server.
  In this situation you can update the Default Domain Settings to specify an alternative name to use with the HELO/EHLO command.

Sending via a Forwarding Mail Server

Forward to

When this option is selected, the SMTP module connects to the specified Forwarding Mail Server (also called a smart host) and sends all queued messages to that server. Since the Forwarding Mail Server 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 Forwarding 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 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.

AUTH Name

The Forwarding Mail Server should be configured to enable relaying from your server to any other server on the Internet. Some Forwarding Mail Servers may require your server to use the AUTH command with a valid name and password parameters before transferring messages that need to be relayed. In this case you should enter the AUTH login name and password in the AUTH fields.

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.

Sending Messages Directly to Recipients

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 Forwarding 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.

Channels/Host

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

When the SMTP module cannot send a single message within this time period, and there are other messages in the same Queue, the module opens a new parallel connection.

when Queue size is

If the SMTP module is sending a message, and there number of unsent messages in the same Queue is equal or larger than the value of this setting, the module opens a new parallel connection.

Retrying Sending Attempts

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:

Retrying
Retry Every:	1 sec2 sec3 sec5 sec10 sec15 sec20 sec30 sec40 sec60 sec90 sec2 min3 min5 min10 min15 min20 min30 min45 min60 min2 hour(s)3 hour(s)4 hour(s)6 hour(s)8 hour(s)10 hour(s)12 hour(s)24 hour(s)2 day(s)3 day(s)4 day(s)7 day(s)other	for the first:	1 sec2 sec3 sec5 sec10 sec15 sec20 sec30 sec40 sec60 sec90 sec2 min3 min5 min10 min15 min20 min30 min45 min60 min2 hour(s)3 hour(s)4 hour(s)6 hour(s)8 hour(s)10 hour(s)12 hour(s)24 hour(s)2 day(s)3 day(s)4 day(s)7 day(s)other
then Every:	1 sec2 sec3 sec5 sec10 sec15 sec20 sec30 sec40 sec60 sec90 sec2 min3 min5 min10 min15 min20 min30 min45 min60 min2 hour(s)3 hour(s)4 hour(s)6 hour(s)8 hour(s)10 hour(s)12 hour(s)24 hour(s)2 day(s)3 day(s)4 day(s)7 day(s)other	for:	1 sec2 sec3 sec5 sec10 sec15 sec20 sec30 sec40 sec60 sec90 sec2 min3 min5 min10 min15 min20 min30 min45 min60 min2 hour(s)3 hour(s)4 hour(s)6 hour(s)8 hour(s)10 hour(s)12 hour(s)24 hour(s)2 day(s)3 day(s)4 day(s)7 day(s)other
Messages with empty 'Return-Path':		for:	1 sec2 sec3 sec5 sec10 sec15 sec20 sec30 sec40 sec60 sec90 sec2 min3 min5 min10 min15 min20 min30 min45 min60 min2 hour(s)3 hour(s)4 hour(s)6 hour(s)8 hour(s)10 hour(s)12 hour(s)24 hour(s)2 day(s)3 day(s)4 day(s)7 day(s)other
Delay Messages:	1 sec2 sec3 sec5 sec10 sec15 sec20 sec30 sec40 sec60 sec90 sec2 min3 min5 min10 min15 min20 min30 min45 min60 min2 hour(s)3 hour(s)4 hour(s)6 hour(s)8 hour(s)10 hour(s)12 hour(s)24 hour(s)2 day(s)3 day(s)4 day(s)7 day(s)other	Delay Recipients:	1 sec2 sec3 sec5 sec10 sec15 sec20 sec30 sec40 sec60 sec90 sec2 min3 min5 min10 min15 min20 min30 min45 min60 min2 hour(s)3 hour(s)4 hour(s)6 hour(s)8 hour(s)10 hour(s)12 hour(s)24 hour(s)2 day(s)3 day(s)4 day(s)7 day(s)other
Send Warnings after:			1 sec2 sec3 sec5 sec10 sec15 sec20 sec30 sec40 sec60 sec90 sec2 min3 min5 min10 min15 min20 min30 min45 min60 min2 hour(s)3 hour(s)4 hour(s)6 hour(s)8 hour(s)10 hour(s)12 hour(s)24 hour(s)2 day(s)3 day(s)4 day(s)7 day(s)other

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 Forwarding 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.

for the first .... then Retry

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.

for

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.

Messages with empty 'Return Paths': for

This setting specified the alternative Keep Trying value for messages with empty Return-Paths. These messages are used to report failed or successful delivery, and they can be discarded from the Queue after fewer attempts.

Delay Messages

When a receiving host returns a "temporary failure" (4xx) response for a message sending command (MAIL FROM, DATA, the "final dot"), this setting specifies when an attempt to send this message should be repeated.

Delay Recipient

When a receiving host returns a "temporary failure" (4xx) response for a message recipient command (RCPT TO), this setting specifies when an attempt to send the message to this recipient should be repeated.

Send Warnings After

Use these settings to tell the SMTP module when warning messages should be sent back to the message senders, notifying them about delivery delays.

Secure (encrypted) Message Relaying

You can configure your CommuniGate Pro Server SMTP module to use secure (encrypted) connections when sending messages to remote sites.

Send Encrypted (SSL/TLS)
	NeverWherever possible (low security)Always (high security)
TLS Version:	SSLv3TLSv1.0TLSv1.1TLSv1.2
TLS Client Certificate:	NoneSender Domain's or NoneSender or Main Domain's/select>

Never

Select this option if you want the SMTP module to send via an unencrypted channel.

Wherever possible (low security)

Select this option if you want the SMTP module to try to use SSL/TLS connections with remote SMTP servers that support this feature. If the remote server supports the STARTTLS command, the SMTP module tries to establish a secure (SSL/TLS) connection with that server.
The module does not check the remote server Certificate validity or the Certificate Subject in this case. If the STARTTLS command or secure connection negotiations fail, the server defaults back to plain-text communication and sends messages via an unencrypted channel.
Some servers advertise STARTTLS support, but fail to accept SSL/TLS connections. When this option is selected, it is impossible to send E-mail to those servers. To solve this problem, inform the broken server administrator, and create a Profile with the list of the exception hosts which uses the "Never" option.

Always (high security)

Select this option to enforce secure connections with the remote servers.

When the CommuniGate Pro SMTP module connects to a remote SMTP server, it checks if that server supports the STARTTLS protocol extension command. Then the SMTP module uses this command to initiate a secure connection with that server.

The CommuniGate Pro SMTP module checks the validity of the remote server Certificate using the specified set of the Trusted Certificates.
The remote server 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:

NoRelay:company.dom = company.dom@smtp.company.dom._via

See the Routing section for more details about SMTP routing.

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

• users submit messages to servers either using a private network, or using TLS/SSL connections over the public Internet (secure SMTP or secure WebMail);
• all mail servers and relays exchange messages either using a private network, or using TLS/SSL connections over the public Internet (secure SMTP);
• users read messages either using a private network, or using TLS/SSL connections over the public Internet (secure POP, IMAP, WebMail).

If 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 Mail Server, the CommuniGate Pro SMTP module does not check the Subject of the Forwarding Server certificate.

TLS Version

The highest version of TLS the SMTP module will try to use. If the connection fails due to TLS handshake problems and the "herever possible" flag is set, then for the every next attempt the version one step lower will be used. The final delivery attempt will be done without TLS.

TLS Client Certificate

A remote server may request that the sending server additionally authenticates by a certificate. If the remote server sends certificate request during handshake, it can be handled in three possible ways:

None

no client certificate is sent.

Sender Domain's or None

if a certificate matching the request is installed in the sending domain, it will be sent; no certificate is sent otherwise.

Sender or Main Domain's

if a certificate matching the request is installed in the sending domain, it will be sent; the certificate from the Main Domain is sent otherwise.

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.

Target Host Profiles

A Host Profile is an additional named set of the SMTP Module settings. You can have several profiles, for different sets of target hosts.

To create a new Profile, or edit an existing profile, use the WebAdmin Interface to open the Sending settings page of the SMTP module. The page lists names of all created Profiles.

Profiles
Big providers		Lame Hosts
our ISP
New Profile Name:

Enter the new Profile name and click the Create Profile button. A new Profile will be created.

Big providers
Comment:	Big providers. More channels, less delays.
Hosts:	*gmail.com,*yahoo.com

Each Profile has a list of domain names to whose hosts the Profile's settings are applied. The specified names can contain a wildcard - the asterisk (*) symbol. The settings of the SMTP Module are used as default values for the Profile's settings.

The Profiles are checked in the alphabetical order of their names. A domain may be listed in multiple profiles, but only the first matched profile will be used.

By using Profiles you can override the default SMTP module settings for particular target domain or group of domains. For example, you can assign a domain a dedicated Frowarding Server, with dedicated authentication parameters.

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 Receiving settings page.

Processing
Log Level: Crashes OnlyFailuresMajor & FailuresProblemsLow LevelAll Info	Listener				Channels: 0510255010025050010002500other

Channels

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.

Listener

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.

Processing
Verify:	Return-Path for:		nobodynon-clientsclientseverybody	HELO for:	nobodynon-clientsclientseverybody
	Check SPF records:		DisabledAdd HeaderEnabledwith DMARC	Reverse Connect:	DisabledAdd HeaderEnabled
Require:	STARTTLS for:		nobodynon-clientsclientseverybody

Verify HELO

This option specifies if the parameters of HELO/EHLO commands should be verified.
You can tell the module to verify these addresses only for the connections from network addresses not included into the Client IP Addresses list. 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).

Verify Return-Path

Return-Path E-mail addresses (sent using the MAIL FROM protocol commands) are processed with the Router. If the resulting address is routed to a remote host (a non-local domain name), this option specifies if the that domain name should be verified.
See the Protection section for more details.

Check SPF records

This option tells the SMTP module to verify non-local Return-Path domain names using the SPF DNS records.

• If this option is set to Disabled, the SPF records are not used.
• If this option is set to "Add Header", the SPF records are checked,
  and the Received-SPF header field with the SPF record processing result is added to all incoming messages.
• If this option is set to Enabled, the SPF records are checked.
  If these records say that messages with the specified Return-Path domain cannot be sent from the sender network (IP) address (the SPF records specify "hard failure" for that address), the Return-Path is rejected.
  In other cases, the Received-SPF header field is added to the message.
• If this option is set to "with DMARC", the SPF records are checked, Return-Path and message body are accepted;
  Then if the sender is not authenticated then domain in 'From:' address from the message header is checked; if the domain does not exist (no A nor MX DNS records) the message body is rejected.
  Then DMARC record for the domain is checked, if the record is not found then the record for the organizational domain is checked. If the DMARC policy is "reject" and SPF check result is not "pass" and the message has no DKIM signature which is valid and aligned to the domain, the message body is rejected.
  In other cases, the Received-SPF header field is added to the message.

Note: the SPF/DMARC records are not checked for SMTP connections from Client or White Hole network addresses.
Note: If the Verify Return-Path option is set to Nobody, this option is not used.

Reverse Connect

This option tells the SMTP module to verify non-local Return-Path addresses by connecting to the mail servers hosting those addresses and verifying that those servers accept the specified addresses.
If this option is set to Add Header, the addresses that cannot be verified are not rejected. Instead, the X-Reverse-Check header field containing the verification failure code is added to the message.
Note: Reverse Connect processing is not used for incoming SMTP connections from Client or White Hole network addresses.
Note: If the Verify Return-Path option is set to Nobody, this option is not used.

Require STARTTLS

This option is applied to messages with Return-Path addresses not belonging to any Domain created on this Server. If the SMTP connection is established from the specified address (Client, non-Client, etc.) and the connection is not secured using SSL/TLS encryption, the Return-Path and the message itself is rejected.
For messages with Return-Path addresses belonging to some Domain created on this Server, this functionality is controlled using the Domain Settings.

Sender Authentication

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: 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.

Blacklisting Offenders

To protect your system from known spammer sites, CommuniGate Pro provides several methods to maintain "black lists" of offending hosts IP addresses.

When a "blacklisted" host connects to your server and tries to submit a message via SMTP, it gets an error message from your SMTP module and mail from that host is not accepted.

Note: connections from "blacklisted" hosts are still accepted. If you want to reject all connections from the certain Network Addresses, see the Denied Addresses section.

Enter the addresses of offending hosts in the Blacklisted IP Addresses field in Address List format:

Blacklisted IP Addresses

10.34.56.78 ; bad host 10.34.50.01-10.34.59.99 ; bad network

Using DNS-based Blacklisting (RBL)

It is difficult to keep the Server "blacklist" current. So-called RBL (Real-time Blackhole List) services can be used to check if an IP address is known as a source of spam.

Some ISPs have their own RBL servers running, but any RBL server known to have a decent blacklist can be used with your CommuniGate Pro server. Consult with your provider about the best RBL server available.

To use RBL servers, select the Use Blacklisting DNS Servers option and enter the exact domain name (not  the IP address!) of the RBL server. Now, when the SMTP module accepts a connection from an IP address aa.bb.cc.dd, and this address is not listed in the Blacklisted, Unblacklistable, or Client Addresses lists, the module composes a fictitious domain name dd.cc.bb.aa.rbl-server-name where rbl-server-name is the domain name of the RBL server you have specified.

The SMTP module then tries to "resolve" this name into an IP address. If this operation succeeds and the retrieved IP address is in the 127.0.0.2-127.1.255.255 range, then the aa.bb.cc.dd address is considered to be blacklisted.

Note: this option results in an additional DNS (Domain Name System) operation and it can cause delays in incoming connection processing.

Use Blacklisting DNS Servers (RBLs)

You can specify several RBL Servers using the last (empty) field in the RBL Server table. To remove a server from the list, enter an empty string into its field. The more servers you use, the larger the incoming connection processing delay. If you really need to use several RBL servers, but do no want those additional delays, make your own DNS server retrieve the RBL information from those servers (using daily zone updates) and use your own DNS server as an RBL server.

Note: an RBL server failure can cause very long delays for incoming connections.

Limits and Protection

Limits
Message Limits:		Size:	Unlimited 0 Kbyte 1 Kbyte 3 Kbytes 10 Kbytes 30 Kbytes100 Kbytes300 Kbytes 1 Mbyte 3 Mbytes 10 Mbytes 30 Mbytes100 MbytesOther	Recipients:	unlimited1351025501002501000
Sender Limits:		Recipients:	Unlimited1351025501003001000300010000other	in:	5 seconds7 seconds10 seconds15 seconds30 secondsminute2 minutes3 minutes5 minutes10 minutes15 minutes30 minuteshour2 hours3 hours6 hours12 hoursday2 days3 days4 days5 daysweek
		Delay Prompt for:	0 seconds1 second2 second3 second5 seconds7 seconds10 seconds15 seconds30 secondsminute2 minutes3 minutes5 minutes10 minutes15 minutes
		Disconnect after:	135102025501002501000other errors and	Deny Access for:	disabled15 seconds30 secondsminute2 minutes3 minutes5 minutes10 minutes15 minutes30 minuteshour2 hours3 hours6 hours12 hoursday2 days3 days4 days5 daysweek

Message Size Limit

This setting tells the module to reject all incoming messages that are larger than the specified limit.

Message Recipients Limit

This setting limits the number of recipients for each incoming message. Specifying a lower value makes your server less attractive for spammers.

Sender Limits

Use this option to specify a time period and the limit on the number of message recipients. For each IP address the SMTP module counts all messages coming from that IP address, and all recipients specified for those messages. If the total number of all recipients specified during the set time period exceeds the set limit, new recipients are rejected with a temporary code, forcing the sending server to retry sending messages to those recipients later.
If a sender has completed a successful SMTP AUTH operation that allows the sender to relay via the CommuniGate Pro server, the recipients sent via that connection are not counted.
This setting can be used to protect your Server from spammers that send one message or a batch of messages to a large number of users of your system. On the other hand, if a large number of your users is subscribed to some mailing list, this option can cause delays for messages coming from that list.

Delay Prompt

Use this option to specify the delay time between the moment when an SMTP connection is accepted and the moment when the Server responds with an initial prompt. This delay can be used to force spam-sending programs to disconnect from your Server. Normal servers should still be able to transfer mail, as the RFC2821 standard requires them to wait 5 minutes for the initial prompt, and most servers do wait at least 3 minutes.
When this setting has a non-zero value, the Server checks if any data line has been received from the sender before the initial SMTP prompt is sent. If the sender has sent some data without waiting for an initial Server prompt, an error message is returned to the sender and the connection is closed.
The Prompt Delay is introduced only for connection made to the port 25.
Note: if you start to use long Prompt Delays, expect to see your Server using much more SMTP Input channels, as each SMTP transaction becomes longer.

Disconnect and Deny Access

Use this option to specify how many protocol errors the SMTP module should detect before it drops the connection with the sender. This feature protects your Server from spammers that try various E-mail addresses (dictionary attack), causing "unknown account" errors.
The SMTP module places the network addresses of disconnected senders into the Temporarily Blocked Addresses list. The SMTP module rejects new connections from the Temporarily Blocked Addresses.
Note: the module does not block a "failed sender" network address if that address is a Client IP Address (specified explicitly or via DNS) or if that address is a White Hole Address.

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.

Senders Address Profiles

A Senders Address Profile is an additional named set of the SMTP Module settings. You can have several profiles, for different sets of source IP Addresses.

To create a new Profile, or edit an existing profile, use the WebAdmin Interface to open the Receiving settings page of the SMTP module. The page lists names of all created Profiles.

Profiles
Clients		List Engine
our ISP
New Profile Name:

Enter the new Profile name and click the Create Profile button. A new Profile will be created.

Clients
Comment:	Our network. Less checks and restrictions.
Source IP Addresses:	127.0.0.1-127.0.0.254 10.0.0.0-10.0.255.255

Each Profile has a list of IP Addresses; the Profile's settings are applied to connections from those Addresses. The settings of the SMTP Module are used as default values for the Profile's settings.

The Profiles are checked in the alphabetical order of their names. An address may be listed in multiple profiles, but only the first matched profile will be used.

By using Profiles you can override the default SMTP module settings for particular source IPs. For example, you may allow some sending applications which can not authenticate to use your Server as open relay.

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

On-Demand Mail Relaying (ATRN/TURN)

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:

• Only one ATRN command parameter is allowed.
• The name of the domain queue to be released should match the name of the authenticated user. If you want to allow a dial-up client host to release the domain.dom queue, you should create the domain.dom Account in the CommuniGate Pro Main Domain, and the client host should authenticate itself using the domain.dom as the login name and the domain.dom Account password as the password.
• If the ATRN command does not have a parameter, the name of the authenticated user is used as the name of the queue to be released.
• The domain name used in the ATRN command must be included into the Hold Mail for Domains list.

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.

Waking up via E-mail

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.

Holding Mail in Queue

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.

ETRN/ATRN Processing
Accept Wakeups from:	nobodyclientsanybody
Hold Mail for Domains:	client1.com, client2.com, client3.com, client4.com, *.client4.com

Accept Wakeups

This option tells the SMTP module to accept ETRN commands and wake-up E-mail messages either from anybody, or only from the hosts included into the Client IP Addresses list, or from no host at all.
Since the ATRN command, unlike ETRN, requires authentication, the ATRN command is always accepted from any address.

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/ATRN 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/ATRN command.
The specified names can contain a wildcard - the asterisk (*) symbol.

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.

By default the relaying is allowed only for authenticated senders who have Relay option enabled in Services in the Account Settings page.

To allow relaying for applications which don't support authentication you should create a Profile for the IP Address of the workstation where the application is launched; and enable the "Trusted Source (Allowed Open Relaying)" option in the Profile.

When the Server is launched with --SMTPRelayToHostsWeBackup Command Line Option the SMTP module allows to relay messages to any domain, if the MX records for that domain includes this CommuniGate Pro Server name (its Main Domain name) as a back-up mail relay.

Relaying via Dedicated IP Addresses

You may want to send messages for some of your CommuniGate Pro Domains via Local IP Addresses assigned to those Domains. See the Domain Settings section for more details.

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).

Processing the Submit Port

You may want to enable SMTP receiving on the port 587. Sessions established to that port are processed differently:

• Connections are not rejected when the Reserved for Clients limit is reached.
• The AUTH capabilities are always advertised.
• Messages (the MAIL FROM commands) are accepted only after successful authentication.

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.

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:.

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

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.

Use the ._relay or ._via suffix with the port number: domain.port._relay. The SMTP module will not use the domain MX records in this case, it will try to resolve the domain name directly into an IP address. Sample Router record:
secret.communigate.ru = mail.communigate.ru.26._relay

The Monitors realm of the WebAdmin Interface allows Server Administrators to monitor the SMTP module activity. The SMTP Monitor section contains three pages - the Delivery (sending) page, the Waiting page, and the Receiving page.

The Delivery page displays the active outgoing SMTP connections:

ID	Target	Messages	Status	Running	Message	Size	Return-Path
158996	domain1.dom	1	opening connection	8sec	23458798
158997	domain2.dom	2	opening connection	2sec	58798234

ID

This field contains the numeric ID of the outgoing SMTP session. In the CommuniGate Pro Log, this session records are marked with the SMTP-nnnnn flag, where nnnnn is the session ID.

Target

This field contains the target Queue name (which normally matches the destination hostname).

Messages

This field contains the number of messages in the destination Queue.

Status

This field contains the operation in progress.

Running

If there is an SMTP operation in progress, this field contains the time since operation started.

Message, Size, Return-Path

If there is a message being sent to the destination host, these fields contain its ID, size and Return-Path, respectively.

The Receiving page displays the incoming SMTP connections:

ID	Source	Account	Status	Running	Size	Return-Path	Recipient
151	[192.168.0.104]:58312	user1@domain1.dom	reading recipients		28798	user1@domain1.dom	user2@domain1.dom
152	[10.0.0.104]:47531 (TLS)		checking return-path	2sec		xfs@company.com

ID

This field contains the numeric ID of the incoming SMTP session. In the CommuniGate Pro Log, this session records are marked with the SMTPI-nnnnn flag, where nnnnn is the session ID.

Source

This field contains the IP address the sender has connected from.
The (TLS) mark indicates that the SSL/TLS encryption is being used.

Account

This field contains the name of the client Account, if the sender had authenticated.

Status

This field contains the operation in progress.

Running

If there is an SMTP operation in progress, this field contains the time since operation started.

Size, Return-Path, Recipient

If there is a message being received, these fields contain its size, Return-Path or a recipient address, respectively.

If the sender had connected to port 587 (SMTP Submit), the connection row is displayed with a green background.

SMTP activity can be monitored using the CommuniGate Pro Statistic Elements.