Some users have recently experienced a “Bounce Attack” on their email account.
This happens when someone sends mail pretending to be from your domain and the mail is then bounced by the receiving server back to your mailbox as the mail was purportedly from you even though you never sent it. This can become a problem if thousands/millions of messages are bounced back to you. This is commonly referred to as “joe-job”
We are looking at how to combat this and have come upon a possible solution.
Since we implemented SRS:Sender Rewriting Scheme we actually specify the return-path for all mail sent by our server using a unique hash key dependant on the sender.
Using this knowledge we can then assume that if we receive a mail with return-path <> (a null sender) and to a valid SRS address that the bounce is from a message sent by our mail servers.
The reason we check for a null sender is because bounce messages are always sent by a null sender.
As we now have this information we can chose not to accept mail where the sender is null and the receiver is not a valid SRS address.
There are some potential problems with this set-up:
- If you send mail using a mail server other than ours and the message bounces you will not receive the bounce message.
- Some auto-responders and mailing lists send using a null sender <> so these would not be received.
- RFC guidelines state you should accept mail from <> (RFC1123 5.2.7)
We are currently testing implementation on our mail servers at present. We would appreciate customer feedback.
January 10th, 2006 at 1:52 pm
One of the (many) reasons I switched from Easyspace to AGUK was that my primary email domain became the victim of a Bounce Attack in late autumn, to the point where eventually I had to abandon the domain; I am therefore very much in favour of any measure which might reduce the possibility of a repeat attack.
I still have a couple of unanswered questions about this phenomenon: 1) How and why does one particular domain out of millions get picked for this kind of highjacking; and 2) A lurking worry has always been that even if the bounced-back emails are prevented from clogging up my postbox, the misuse of the domain name will continue unabated until anything associated with that domain, including legitimate mail, will be automatically blocked by spam filters.
January 10th, 2006 at 2:22 pm
There is unfortunately pretty much nothing you can do to stop anyone from sending mail that “pretends” to be from you or your domain.
However there are measures you can take to protect your domain and reduce the risk of this happening.
First is publishing SPF records for your domain. See What is an SPF record and why do I need one?. By default we publish basic SPF records for you anyway.
Second is to not use catch-all accounts. We will be doing an article soon about the disadvantages of using catchall accounts and how to make them more productive. Since the problem with catch-all is they accept mail to anyone. Since a [Spam] message will be sent using user names from your domain most likely made up the bounce messages will never be accepted since the user wont exists except if you are using a catch-all account.
Regarding the misuse of your domain name for spam, in general it is not email addresses that get penalised for sending spam it is the actual sending servers themselves.
January 10th, 2006 at 3:01 pm
We do get some unsolicited mail on our catch-all account but have not yet suffered a bounce attack.
For the majority of users I guess any protection against flooding, DoS or fraud would be welcomed. For the odd user that sends email via some other account with an AGUK-served reply address perhaps there could be an opt out button.
January 13th, 2006 at 6:51 pm
With the feedback we have so far received it is likely we will provide the ability to create a filter on a per user email account basis.
This will allow those wishing to use it the ability to do so.
January 23rd, 2006 at 2:39 pm
[…] Further to our recent development project Bounce Attack Prevention we are now able to provide our customers the ability to reject incorrectly bounced mail. […]