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 then 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, then all relay requests are only carried out if they are specifically covered by a relaying rule.
So to adding relaying restrictions ...
- Add a forward_from_ip setting as it 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: Allow 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 works fine for medium sized servers but became inefficient on large servers if the window was set large, e.g. 1-2 days.
- smtp_auth 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 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 using the forward_user system as well then 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 that 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 and 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 messages filtering rules. An explantion of those rules is at the other end of the link
Banning
You can also straight out ban anyone from a particular IP address from connecting.
ban_ip: Specifies an IP address that 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 greater than 50% of users get hit, then 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 then they are likely to get more spam. The same is true for usernames that 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 then that might be a 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.
|