Adding bounce spam rejectiion

Should we refuse MAILER-DAEMON returns of email we didn't send (it breaks the RFCs)?

  • Hang the RFCs, let's do it

    Votes: 7 100.0%
  • No. Let's be RFC compliant.

    Votes: 0 0.0%

  • Total voters
    7

Icheb

Verified User
Joined
Sep 15, 2003
Messages
556
Location
The Netherlands
Adding bounce spam rejection

I've talked this over with Jeff already, but we'd like to have the opinion of the rest of you.

For a while now, our servers, and servers I manage, are being bombarded by the result of 'joe jobs', where the spammer places a from in each message like:
<random>@<domainhostedbyme>

Most of my customers use catchall.

So this caused the problem of bounces from other legitimate mailservers being send to my servers. The problem is that this isn't just one or two messages, not more along the lines of 10.000 to 20.000 messages per day.
This causes server overloads as Spam Assassin is unable to process these amounts of spam at the same time.

Until some time ago we've been able to block it by creating mail blackholes. But it's too much nowadays. So we implemented the following;
1. Add a signature to every outbound e-mail.
2. When there's an incoming e-mail, try to find out if it's a bounce message.
3. If 2 is true, check the bounce key.
4. If the bounce key is valid, accept the message, otherwise just deny it.

The patch essentially exists of:
1. Add bounce_id and bounce_secret variables (each server has to be different)
(like this:
BOUNCE_ID = anubis.sebsoft.nl-178
BOUNCE_SECRET = 0b0b8c637a9548f25bdada44f6d36ffb
(note these values aren't the values we're using at the moment)


2. Find:
# ACL that is used after the DATA command
check_message:

Below that, add the following:
accept
regex = [dD]isposition.*:::.*disposition-notification.*

deny senders = :
condition = ${if ! eq{$recipients_count}{1}{1}}
message = Bounces must have only a single recipient

deny senders = :
! condition = ${if match \
{$message_body $message_body_end} \
{[xX]-bounce-key:\\s*BOUNCE_ID;${rxquote:${lc:$recipients}};(\\d+);(\\w+)} \
{${if eq {$2} \
{${length_8:${md5:BOUNCE_ID;${lc:$recipients};$1;BOUNCE_SECRET}}} \
{${if <{${sg{${eval:$tod_epoch-$1}}{-}{}}}{864000}{1}}}}}}
message = Bounce does not contain a valid X-bounce-key signature so not accepting message

Find
# This transport is used for delivering messages over SMTP connections.

remote_smtp:
driver = smtp

Below, add:
headers_add = ${if eq{$return_path}{}{}{X-bounce-key: BOUNCE_ID;${lc:$return_path};$tod_epoch;${length_8:${md5:BOUNCE_ID;${lc:$return_path};$tod_epoch;BOUNCE_SECRET}};}}

(The italic parts indicate something I added today, hasn't been tested yet, to allow certain messages to pass without going through the check, this however will have to be finetuned a bit more ;)).

This will block every mail that doesn't contain the right bounce key. That way, bounces that are generated without having come from your server at first, will not be allowed.

What do you guys think?
 
I'm certainly *not* an expert and I don't know if this is a 100% solution.

But if it works like you say it does (or should) it looks like a real simple and rock solid solution to a very big problem (at least in your case).

What are the negative points? More processing time by Exim?

Jeff, are you thinking about adding this into SpamBlocker?

Greetings,
Niels
 
Well there are some downsides;
Some mail will be rejected, like in this case:

Person a doesn't use the domain names SMTP server to mail someone, the mail gets bounced back for some reason, the message will be refused because the bounce key is missing.
But for us it works great, as we ask every customer to use our SMTP server for outbound mail.

The extra processing time is acceptable, as time is won by not putting those message through SA.

Furthermore, I do have to say I too am not an expert with ACL's...
 
It's a big problem on our servers as well. It's important to note that you can't guarantee all folk who send email with return addrsses hosted on your servers will always use your mailservers.

And as a result, you will be (at least part of the time) in violation of the RFCs.

So my question is, is this important enough to violate the RFCs? Note that these emails generally only cause a problem for your users when they implement catchall; we generally tell our clients if they implement catchall they're going to have to deal with it.

We'll never implement it for ourselves, but of course I can add it to SpamBlocker and leave it turned off; then everyone who wants it can turn it on.

I've added a poll :) .

Jeff
 
It would be lovely, but i suggest to implement in on a per-user/domain base. Some of my customers use their ISP's smtp server.

I had to turn off catch-all for my own domain because bouncers made me crazy. So I would give it a go, but users must have the possibility to turn it on/off.
 
fwpeter said:
It would be lovely, but i suggest to implement in on a per-user/domain base. Some of my customers use their ISP's smtp server.

I had to turn off catch-all for my own domain because bouncers made me crazy. So I would give it a go, but users must have the possibility to turn it on/off.

Hmm, that would be a nice solution for everyone. Turn it on if you want, or leave if off if you don't want it...
 
Users won't have the ability to turn it on/off unless either DA adds that, or someone (us?) writes a plugin.

As you can see, when writing an exim.conf file that's going to be used by everyone, we have to be very careful what/how we implement.

Jeff
 
I've decided to leave it out for now. It may become part of something in the future along with a DA control panel to set it.

Jeff
 
Back
Top