Tweaks and Tightening

The system already described in this article will drastically reduce the amount of spam and viruses getting to your e-mail server, and this section show you how to tighten down the hatches even further.

System Updates

If your system is running well, unless there are security updates for the specific components used you could do worse than leave it alone.

If you do want to keep it up to date, start an Online Update from within YaST and follow the prompts. You can also configure fully automatic updates within this application.

To upgrade any additional software such as DCC, Razor2 or Maia Mailguard, you will need to carefully read the upgrade notes and test the update before going live.

Stopping spam and viruses before they even get in

These settings are additional checks performed by the postfix SMTP connector, that are performed at different stages throughout the e-mail conversation it has with the outside world.

The file you will edit for this set of restrictions is /etc/sysconfig/postfix, which is the YaST template that creates the postfix configuration file /etc/postfix/main.cf

The set of restrictions listed here will follow a typical SMTP conversation, the first of which is the sender identifying itself.

Reject if the sender doesn't identify itself

The sender should identify itself using an EHLO or HELO command and if it doesn't then there's a good chance it's a poorly written virus or script. All commercial and well known free e-mail servers and clients will tell you who they are before sending you e-mail.

To deny any sender that doesn't identify itself, add the following line to the very end of the /etc/sysconfig/postfix file:

POSTFIX_ADD_SMTPD_HELO_REQUIRED="yes"

To test this change, save the file, in a terminal run SuSEconfig then postfix reload and try to start an SMTP conversation by running telnet mailscan 25

mail from: <[email protected]>

Right there you will see a 503 error, and the sender will get no further until the connection times out or it stops trying to send the e-mail.

All of the sender restrictions are also applied to internal senders, i.e. Your e-mail server, but don't worry, the next 'restriction' allows all internal e-mail out, even if it's not properly formatted.

Permit e-mail from trusted networks

This is implied if no sender restrictions are in place, but as you are about to put some in, you will need to implicitly make this statement.

It references a self-calculated list called mynetworks that contains "trusted" SMTP clients that have more privileges than strangers. Restrictions are tested in order and the first to match will be applied. If none match, 'allow' is implied.

It is required in order to allow relaying from hosts other than the gateway itself onto external domains, which if you point your current e-mail server to this gateway, it will need doing.

To make this change, which you must do else you won't be able to relay e-mail out of your network via this gateway, add the following line to the very end of the /etc/sysconfig/postfix file:

POSTFIX_ADD_SMTPD_SENDER_RESTRICTIONS="permit_mynetworks"

By default postfix will use the subnet of your gateway as a trusted subnet, so any other host on the same subnet will be "trusted". If your e-mail server is actually on another subnet, you will need to specify this explicitly.

If you do need to do this, add the following line to the very end of the /etc/sysconfig/postfix file: POSTFIX_ADD_MYNETWORKS="192.168.0.0/24"

where 192.168.0.0 is the subnet you want to trust, and /24 is the number of bits in the subnet mask (in this case that will be 255.255.255.0). To trust only a single host such as your internal e-mail server, change it to something like 192.168.0.100/32. If you want to trust multiple hosts and/or subnets, separate them with commas.

To test this change, save the file, in a terminal run SuSEconfig then postfix reload.

On a computer in an 'untrusted' network, start an SMTP conversation by running telnet mailscan 25

mail from: <[email protected]>

rcpt to: <[email protected]>

Substitute [email protected] for your own external e-mail address.

Right there you will see a 554 error, with postfix not willing to relay that e-mail. Now repeat the test from a computer on a 'trusted' network and it will work (as long as your MYNETWORKS statement is correct).

Reject non fully qualified sender's address

Have you ever received an e-mail from [email protected] when you know that Joe doesn't exist in your company? This is a simple trick some malicious programs play to try to gain your confidence in opening the e-mail or running an infected attachment. They send the e-mail as simply <joe> instead of <j [email protected]>. Your e-mail server will usually be default fill in the @company.com with your own company domain, thus appearing as a legitimate local e-mail.

To deny any sender that doesn't specify a full e-mail address in the MAIL FROM command, add the following line to the very end of the /etc/sysconfig/postfix file:

POSTFIX_ADD_SMTPD_SENDER_RESTRICTIONS="reject_non_fqdn_sender"

If you already have an option listed, separate them with whitepace meaning any space, tab or new line (enter) so it could look something like:

POSTFIX_ADD_SMTPD_SENDER_RESTRICTIONS=" permit_mynetworks rej ect_non_fqdn_sender"

To test this change, save the file, in a terminal run SuSEconfig then postfix reload and try to start an SMTP conversation by running telnet mailscan 25 mail from: <test> rcpt to: <[email protected]>

Substitute [email protected] for your own e-mail address. Right there you will see a 504 error, with postfix not accepting that user.

Reject from unknown sender domains

The assumption here is all incoming Internet e-mail should have originated from a real, existing Internet domain, so if postfix can't verify that the domain of the sender as specified in the MAIL FROM address exists, then reject the e-mail.

For this restriction, add the following line to the very end of the /etc/sysconfig/postfix file: POSTFIX_ADD_SMTPD_SENDER_RESTRICTIONS="reject_unknown_sender_domain"

If you already have the sender_restrictions line in your postfix file, just add additional parameters to it separated by commas and blank lines so that it looks like:

POSTFIX_ADD_SMTPD_SENDER_RESTRICTIONS=" permit_mynetworks rej ect_non_fqdn_sender rej ect_unknown_sender_domain"

To test this change, save the file, in a terminal run SuSEconfig then postfix reload and try to start an SMTP conversation by running telnet mailscan 25

mail from: <[email protected]>

rcpt to: <[email protected]>

Substitute [email protected] for your own e-mail address.

Right there you will see a 450 error, with postfix not accepting the sender's domain.

The next set of restrictions relates to the recipients. Permit e-mail from trusted networks

For the same reasons as the sender restrictions, allow anything from trusted hosts or networks to go through.

POSTFIX_ADD_SMTPD_RECIPIENT_RESTRICTIONS="permit_mynetworks"

Reject non fully qualified recipients addresses

All e-mail coming into your company should be destined to [email protected] and never to just user. Spammers can use this method to get around you trying to hide your domain name from the Internet. They simply connect to your e-mail server and start firing off e-mails to recipients without specifying your domain so they don't even have to know it!

To enforce that senders send e-mail to fully qualified e-mail addresses, add the following line to the very end of the /etc/sysconfig/postfix

POSTFIX_ADD_SMTPD_RECIPIENT_RESTRICTIONS="reject_non_fqdn_recipient"

Again if you already the first setting in place, separate the options with whitepace.

To test this change, save the file, in a terminal run SuSEconfig then postfix reload and try to start an SMTP conversation by running telnet mailscan 25

mail from: <[email protected]>

rcpt to: <stephen>

Substitute stephen for your own e-mail name (don't include the domain though). Right there you will see a 504 error, with postfix not accepting that recipient.

Reject unauthorised destination domains

This check confirms that the domain in the RCPT TO command matches your domain name. For this restriction, add the following line to the very end of the /etc/sysconfig/postfix POSTFIX_ADD_SMTPD_RECIPIENT_RESTRICTIONS="reject_unauth_destination"

To test this change, save the file, in a terminal run SuSEconfig then postfix reload and try to start an SMTP conversation by running telnet mailscan 25

mail from: <[email protected]>

rcpt to: <[email protected]>

Substitute the stephen part for your own e-mail name (don't include the domain though). Right there you will see a 554 error, with postfix not accepting the recipient domain.

Reject unverified recipients

This is a pearl of a setting, where postfix will probe your e-mail server to see if the recipient actually exists on your internal e-mail server, before accepting the e-mail from the sender.

This setting therefore prevents undeliverable junk mail from ever entering your e-mail system and wasting resources on processing the e-mail or generating bounce replies that end up sitting on the gateway for days.

Postfix does this by starting a normal SMTP conversation with your e-mail server, and assumes if it receives from your server a 250 OK response to the RCPT TO address, that the user exists. This probe is only performed once then the result is cached. If the recipient exists it will stay cached for 7 days before requiring a refresh. If the recipient does not exist that result will stay cached for 3 hours, so if someone was just trying to send a new starter some e-mail who didn't have an account yet, it wouldn't be long before the address was re-checked and any subsequent e-mails to that recipient would be allowed through.

For this restriction, add the following line to the very end of the /etc/sysconfig/postfix

POSTFIX_ADD_SMTPD_RECIPIENT_RESTRICTIONS="reject_unverified_recipient"

If you already have the recipient_restrictions line in your postfix file, just add additional parameters to it separated by commas and blank lines so that it looks like:

POSTFIX_ADD_SMTPD_RECIPIENT_RESTRICTIONS=" permit_mynetworks rej ect_non_fqdn_recipient rej ect_unauth_destination rej ect_unverified_recipient"

Also note that Postfix say this is only a good option for low traffic sites... but I believe their idea of low traffic is something like under several hundred thousand of messages per day, which I believe should be fine for most of you out there. Another thing to take heart at is if you did not do this check the gateway would attempt to send the e-mail onto your e-mail server anyway.

To test this change, save the file, in a terminal run SuSEconfig then postfix reload and try to start an SMTP conversation by running telnet mailscan 25

mail from: <[email protected]>

rcpt to: <[email protected]>

Substitute @retnet.co.uk for your own domain name (leave the username as it is, unless you actually have a user called that in which case change it to a user that doesn't exist).

Right there you will see a 450 error, with postfix not accepting the recipient's name.

Tighter control over attachment filtering

File attachment filtering is performed by Amavisd, and this is one area that Maia Mailguard only supports being enabled or not and what to do when they are caught.

If you want to change the types of files caught from the default set, then you will need to modify /etc/amavisd.conf

Scroll down to the $banned_filename section then edit to your heart's desire.

Be sure to re-start Amavisd by running /etc/init.d/amavis restart in a terminal console.

Blocking e-mail delivery to local users of the gateway

Because this is a gateway, no one should ever be trying to send e-mail to locally setup users on the box itself. By getting rid of local e-mail delivery to the gateway makes it harder to break.

In /etc/sysconfig/postfix add to the end of the file

POSTFIX_ADD_MYDESTINATION = "" POSTFIX_ADD_LOCAL_RECIPIENT_MAPS = ""

POSTFIX_ADD_LOCAL_TRANSPORT = error: local mail delivery is disabled

Save that file, now open /etc/postfix/master.cf and comment out the local delivery agent line, to look like #local unix - n n - - local

Save that file, close Gedit and in a terminal console run

SuSEconfig postfix reload

Setting a lower spam thershold

SpamAssassin has very good default settings, but still errs on the side of caution. Some specially crafted spam messages are designed to come in just under the default score of 5.000. After a few weeks I personally set mine set to 4.000 and have found this very reliable with not a single legitimate e-mail being caught yet, after it learned my initial e-mailing habits.

Because Maia doesn't automatically reject spam, but instead quarantines it, you can be safe in tweaking the spam catch score setting in Maia.

To do this, in Maia mailguard edit the options Consider mail 'Spam' when Score is >= and Quarantine Spam when Score is >= in your System Default domain ([email protected]), local domain and your own personal email account settings.

Remember in the current stable RC5 release of Maia Mailguard that the quarantine level will always be matched to the spam level. There is no distinction between these 2 values in this version.

BCC copies of e-mail to another address

Useful for security or HR/IT investigations, these options will add another address to the e-mail as a BCC so the original sender and recipient has no idea it's being done.

Edit /etc/sysconfig/postfix and add them like this:

# Send a copy of every e-mail generated to another address POSTFIX_ADD_ALWAYS_BCC = [email protected]

# Send a copy of every e-mail matching the sender

POSTFIX_ADD_SENDER_BCC_MAPS = 'hash:/etc/postfix/sender_bcc_maps'

# Send a copy of every e-mail matching the recipient

POSTFIX_ADD_RECIPIENT_BCC_MAPS = 'hash:/etc/postfix/recipient_bcc_maps'

The sender_bcc_maps and recipient bcc_maps use a lookup file to match an address then send to it's corresponding bcc'd address. Note that neither address needs to be on your local domain, so you can match an external sender or recipient address.

You will need to create the files yourself as they do not exist by default, and don't include the .db extension.

An example would be if you wanted to receive a copy of all e-mail sent from [email protected] . Create the file /etc/postfix/sender_bcc_maps and in it put something like:

# This lookup table is used to match sender addresses then send a bcc'd copy

# to a matching address.

[email protected] [email protected]

Once you've created the file, save it then run postmap /etc/postfix/sender_bcc_maps which will create a hashed index table version of the same file and give it a /db extension. Now edit /etc/postfix/master.cf and add the sender_bcc_maps option as described above To finish off, reload postfix with the new changes by running postfix reload

To read more about these or any other setting, visit http://www.postfix.org and search for those terms on the front page to find the relevant documentation.

Increasing scanning throughput

One way is to increase the number of scanning threads in amavisd-new.

To do this, increase the $max_servers setting in /etc/amavisd.conf and restart amavisd.

Also you will need to change the postfix maxproc setting in /etc/postfix/master.cf on the smtpd line that uses amavisd.

service type private

unpriv

chroot

wakeup

maxproc command + args

(yes)

(yes)

(yes)

(never)

(100)

smtp inet n - n - 2 smtpd -o content_filter=smtp:[127.0.0.1]:10024

smtp inet n - n - 2 smtpd -o content_filter=smtp:[127.0.0.1]:10024

In the above example, maxproc is set to 2. This setting tells postfix how many connections it can use to talk to amavisd. If the maxproc setting is smaller than the $max_servers setting in amavisd.conf you're just wasting resources as postfix will never send more than 2 e-mails at a time to amavisd and amavisd will always have many unused threads, so to maximise efficiency and performance, make sure both settings match.

After the change to master.cf, restart postfix with a postfix reload

Another option is to put the SpamAssassin Bayesian database and AutoWhiteList into a MySQL database instead of using the default Berkley DB format. The process is quite simple by following instructions on https://secure.renaissoft.com/maia/wiki/SpamAssassin3SQLBayes

A third, but slightly more risky option is to setup a RAM drive and mount it as the temporary storage area used by amavisd-new (/var/spool/amavis/tmp). Because there can be a lot of disk spooling going on, especially with 15 or more amavisd-new processes running, doing this on higher loaded sites can show a huge performance increase, but requires plenty of extra memory.

I've never set one of these up, so if you're interested hop on over to the SuSE support forums at http://support.novell.com/forums/ for some helpful advice.

Was this article helpful?

0 0

Post a comment