Swede,

I might be able to help.

You're target for a system that goes through a list of domain names searching for valid or responsive email addresses. The attack will stop once the specified volume of mail is sent, usually a few hours. This attack is somewhat different to the brute force attack that targets http passwords and not email addresses.

A dictionary attack on an email server, as opposed to web password access consists of spammers generating apparently random addresses ([email protected]) using a predifined list of words or commonly used email address names (a ‘dictionary’) for a particular domain (5bears.com) and sending email to them.

Those that bounce back as invalid are purged; those that don’t bounce - ie message accepted by the mail server as a good address will be assumed to be active and added to a list of ‘good’ addresses and subsequently used as a target for spam, sold to spammers, or if the server is open relay used to bounce spam.

A variation sends an smtp specific validation request so theres no email but requires a known and published email server to do so. Not commonly used for this attack as its easy to locate the source and action can easily be taken.

This is a common attack, easily identifiable and the process and resolutions are well known. In other words your provider should identify the attack and know what to do about it without threatening you or your service - assuming they host your email server and you're not running your own pop/smtp server locally.

the attacks are emails sent to the email server defined in the mx record for your domain, hosted by your provider. The system(s) sending them are probably forging the headers to show various sender and return addresses *BUT* the sending IP cannot be so easily spoofed. Your provider can (should) easily put a filter on to block email from the sending IP address without affecting your other mail. This is a specific block of a sending IP address, usually before it enters the smpt server. The IP addresses to be blocked are derived from a simple view of headers from some of the messages received and/or bounced. An alternative is to put a reverse DNS test on each incoming mail which checks the sener/return domain against the sending IP. Finally your providor should be able to limit the number of emails received from any IP in a given period - so stopping the thing slowing down the server.

Even if your providor doesn't do any of this then the problem should soon go away as the list is exhausted. look to see if any unusual mails have been received in this period and this could be an indication that the addresses have been farmed..

hth

Andrew