Setting your default address in cPanel – why its better to use :fail: instead of :blackhole:

Posted on November 11, 2007
Filed Under Configuring Email in cPanel, cPanel Web Hosting, Exim mail server, Mail Server administration | Leave a Comment

What does using :fail: no such address here for default address do?

This setting bounces unrouted email back to the sending address without it being processed by our mail server. This is better than :blackhole: because using the blackhole setting causes the mail server to accept and process the email before sending it to null. Fail on the other hand causes the email to be rejected (bounced) before it is accepted by the mail server. This prevents abuse of resources. This is also useful for other mail servers because it lets them know (from the bounced email) that the emails being sent are to non-existent addresses and the mail server administrators can then more easily detect and prevent abuse of their own services by spammers.

Why bounce unrouted email? Why not just accept it?

Experience will show you over time that unrouted mail is the preferred method of spamming. And the same experience will show you that spam is sent in great numbers, absolutely millions of spam emails are sent around the Internet daily. Spammers also use software to automatically generate random email addresses to single domains in large numbers.

Accepting unrouted email is the friend of spammers since they don’t have to guess or know what email accounts you have set up, they can send spam to any address for your domain and it will be accepted and delivered to whatever address you set as the default address.

Rejecting unrouted email is the enemy of spammers since they can send spam to any address at your domain but it will not be accepted unless they match an email address that exists (i.e. one that you have created in your control panel).

What alternatives are there for dealing with unrouted email?

You can use Forwarders to handle mail sent to non-existent email addresses. For instance, if you wanted to accept mail for user @ when you have not set up a mail account in that name, you can create a forwarder for that address to send the mail on to an address that does exist (and that does not have to be a mail address in your hosting account, it could be a mail address at your ISP for instance). This method maintains protection against unrouted spam email and still allows you to accept mail to certain addresses for which you do not want to create a separate account for.

A huge word of caution though, whatever address you set as the default address should really have a quota limit set as substantial amounts of spam can fill your quota. Filling your quota (where you have left the default address with an unlimited quota for instance) will stop your hosting from working because you … literally have no space left.

Mail server attack

Posted on November 11, 2007
Filed Under Exim mail server, Mail Server administration | Leave a Comment

Stopping an attack on Exim

Attacks on mail servers are pretty common and can lead to mail server outages and even entire server outages.

Common types of attack

There are two common forms of attack …

Dictionary attack

Email sent to non-existent addresses consisting of random strings of letters representing the usernames (such as dkfjg @ or abcdef @ This is a very common form of spamming and often you can include email sent to random names generated by the spamming software employed to conduct such attacks.

To reduce the impact and deplete these attacks you must follow the methods detailed in Section 1 below.

Spoofing attack

This is where someone spoofs one of your client accounts’ email addresses and sends thousands of spam messages around the net, masses get rejected by recipient mail servers which employ good anti-spam solutions and the rejects get sent to the spoofed address (often a non-existent address, but sometimes an existing mail account).

To reduce the impact and deplete these attacks, you would have to at least set a low mail box quota (let’s say a max of 100mb) to prevent complete flooding. Then ensure that Exim is configured to reject any mail at SMTP time that is sent to a full mailbox, because this mail box is certain to completely fill with the high amount of bounces that this attack produces. If you have the benefit of cPanel and WHM then you can make this setting by entering the Exim Configuration Editor (Service Configuration > Exim Configuration Editor in the left hand pane of WHM) and check the box marked …

Reject email at SMTP time for users who have exceeded their quota rather than keeping it in the queue. This is probably a good idea, but it does mean people will lose mail so its not on by default.

Click the save button and Exim will be reconfigured and restarted for the change to take effect**. Now follow the instructions in Section 1 to handle the attack.

**The setting needed in Exim (if you don’t have the benefit of WHM’s Exim Configuration Editor) is as follows …

driver = redirect
condition = "${perl{checkuserquota}{$domain}{$local_part}{$message_size}}"
user = "${lookup{$domain}lsearch* {/etc/userdomains}{$value}}"
domains = lsearch;/etc/userdomains
data = :fail:Mailbox quota exceeded

… which should be added at the beginning of the section called DIRECTORS CONFIGURATION.

The alternative is to delete the mail account until the rejects subside, so that such mail would be sent to the default/catchall address. You can then follow the instructions in Section 1 to handle the attack.

Section 1

If you’re undergoing a mail attack – the attacks that can be deterred by setting an appropriate catchall (default) address setting

In such circumstances where substantial amounts of email are targeting non-existent addresses it is obviously preferable to set the catchall (default) address to :fail: as this causes the MTA (mail transfer agent – usually Exim) to reject the email at SMTP time – this means that the mail server will refuse to accept and process the email. Many users set the catchall/default address to :blackhole: but the MTA will handle this by accepting the message and then deleting it and this uses resources to do so, whereas using :fail: will not use such resources. Other users set the default/catchall address to another email address, either in their account or a remote address but either also uses resources.

So, if you are under such an attack it is obviously preferable to change the default/catchall addresses very quickly to preserve resources and prevent your MTA from going down.

Check if any users are using anything other than :fail: for default/catchall address

To be sure that you need to make any changes its best to see if anyone is using anything other than the desired :fail: setting. You can find this out by running this command in SSH …

grep ‘*:’ /etc/valiases/* | egrep -v ‘:fail:’

… if you see no results then all accounts are using :fail: but otherwise you will see a list of all domains which use :blackhole: or have an address set for the default/catchall setting.

Backup all valiases files

You can change all settings to :fail: that do not have it already set, but maybe it would be a good idea to backup the valiases before doing so, so that you can return the settings when the attack subdues. So copy the entire valiases folder to a backup folder for later retrieval – to do this run these two commands in SSH …

mkdir /etc/valiasesbackup

… this creates the backup folder, and …

cp -p /etc/valiases/* /etc/valiasesbackup

… this copies all files in the valiases folder to the backup folder.
Change all default/catchall addresses from :blackhole: to :fail:

Then to change all default addresses to :fail: we’ll need to run two commands, one to change any :blackhole: settings and the other to change any default addresses that forward to another email address. First run this command in SSH …

replace ‘:blackhole:’ ‘:fail:’ — /etc/valiases/*

… this will change any :blackhole: setting to the desired :fail: setting.

Change all default/catchall addresses to :fail:

Then the second command …

sed -i ’s/^\*: [^ ]*$/*: :fail: ADDRESS DOES NOT EXIST/g’ /etc/valiases/*

… this will change any setting which sends the unrouted mail to another email address to the desired :fail: setting.

Now, running this command again should reveal no results because we have just changed all settings to :fail: …

grep ‘*:’ /etc/valiases/* | egrep -v ‘:fail:’

Restore valiases files

Once the attack is over, you can then copy the backed up valiases files to their usual place, run this command from SSH …

cp -p –reply=yes /etc/valiasesbackup/* /etc/valiases

… all done. And this should only take about a minute to complete, depending on your typing or copy and paste skills.




website promotion