The situation is as follows. You're hosting a domain with us (say, yoursite.com) and are running some mailboxes/address with it. Suddenly you start receiving failed delivery reports (from very few up to very many) that basically say that your mail to someone@elsewhere.com could not be delivered because of whatever reason. However, you're pretty sure you never sent such mail. The reasons could be:

1. You did send the email in fact;
2. You are running a virus/worm on your computer that is hijacked your email client to send out emails;
3. You are running a vulnerable web site (e.g. a contact form) that has been abused to send out email with your identity (either explicitly specified, or implicitly added by the server);
   
4. A 3rd party broke into one of your user accounts on our server and used it to send emails;
5. A 3rd party spoofed your sender identity, specifying either a valid, or inexistent email address on your domain as the From field.

In either case, an email address belonging to you was found in the From field of the message, and the destination server for elsewhere.com is coming back to you with the report. The critical evidence can be found in the headers of the original email sent. It is often the rule to include the message in question either quoted or as an attachment, as part of the failure report you get. Once you find it, locate the last few headers line that start with 'Received'.

In the cases above numbered #1 and #2, it would mention a hostname or an IP address which belongs to your local network or the ISP you're connecting through. Cases #3 and #4 are the only important from our point of view, because they involve compromised accounts and broken security. The most (if not only) reasons are weak web site code (i.e. code that does not check for malicious mail injections) and weak passwords. Beware that both case are covered by our TOS/AUP conditions and may mean penalties to you if happening repeatedly. You are responsible for running applications that are not vulnerable and you are responsible for keeping passwords reasonable strong.

What remains is case #5, which is by far the most common one, and, unfortunately, the one which is definitely the most difficult to prevent or fight. Given how SMTP works by design, nothing is preventing anybody from using whatever email address desired in his sender identity (i.e. in the From field) when sending out email. It is upon the destination servers to decide whether to accept or reject, and if they reject (e.g. the recipient doesn't exist, has a full mailbox etc.), then the sender will receive a delivery failure notification - the sender as specified in the From header (not the actual person who send the email out).

While there are some recent measures that can be implemented to help mail servers decide whether mail is arriving from the party it says in the From headers (e.g. SPF records in DNS), there are no technical means of helping the real victims here, i.e. the users whose sender identities were spoofed.

We as the server owners are not concerned by this situation (i.e. we won't hold you responsible for email which - based on the headers - was obviously not sent through our servers). We are though concerned about the load this may put on our mail servers. The first thing that you should make sure of, is that you are not using catch-alls (i.e. wildcard rules to
forward all mail for a domain into a single mailbox or a single external address). In fact, if we see a high load on a server due to a catch-all, we will turn the catch-all off regardless of its immediate consequences for the owner. Catch-alls are bad for several reasons, and we have said that on numerous occasions.

If you have problems deciding whether case #5 applies to you, or whether your hosting account has been compromised as per #3 or #4, open a support ticket and give us the full headers of one such email (i.e. the original email, not the delivery notification itself).