|
|
What can the Lotus SMTP MTA do to prevent SPAM?
From a member of Lotus' SMTP team:
The term 'SPAM' covers such a broad spectrum of SMTP mail 'attacks' that there is no easy solution to the prevention of 'SPAM'. The MTA provides rudimentary capabilities to deal with 2 types of 'attack'.
1. Relays
These are messages sent to your SMTP server from an outside source that are not destined for a local recipient, but are for another external SMTP address. This results in your SMTP server 'relaying' the message onto the external destination. Before the explosion of the Internet and the use of DNS to provide 1 hop source to destination routing of messages this was an acceptable practice on the Internet. Infact the original concepts relied on it to provide source to destination routing across many interconnected hosts. However the ability to accept and transfer 'Relay' messages brings 2 problems to the modern Internet SMTP host administrator. Firstly it results in the local organization incurring transfer costs to handle messages that have no relation to that organization. Secondly, as SMTP is in general an unauthenticated protocol, it became a mechanism for the distribution of 'SPAM' mail. A host that was available to relay mail could be used as the 'distribution' point for a broadcast/offensive 'SPAM' message. Often the message would be constructed to make it look like it originated from that host domain, making to original distributor virtually anonymous. As a result, most SMTP servers directly connected to the Internet are configured to provide some measure of protection to deny the ability to relay messages through them. The initial SMTPMTA option to prevent relays was provided as a quick 'band-aid' to a growing problem.
The MTA was designed to accept and support the concept of Relay messages. This was achieved by allowing the Inbound message converter to pass any message that is not destined for a local user to the Outbound Work Queue so that the Outbound Transport could route it out. The first 'band-aid' solution was an ini variable, SMTPMTA_REJECT_RELAYS=1. This ini variable switched off the Inbound Converters ability to perform relays. If the converter found a message that was supposed to be relayed, instead it would flag an error and place the message in state that the DRTask could generate a Non-Delivery report. This solution has a number of limitations:
It cannot distinguish relays from external originators that need to be blocked and messages from local POP/IMAP clients that need to be relayed.
Often the Originator address on a Spam relay message is bogus, so the NDRs often failed an ended up DEAD in either the Inbound or Outbound WQ's, which meant more work for the Administrator to have to monitor and clean up after.
The check only occurred after the entire message has been received, which results in the hosting server incurring the cost of reading in the message.
The check only looks for messages that were destined for the Outbound WQ from the Inbound WQ. There is a mechanism of addressing that can cause an MTA to deliver the message to mail.box, and the Router to deliver it back to smtp.box. This method of addressing circumvents this relay check, and is referred to in the internet as '% hack' addressing.
The MTA team had been aware of the potential of '% hack' addressing prior to the need to reject relays, and the MTA already had an .ini variable to handle messages that had an SMTP address that results in a Notes message that will be delivered back to SMTP. This is another 'band-aid' solution. It works, but there are drawback. The ini variable is SMTP_OCH_REJECT_SMTP_ORIGINATED_MESSAGES=1. When the MTA Inbound Converter creates a message in Mail.Box it writes a field called SMTPOriginator to hold the SMTP specific Originator information for NDR purposes. This .ini variable plays off of this functionality.
It causes the Outbound converter to reject any message in SMTP.BOX that has an SMTPOriginator field (i.e originally came from SMTP). This will block the '% hack' relay case in SMTP.BOX. The downside is due to the way Notes does NDRs. When Notes sends back an NDR for a failed delivery it does not send back a new message. It will send back the original message, with all the original fields, but it adds additional information. This means that Notes NDRs to incoming SMTP messages will have an SMTPOriginator field and will be blocked by this .ini variable.
To overcome most of the limitations of the Reject_Relays ini variable the MTA implemented a new mechanism to handle the denial of relays. This is controlled by the SMTPMTA_ALLOW_KNOWN_DOMAINS=1 .ini variable. This allows the MTA to refuse any message which is deemed to be a Relay during the inbound transport session rather than in the Inbound Converter. For each incoming connection, and each incoming recipient the MTA makes a determination regarding the nature of the Connection and the nature of the Recipient, each can either be 'External' or 'Internal'. An 'Internal' Connection can send messages to both 'Internal' and 'External' Recipients. An 'External' Connection can only send to 'Internal' recipients, 'External' recipients will be rejected. The MTA determines the states as follows. The MTA knows which Internet Domains it is responsible for, from the Internet Domain Suffix list in the Global Domain Document. The Inbound Sessions Handlers have access to this list of domains. When an incoming connection is received the Session Handler can obtain the IP address of the host that is connecting to it from the IP stack. The Session Handler then uses the DNS to resolve the IP address into a host name. Once it has got the host name, it compares it to the list of 'local' domains. If the connecting host is in one of the 'local' domains, then the Connection is deemed 'Internal'. If the host name is not in a 'local' domain, or the DNS was unavailable, or unable to provide a hostname, then the Connection is not to be trusted and is deemed 'External'. As the connecting host goes through the SMTP protocol exchange, the Inbound Session handler checks each recipient address against it's list of 'local' domains. If the recipient is for one of the local domains, then it is considered 'Internal', anything else is 'External'. Once both states are know the Inbound Session handler can decide if it will accept that recipient or reject that recipients. This mechanism solves the previous problems:
It has an ability to distinguish between external relays and internal POP/IMAP clients.
It does not need to accept the message content before decided whether it is a relay or not. This reduces the network traffic and means no NDRs to clean up for the Admin.
There are, however, still some potential limitations:
Because it uses DNS reverse lookups to 'validate' an incoming connection, if local POP/IMAP clients have IP addresses that are not in the local DNS, then they cannot be seen as 'Internal'
If the incoming connection is through some Proxy Servers, this may mask the true IP address of the connecting host from the MTA, so that the MTA always sees the incoming host being the Proxy Server. If the Proxy Servers IP address resolves to a local host name, then all incoming connections are considered 'Internal'
Because the Inbound Sessions handlers do not have access to the Router Routing tables, they cannot make a further determination as to whether a '%hack' type address to a local domain is truly an inbound message or a 'Relay'. As a result this option will not prevent inbound relays using a '%hack' address to a local domain, so the previous .ini variable may need to still be implemented to prevent these relays.
2. Attacks
Whilst a Relay is technically an attack, it is primarily an attack against another system, using the local SMTP host as an unwitting carrier. It is also possible that a connecting system may attempt to deliver a message to a local address that is considered an attack. This maybe in the nature of an offensive message, or perhaps an unwanted message. Oftentimes these messages are repeated over and over continually, resulting in a degradation of the local mail service.
These types of attack are harder to prevent ahead of time, as they often have no distinguishing features that separate them from ordinary acceptable messages. There are 2 possibilities to help combat them though.
The first is to attempt to authenticate the connecting host to determine that it is a 'real' SMTP host and not an Internet client attempting to attack the server. Until true Server-Server authentication using a PKI setup is available there are a couple of mechanisms. The MTA provides one of these, however its usefulness is somewhat in question. When a host connects to the MTA, it provides a HELO/EHLO command with it's own hostname as a parameter. Early on it was thought that this could be used to 'authenticate' the connection, as most 'SPAM' attacks used a bogus name at this point. A number of vendors including the MTA implemented a check of this parameter by taking the incoming IP address, looking it up in DNS to get a host name and comparing the result to the HELO parameter. If they did not match then the connecting host is not to be trusted. Over time it has become obvious that this check is only of little value as there is no requirement that Internet SMTP hosts have the necessary reverse lookup entry in DNS. As a result this type of check can reject connections from otherwise perfectly valid SMTP hosts. Each Admin needs to bear this in mind when considering to implement this option. It is enables via the SMTPMTA_HELO_DOMAIN_VERIFY=1 ini variable.
The second option is the provide a mechanism for admins to 'blacklist' connecting hosts/domains that have previously caused problems so that they cannot cause problems in the future. The MTA provides this via the SMTPMTA_Denied_Domains ini variable. This variable takes the path to a text file as a parameter. That text file should contain a list of hosts that the Admin wishes to refuse connections from, one per line. When this is enabled, the first Inbound Session Handler will take this list and perform DNS lookups to turn it into a list of IP addresses, which is then shared with all the other handlers. Each incoming connection is then compared to the 'blacklist' of IP addresses and the connection refused if there is a match.
As can be seen the MTA provides some basic measures for 'Anti-Spam' however it is by no means complete and Admins should look to R5 for a more complete implementation and ongoing mechanisms. Please check the Release Notes for exact details of all the .ini variables, including correct spelling and in what version they were first supported in.
You can also set up ASSP as an anti-spam proxy by following Andrew Pollack's Blog Entry.