DMail Anti-Spam features DMail has a host of features for blocking spam. Most importantly, a mail server should have Relaying Restrictions imposed on it. Note: The default behaviour for DSMTP is not to restrict relaying. Relaying is where a message comes in for a non-local user, i.e. a user on a domain that is not covered by a vdomain setting, and DSMTP tries to deliver the message to the SMTP server where that user is local. So it has to do a DNS MX lookup on the destination domain, open a connection to that SMTP server and try to give it the user's message. If that SMTP server does not accept the message then DSMTP will bounce the message. Note that if that SMTP server allows relaying from DSMTP then it will also accept that message and try to send it to the end destination. Given that you have secured your box against unauthorised relaying, most SPAM is to local users. With the settings below, you can restrict spamming on your system. You can place Volume Restrictions on the amount of mail that one user receives, or the number of recipients for the message. Another way of stopping spam is to add message filtering such that if a message does not apply to a general set of rules it will be rejected. Given that you know who is spamming your server, you can set up rules to ban connections from certain sources. Relaying Restrictions By default, DSMTP will allow all relaying, but as soon as you put one relaying rule in dmail.conf, all relay requests are only carried out if they are specifically covered by a relaying rule. So, to add relaying restrictions ... Add a forward_from_ip setting, as this is the best defense against being an Open Relay. forward_from_ip: Allows relaying only from a subset of IP numbers. This is matched against the sender's IP address. (In versions 2.7q and above, DMSetup will add a forward_from_ip setting for your local subnet so that your default setup will not be an open relay.) Then add to the forward_from_ip setting other settings to provide exceptions for relaying. Use the following commands for relaying exceptions: (detailed setting descriptions can be found in the Reference Section at the end of the links) forward_from: Allows relaying by users sending from a specifed domain. NB: Creates a relaying hole for spammers pretending to be from the specified domain (which is easy to do). If you have this setting for your main domain then Open Relay Databases like ORBS will almost certainly add you to their 'bad servers' list! relay_to: Permits exceptions to forward_from_ip for certain domains. This is matched against the domain given in the envelope's RCPT line. forward_user: Permits exceptions to forward_from_ip for recent POP users - often called a 'POP before SMTP' system. This allows users to relay mail for the default period of 2 minutes after checking for mail. You can increase this period with the setting, forward_window. NB: this handling of this system was improved greatly in version 2.8m. Before 2.8m it worked fine for medium sized servers but became inefficient on large servers if the window was set large, e.g. 1-2 days. auth_allow relay: New in 2.8n! Allows the login of users to the SMTP server. Once authenticated, the 'trusted' user can be allowed to relay using this setting. DSMTP supports the SMTP AUTH command when this setting is added. This allows the user to turn SMTP AUTH on in their email client. SMTP AUTH means that the email client will provide the username and password (same as on POP server) to authenticate on your SMTP server when connecting to send out mail. NB: adding this setting will mean that some email clients, like Netscape Mail, will force the users to turn on SMTP AUTH. Generally this is not a problem, as Netscape Mail instructs them on how to do it, but it may be confusing to some users. If you are using the forward_user system as well, you should probably set the setting hide_auth recentpop so that unnecessary auth lookups are not done. DSMTP will log the following lines when it allows relaying because of a setting above, Because of SMTP AUTH: Command RCPT OK (authenticated channel) Because of a relay_to setting: Command RCPT OK (relay_to allowed) Because of a forward_from setting: Command RCPT OK (forward_from allowed) Because of a 'recent pop connection', i.e. forward_user, (x.x.x.x) is recent Because of any other setting like forward_from_ip Command RCPT OK (relaying allowed) Volume Restrictions DMail also allows restrictions to be placed on the volume of messages coming from a particular IP number going through DSMTP per hour. fromip_max: Restricts the number of messages per hour which DSMTP will accept from an IP number. fromip_nolimit: Permits exceptions to from_ip_max for certain IP numbers. This applies to the IP number of the sender. max_rcpts: This sets how many recipients can be sent in a single message before it is rejected. tarpit_start: This basically starts slowing down responses by DSMTP once x recipients have been reached for the session. Each new recipient will get a slower response. tarpit_except: This allows certain ip address to be exempt from tarpitting. Message Filtering Message filtering is also available, though it should be used with care. DMail doesn't do logic checks of them so it may be possible to accidently reject everything (!). msg_filter: Gives a filename containing message filtering rules. An explantion of those rules is at the other end of the link DMail's Mfilter system This is a far more complex method of filtering and allows regular expressions etc, examples are included. This also allows a "scoring" system in which you can score emails based on their contents and then add headers letting customers know the likely hood that it is spam. Banning You can also straight out ban anyone from a particular IP address from connecting. ban_ip: Specifies an IP address which DSMTP may not talk to. ban_mailfrom: This allows you to ban by the "mail from" header, and is a pattern match. So if you wanted to ban bob@aol.com ban_mailfrom bob@aol.com or all aol users ban_mailfrom *@aol.com ban_rcptto: This allows you to ban by the recipient it is pattern matching like ban_mailfrom.   Thinking about SPAM ... If your site gets spammed and, say, more than 50% of users get hit, you really have to ask yourself, 'Where did the spammer get their list of names?' Here are some things that spring to our minds ... Through VRFY?: We don't think that it is common for spammers to use the SMTP vrfy command to check if usernames exist on your server. There does not seem to be a gain to doing this over simply sending a recipient line which is less work. The spammer can do a mail out and then build up a list from the successful posts on that mail out. From Public Posting?: Certainly it is true that if your users post to public sites like News Groups or Mailing Lists, they are likely to get more spam. The same is true for usernames which are common, e.g. we should all have pity on people called, Joe, Bob or Fred :-) From your Mailing Lists?: If you have not restricted access to the 'who' command on your mailing lists, that might be the way that a spammer has obtained lists of your users. Your user database has been obtained?: The possibility of this happening certainly can not be ignored if you have a large unexplained posting. Any suggestions?: If you have suggestions for anti-spam features then we will be glad to hear them.