Mailtraq is one of the most sophisticated SMTP servers available.
The SMTP service provided by Mailtraq is the heart of your email system. It enables you to receive mail from the Internet - from other servers - and to accept mail from your local network and other authorized users for delivery.
Mailtraq is multi-threaded, with support for multiple CPUs and runs on all Windows systems from XP to W2008 Server. Mailtraq provides the power and flexibility you need, without the costs and difficulties that come with Microsoft Exchange or other alternatives.
For general guidance on setting up email systems see www.mailtraq.com/guide
Mailtraq's SMTP service installs automatically with a safe default configuration.
This Features section explains how to use the Advanced configuration options.
This dialog is accessed from the Service Manager in the Mailtraq Console.
The SMTP service performs two key roles:
- Accepting mail - both from local users and from the Internet.
- Rejecting mail that is unwanted.
Whilst this may seem straightforward, the efficient execution of these tasks in the midst of multiple attack vectors makes this one of the most demanding environments. Mailtraq has the power and multi level protection you need.
See a Flow Diagram of how the SMTP service analyses incoming mail.
Mailtraq Professional provides SSL/TLS support for SMTPS.
The SMTP service listens for incoming connections on port 25 (or any other specified ports), and having checked that it shouldn't be rejecting it (see below), sends the mail to Mailtraq's mail routers, which will either place it in local mailboxes, or send it out to remote recipients.
Typically mail coming from outside the local network, addressed to local users, will be received through an un-authenticated connection. This simply means that the sender doesn't have a username and password on this system.
Mail from local senders can also be un-authenticated. If the connection is coming from an IP address within the LAN it can normally be accepted, and safe to relay to external recipients.
If your users are connecting from outside the LAN (say from home), and they are not using a VPN, their IP address will be external, and Mailtraq would not normally allow them to send mail through the system to external recipients. To do so would make the system an Open Relay (see Mail Relaying below).
To allow your users to send external mail, without becoming an Open Relay, they need to authenticate. There are three methods supported by Mailtraq. The choice of method is normally determined by the options available in the client software. Whatever the method of authentication, the system requires the username and password of the individual Mailtraq users (as specified in the Options | Users dialog).
This is the most secure method of authentication, involving an encrypted password.
This works in the same way, but the passwords are sent in clear text.
This works by piggy-backing on the authentication performed by the POP3 service, whitelisting the IP address the POP3 collection was authenticated on, for a limited time.
Accepting mail is easy, but knowing when to reject it is more complex, yet just as important in maintaining an operational mail server.
Listed below are just some of the situations the Mailtraq SMTP service handles. Many of these are aimed at preventing attacks by spammers which, if permitted, could lead to your users being impersonated, inundated with unwanted mail, and even (in the case of open relaying) being disconnected from the Internet for violation of acceptable usage agreements.
It is critical that a mail server should not operate as an 'open relay'. Open relays are when mail servers accept mail that is not for them, and forward it on to the mail servers it should have been sent to. Whilst this may seem the neighborly thing to do, open relays allow spammers to hijack mail servers to send vast quantities of mail and are so 'polluting' that Internet Service Providers will disconnect companies whose mail servers act as open relays. By default Mailtraq will reject open relay attacks. Read more...
Spammers don't just send email to addresses they know, but also make up addresses on the off-chance that they exist. This may seem hard work, but with modern broadband connections (usually someone else's - inadvertantly running an open relay), and a dictionary of names, they can send messages to every imaginable address at your domain. Mailtraq detects and blocks dictionary attacks. Read more...
Unverifiable return paths
Mailtraq performs this check to see whether it is technically possible to reply to the inbound message. If the message claims to be from an address, but the domain name doesn't have DNS records enabling a message to be directed back in response, the message can be rejected. Read more...
The HELO parameter should relate to the domain the email is being sent from. If Mailtraq cannot resolve the HELO paramater the message is probably a forgery, and may be rejected. Read more...
HELO or From header claiming to be local
If Mailtraq receives a message with a HELO parameter or a From address claiming to be from your domain, but it is coming from a remote location, it is probably a forgery, and may be rejected.
Large message safety
Sometimes a denial of service attack may be made against the Mailtraq server by sending a very large message - which may be Gigabytes in size - hoping to fill up the hard disk or some other resource. Mailtraq can be configured to place a limit on the size of inbound mail. This is different from other size limits within the system, as when this limit is reached, the connection to the sending mailserver is immediately broken, preventing the system from being overwhelmed by the attack. The nature of the message is remembered, so if it is presented again (as would be expected when the connection is broken in this way), Mailtraq can then issue a permanent rejection message. Read more...
Mailtraq supports blacklisting messages based on various parameters:
- RCPT blacklist
- From blacklist
- HELO blacklist
- IP address blacklist
Whitelists take precendence over all other decisions, and allow mail to be accepted in specific cases even if rejection rules would otherwise deny it.
- RCPT whitelist
- From whitelist
- HELO whitelist
- IP address whitelist
Dynamic Blacklists (DBL)
Mailtraq can consult 3rd party databases to help decide whether to reject messages. Typically these databases contain lists of IP addresses used by spammers, but can also be used to tell which country the message is coming from (often mail administrators will reject all messages from countries that they don't do business with, and which have a poor spam control record)
Mailtraq can combine the results from several DBL databases, only rejecting messages if they agree beyond a certain threshold.
Mailtraq can place a copy of the rejected messages in a mailbox for review, so the effectiveness of the configuration can be monitored.
The SMTP service works in concert with Mailtraq's Bayesian anti-spam system (available in the Professional Edition). The Bayesian anti-spam system works by analysing the words in the message headers and body, and, based on earlier training, determines the likelihood that the message is spam.
When the Bayesian anti-spam system detects a message it wants to reject, it notifies the SMTP service immediately. This happens so quickly that the SMTP service is able to reject the message, and as far as the sender's email server is concerned, the message was never delivered. This is important, because, unlike other anti-spam system, it ensures that the sender knows the message was rejected, and reduces the bandwidth burden caused by separate rejection messages.
Should the Bayesian anti-spam system incorrectly reject a message, it important the sender knows this; otherwise they may assume the message was received (and later wonder why it was ignored by the recipient). The rejection notification ensures they know it was rejected, can give the sender a temporary email address that will bypass the Bayesian anti-spam system, however spam-like the message appears.
Mailtraq can be configured to Tarpitw rejected messages. Tarpitting is when Mailtraq deliberately responds in an extremely slow manner. Indeed, rather than immediately refusing the connection or refusing the recipients, they are accepted but delayed substantially. This does not add any load to Mailtraq, but prevents the client from delivering additional messages to other servers. After all the recipients have been listed, Mailtraq will still refuse the message. Tarpitting can help against denial of service attacks, and benefits not only your own mail server, but other mail servers being attacked by the same servers.
Data received before banner
Tarpitting is effective because it ties up the sending server as it has to remember where it is in its (long-running, but ultimately pointless) conversation with Mailtraq. Mailtraq on the other hand uses very little resources in this exercise, as the message will be junked anyway.
To counteract such techniques, spammers sometimes use a pipelining technique, where they don't hold a conversation following the SMTP protocol, waiting for Mailtraq to repond before sending the next piece of information, but instead send everything in one lump. Mailtraq detects this behavior, and immediately disconnects the sender.
Maximum Header Lines
A common characteristic of spam are large numbers of header lines. Mailtraq from 22.214.171.1248 caps the number of header lines at 150. You can adjust this number to suit your environment.
You will see something similar this error message in the log files if this condition is 'tripped'.
1/1/2008 11:59 PM Message header too large (160lines, limit 150): ... .. .
Sender Policy Framework (SPF)
Sender Policy Framework is a form of rejection based on the IP address the message is arriving from. Domain owners list the servers they use to send out mail, and Mailtraq can reject mail that purports to have come from their domain, but actually came from somewhere else. Read more...
[ ] Anonymous banner
An option is provided in the SMTP Service | Service-tab to remove the banner entry from the 220-HELO .
This is not recommended during set-up or testing as it is useful for confirming connections and routing in the Event Log or via remote Telnet sessions.
Mailtraq's default settings are set to the optimum for being generally accepting of messages. Administrators should apply any additional controls with care to avoid rejecting too many legitimate messages.
It is an unfortunate fact that many legitimate mail servers are not correctly configured - applying tests to messages that require correct configuration may lead to rejecting messages you would otherwise wish to receive.