backscatter issue with exim config??

[empowering]

Hi, I got a complaint about backscatter spam from our exim config using a stock exim 2.1.1 that bounced from our mail server but appears it was not at the SMTP level. It sent to the "From" and not rejected at the smtp level. Here is the log output:


2008-11-25 02:17:11 1L4sAZ-0007AJ-Al <= vic@someremotedomain.com H=2-0-124-91.pool.ukrtel.net (microsof-4aa06c) [91.124.0.2] P=smtp S=4558 id=20081125121651.3479.qmail@microsof-4aa06c T="Best Sales 2008!" from <vic@someremotedomain.com> for postmaster@somelocaldomain.com
2008-11-25 02:17:12 1L4sAZ-0007AJ-Al ** postmaster@somelocaldomain.com F=<vic@someremotedomain.com> R=virtual_aliases:
2008-11-25 02:17:12 1L4sAa-0007AN-0V <= <> R=1L4sAZ-0007AJ-Al U=mail P=local S=5371 T="Mail delivery failed: returning message to sender" from <> for vic@someremotedomain.com
2008-11-25 02:17:12 1L4sAZ-0007AJ-Al Completed

The postmaster@somelocaldomain.com is not a valid email address. It appears exim accepted the email and then closed the connection from the spammer and then created a new email and sent the backscatter out.



2008-11-25 02:17:12 1L4sAa-0007AN-0V <= <> R=1L4sAZ-0007AJ-Al U=mail P=local S=5371 T="Mail delivery failed: returning message to sender" from <> for vic@someremotedomain.com
2008-11-25 02:17:17 1L4sAa-0007AN-0V => vic@someremotedomain.com F=<> R=lookuphost T=remote_smtp S=5493 H=beer.org.uk [91.84.48.107] X=TLSv1:DHE-RSA-AES256-SHA:256 C="250 2.0.0 mAP7HDM2026162 Message accepted for delivery"
2008-11-25 02:17:17 1L4sAa-0007AN-0V Completed


This should not be happening

[nobaloney]

Hi, I got a complaint about backscatter spam from our exim config using a stock exim 2.1.1 that bounced from our mail server but appears it was not at the SMTP level. It sent to the "From" and not rejected at the smtp level. Here is the log output:
I think I understand most of what you wrote above, but I don't understand what you mean by stock exim 2.1.1 because DirectAdmin has never used an exim version below 3.x.

So I'm presuming you mean my exim.conf file version 2.1.1.

I've just checked and all versions of my exim.conf file accept email to postmaster and also to abuse and hostmaster, by default:

# accept mail to postmaster in any local domain, regardless of source
accept local_parts = postmaster
domains = +local_domains

# accept mail to abuse in any local domain, regardless of source
accept local_parts = abuse
domains = +local_domains

# accept mail to hostmaster in any local domain, regardless of source
accept local_parts = hostmaster
domains =+local_domains
As I've written before, I originally wrote SpamBlocker exim.conf for my own use, and I always have postmaster, hostmaster, and abuse for every domain on my systems.

No one else has mentioned this, though it's been there for years. So I'm not sure that it needs to be removed. You can certainly comment out those sections while we discuss this issue.

RFCs require that mail to postmaster and abuse be accepted by default; perhaps by default these addresses should be a part of DirectAdmin, perhaps forwarded to admin. Then we can remove hostmaster.

Comments from others accepted and appreciated.

Jeff

[Chrysalis]

Jeff I am dealing with the same problem on a server now. here is the problem in more detail.

Spam arrives to an inbox that is full.
Exim accepts the email and spamassassin processes it.
Exim then realises the inbox is full and sends a bounce (after it has accepted the email).
Email is bounced to an email box that doesnt exist since most spam is sent using spoofed addresses.

The solution I am looking at involves getting exim to check quota at a earlier stage of the transaction before the email is accepted.

[empowering]

Jeff I am dealing with the same problem on a server now. here is the problem in more detail.

Spam arrives to an inbox that is full.
Exim accepts the email and spamassassin processes it.
Exim then realises the inbox is full and sends a bounce (after it has accepted the email).
Email is bounced to an email box that doesnt exist since most spam is sent using spoofed addresses.

The solution I am looking at involves getting exim to check quota at a earlier stage of the transaction before the email is accepted.

I never looked closer into this issue but I suspect that's what happened to me.

Either way it wasn't a SMTP level rejection and caused this backscatter spam.

[empowering]

So I'm presuming you mean my exim.conf file version 2.1.1.


Sorry yes.

[empowering]

Also per RFCs and rfc-ignorant.org blacklist:
abuse@
postmaster@

MUST be present for every domain, so these should not be removed.

Ideally as a hosting provider or maintainer of the machine

abuse@ and postmaster@ in some cases should go to some centralized email address of the hosting provider, not to the customer.

With the way this rule is written as is where does the email go?

[nobaloney]

here is the problem in more detail.
Spam arrives to an inbox that is full.
Exim accepts the email and spamassassin processes it.
Exim then realises the inbox is full and sends a bounce (after it has accepted the email).
Email is bounced to an email box that doesnt exist since most spam is sent using spoofed addresses.

The solution I am looking at involves getting exim to check quota at a earlier stage of the transaction before the email is accepted.
I'm testing now with my latest SpamBlocker; I no longer support changes to Version 2.x.

Whether the mailbox quota or the user's total quota is exceeded the mail goes into the queue and waits until it can be delivered (until the mailbox again has room). The rationale behind this is that a full mailbox is a temporary condition.

Of course if the email hold time is exceeded the server will return the email.

This has nothing to do with SpamAssassin.

This is part of the exim normal delivery process. I suppose it can be changed but I see no reason to change it.

I don't believe the SpamBlocker exim.conf file I've written has anything to do with this behavior, and I believe it's the same with any version.

However saying that I must admit that I've changed back the quota some time ago and the test mail is still in the queue; though it's supposed to be delivered, I don't see it being delviered :).

I'll wait to see if it gets deliverred; if I haven't responded in 24 hours please remind me to look at this again.

Thanks.

Jeff

[nobaloney]

Right now email to abuse@ and to postmaster@ both get delivered to the user to do with it whatever the user wants. I suppose redirecting those addresses could be a part of exim's exim.conf file but I don't implement it there because I don't believe that it's exim's job to redirect mail that a user might want. I recommend you preset forwards to the user's username mailbox if you want that behavior.

The problem with having it implemented in exim.conf is that then the user couldn't set it up as a forward to manage it her/himself.

Jeff

[Chrysalis]

yep you correct spamassassin is nothing to do with it, I mentioned it as the ****SPAM**** subject on bounced emails made it immediatly obvious to me what was going on.

I now have what looks like a working solution in place for both incoming and outgoing backscatter spam and if it proves to be a good working config I can submit config changes to you for inclusion in the newer spamblocker's. :)

[nobaloney]

I previously wrote:

I don't believe the SpamBlocker exim.conf file I've written has anything to do with this behavior, and I believe it's the same with any version.

However saying that I must admit that I've changed back the quota some time ago and the test mail is still in the queue; though it's supposed to be delivered, I don't see it being delviered .
Soon after I wrote that the the emails were delivered to the correct mailbox; no return was attempted. I'd love to know what that's not been happening on your system.

Jeff

[philmcdonnell]

Right now email to abuse@ and to postmaster@ both get delivered to the user to do with it whatever the user wants. I suppose redirecting those addresses could be a part of exim's exim.conf file but I don't implement it there because I don't believe that it's exim's job to redirect mail that a user might want. I recommend you preset forwards to the user's username mailbox if you want that behavior.

The problem with having it implemented in exim.conf is that then the user couldn't set it up as a forward to manage it her/himself.

Jeff

These get delivered to what user? The domain owner? What if the main domain account is set to :fail: as a bunch of my clients have it set to do?

How can I preset forwarders on each account/domain to point these addresses to somewhere else?

I was thinking that as a web host the abuse/postmaster should come to a default account I have setup for any domain on my servers, doesn't this sound correct?

Thanks,
Phil

[nobaloney]

These get delivered to what user? The domain owner? What if the main domain account is set to :fail: as a bunch of my clients have it set to do?
Actually I miswrote. What I should have written is that email to postmaster and abuse are whitelisted by the default exim.conf file, to be delivered wherever the user sets it up. If the user doesn't set it up it gets refused. I still believe it's up to my clients to manage their own postmaster and abuse email.

I suppose you could convince me otherwise; if so it would have to first be tried to the user and then only if the user doesn't accept it, get sent to the admin's account. I suppose it could be done with a router setup, but I don't have time to look for it now. If you do, please do, as I'm working this week on a release candidate for SpamBlocker3; i could include it.

But in my releases I'd probably not make it default behavior; I don't want my users' postmaster email. Why? more below.

How can I preset forwarders on each account/domain to point these addresses to somewhere else?
By using a post-domain-creation script to add the proper forward to the /etc/virtual/example.com/aliases file.

I was thinking that as a web host the abuse/postmaster should come to a default account I have setup for any domain on my servers, doesn't this sound correct?
Not to me. I don't want postmaster email. Let me explain:

The postmaster address is for people to use who (for example) can't get an email through to their aunt Molly, probably because they've got the address wrong. If I get postmaster email like that I'm stuck with having to do something with it.

The abuse address is for complaining about abuse. Now let's think about this for a moment.

If spam.example.com is sending you email, do you really want to notify their abuse address? Generally not; it's only going to go to the sender, and not to anyone who cares.

Generally the anti-abuse community sends abuse to the mailserver's abuse address, and that's usually abuse@servername.example.com. That's your responsibility to set up. I know that DirectAdmin installation instructions set you up without an aliases file for the servername, since it's not a domain name on the server; I suppose I should publish a whitepaper on how to do that.

Of course on today's Internet that's fairly useless as well, since most spam comes from hijacked systems.

So failing that you write to the abuse address you write the abuse contact for the IP# where the spam originates.

You should be able to find that by doing a whois (from a real whois client, not from a whois webpage) on the IP#:

$ whois 65.254.63.216
and grep for Abuse and/or abuse.

Of course it doesn't always work; for example let's look at the whois record for this static IP served by a major DSL provider:

whois 67.112.189.210

In which case you can just block :).

Jeff

[philmcdonnell]

First thank you Jeff for such a great response...

With all that being said, why am I getting BackScatter if the abuse/postmaster is being refused?

You said that the exim.conf whitelists the abuse/postmaster addresses but if I don't have them pointing anywhere they should just be refused on RCPT and not cause BackScatter right?

Thanks again,
Phil

[philmcdonnell]

Jeff, I just got a response from my datacenter and they said what you wrote is not correct about the postmaster/abuse addresses. Here is what I received:


That is not correct. Maybe it's because you are using the SpamBlocker exim conf? It accepts them only to reject them later and spew out a NDR.


Thanks,
Phil

[nobaloney]

Hmmm... on second thought, looking at it again, you appear to be right. I'll have to figure out a workaround, so we can still whitelist postmaster and abuse (as required by RFCs) and yet figure out a way to deliver it. I think the best way is to force a (perhaps hadden) forward from both postmaster and abuse to the username mailbox.

Any suggestions, anyone?

Jeff

[philmcdonnell]

Hmmm... on second thought, looking at it again, you appear to be right. I'll have to figure out a workaround, so we can still whitelist postmaster and abuse (as required by RFCs) and yet figure out a way to deliver it. I think the best way is to force a (perhaps hadden) forward from both postmaster and abuse to the username mailbox.

Any suggestions, anyone?

Jeff

Only problem with this idea is what if the main account never gets checked, it will fill with these emails until they start bouncing...

/Phil

[DirectAdmin Support]

Probably a solution (for those who really don't care about emails sent to these addresses) is to default to a :blackhole:, with the ability to forward elsewhere if you want. I don't believe that end DA User are going to be checking these 3 accounts if they exist, also considering they'll likely be big spam targets since they are accepted. Why do we need them? Because RFCs say so, and they're often checked for mail acceptance/standards. Do we really care about the mail sent to them? That's up to you, I personally don't, but do want to pass the RFC checks, but without backscatter (and don't need to read mail sent to them)

To prevent the backscatter, if you don't want to read the emails.. you can default to a blackhole with this. Create:
/usr/local/directadmin/scripts/domain_create_post.sh

with the code
#!/bin/sh
FILE=/etc/virtual/$domain/aliases
grep -v '*' $FILE > $FILE.tmp
echo "abuse: :blackhole:" >> $FILE.tmp
echo "postmaster: :blackhole:" >> $FILE.tmp
echo "hostmaster: :blackhole:" >> $FILE.tmp
echo "*: :fail:" >> $FILE.tmp
mv -f $FILE.tmp $FILE
chmod 600 $FILE
chown mail:mail $FILE
exit 0;and that will add the 3 blackhole forwarders for each account. Don't forget to chmod this script to 755.

To run this for existing domains, run:
cd /usr/local/directadmin/data/users
for i in `cat */domains.list`; do { domain=$i /usr/local/directadmin/scripts/domain_create_post.sh; }; done;Don't run it twice, or you'll get duplicates in the aliases file (which won't hurt anything, it's just a waste of space)

If this is important enough, I can make a directadmin.conf option to add these 3 values by default. Note that they'll show up in the User's forwards list, so they can modify them as needed afterwards (including deleting them). They will count towards their forwarders count total, which they'll likely not enjoy too much.

John

[philmcdonnell]

John,

Thanks for the info and the script. I think I will blackhole all for now.

Your idea about a new option would be great, set it up so that abuse/postmaster gets forwarders automatically. The hostmaster should just be deleted from the exim.conf because RFC doesn't require it anyway.

Thanks,
Phil

[philmcdonnell]

Probably a solution (for those who really don't care about emails sent to these addresses) is to default to a :blackhole:, with the ability to forward elsewhere if you want. I don't believe that end DA User are going to be checking these 3 accounts if they exist, also considering they'll likely be big spam targets since they are accepted. Why do we need them? Because RFCs say so, and they're often checked for mail acceptance/standards. Do we really care about the mail sent to them? That's up to you, I personally don't, but do want to pass the RFC checks, but without backscatter (and don't need to read mail sent to them)

To prevent the backscatter, if you don't want to read the emails.. you can default to a blackhole with this. Create:
/usr/local/directadmin/scripts/domain_create_post.sh

with the code
#!/bin/sh
FILE=/etc/virtual/$domain/aliases
grep -v '*' $FILE > $FILE.tmp
echo "abuse: :blackhole:" > $FILE.tmp
echo "postmaster: :blackhole:" > $FILE.tmp
echo "hostmaster: :blackhole:" > $FILE.tmp
echo "*: :fail:" > $FILE.tmp
mv -f $FILE.tmp $FILE
chmod 600 $FILE
chown mail:mail $FILE
exit 0;and that will add the 3 blackhole forwarders for each account. Don't forget to chmod this script to 755.

To run this for existing domains, run:
cd /usr/local/directadmin/data/users
for i in `cat */domains.list`; do { domain=$i /usr/local/directadmin/scripts/domain_create_post.sh; }; done;Don't run it twice, or you'll get duplicates in the aliases file (which won't hurt anything, it's just a waste of space)

If this is important enough, I can make a directadmin.conf option to add these 3 values by default. Note that they'll show up in the User's forwards list, so they can modify them as needed afterwards (including deleting them). They will count towards their forwarders count total, which they'll likely not enjoy too much.

John

Big problem, this script didn't work correctly, it wiped out all the current forwarders and replaced them with *: :fail: and that is all...

So now what do I do to fix this issue?

[nobaloney]

There's a bug in the script. It appears to me that the > should be replaced in all instances with >>. Since I didn't study it, I'm not making the change, but I've added a note at the top of John's post, and I've written him to look at it.

Jeff

[nobaloney]

Before you blackhole your postmaster address you should probably read this (http://www.rfc-ignorant.org/policy-postmaster.php) from rfc-ignorant.org. You're expected to deal with email to postmaster.

Note that they do seem to think it's okay to block mail to postmaster sent from <> as long as the address doesn't send email. We do occasionally send email from our postmaster address, especially when we're writing to another postmaster. Perhaps we should change.

If anyone can find an acl to block mail to postmaster only from null senders (<>) let me know promptly and it'll be in the next exim.conf SpamBlocker file, due to be out by the end of the month.

Edit: I found this exim.conf master file, suggested by a known good guy in the exim world, and used by lots of people, here (http://marc.merlins.org/linux/exim/exim4-conf/exim4.conf).

The default acl for accepting postmaster email posted there is what we use:

# Accept mail to postmaster in any local domain, regardless of the source,
# and without verifying the sender.
accept domains = +local_domains
local_parts = postmaster
That's what we use as well. What I'm looking for is an acl that does the verification based on the sender not being <>.

Anyone able to help?

Jeff

[DirectAdmin Support]

Thanks, replaced with >>
John

[redesb]

Hi Jeff,

So many time without write here...

I'am very interested in the progress of the 'SpamBlocker', you rock!! Surfing I find this page about 'Blocking spam (http://www.wizzy.org.za/article/articlestatic/20/1/2/)' with Exim, that I find interesting, especially the part that says:

# surprising number of spammers spoof my own address
drop message = HELO/EHLO invalid
condition = $ {if match{$sender_helo_name} \
{your.hostname.org.za} \
{yes}{no} \
}

# and IP
deny condition = $ {if eq{$sender_helo_name}{$interface_address}{yes}{no}}
message = Forged HELO: you are not $sender_helo_name
log_message = Forged HELO: is our interface address

It might be interesting for the 3.2b version, personally I'm using v3.1 and I'm very happy with the results, but spam with the same sender and null sender (<>) me going crazy.

Hope this help, I am waiting impatiently to see the next version. Thanks Jeff.

Ramon

[nobaloney]

Thanks very much. I'm going to carefully look at the link before finalizing the next release.

The next release RC was scheduled for the end of the month, but I was delayed by some problems with taking over a bunch of WordPress sites, and while I'm still trying for the first of the month, I can't guarantee it :(.

Jeff

[nobaloney]

I'm moving forward today in this thread and I've moved it to the SpamBlocker3 subforum because it's really about the future.

I've looked carefully at user redesb's solution above, and I'm going to use it in the next release candidate for SpamBlocker3.

I've found an excellent configuration for blocking backscatter, here (http://psg.com/%7Ebrian/software/authbounce/configure-authbounce.txt). Unfortunately it has a major problem.

The only problem is that you will
lose bounces if the remote MTA does not quote back at least the headers of
the message it is returning, and auto-responder messages ("I am away on
vacation") if they are sent with an empty envelope sender and do not quote
the message back. I can live without those; in any case the empty return
address is a declaration by the sender that "I do not care if this is
delivered successfully or not".
This means that both DirectAdmin vacation messages and autoresponders will be thrown away. Probably most others as well.

Do you want to get email from autoresponders? We use them. Do others? Do you?

Do you allow your clients to set vacation messages? We do. Do others? Do you?

Is it worth giving up being able to receive both autoresponders and vacation messages to eliminate backscatter?

To be effective, it's got to be done serverwide. Are your users willing to give up the ability to get vacation messages and autoresponders?

Discussion encouraged.

Jeff

[Chrysalis]

autoresponders generally are not reccomended practice, unfortenatly as you mention they are relied on by various users.

what I do know is backscatter is now a major issue, its growing at a rapid rate.

[redesb]

I've looked carefully at user redesb's solution above, and I'm going to use it in the next release candidate for SpamBlocker3.
Thank you very much for including this.

I've found an excellent configuration for blocking backscatter, here (http://psg.com/%7Ebrian/software/authbounce/configure-authbounce.txt). Unfortunately it has a major problem.

This means that both DirectAdmin vacation messages and autoresponders will be thrown away. Probably most others as well.

Do you want to get email from autoresponders? We use them. Do others? Do you?

Do you allow your clients to set vacation messages? We do. Do others? Do you?

Is it worth giving up being able to receive both autoresponders and vacation messages to eliminate backscatter?

To be effective, it's got to be done serverwide. Are your users willing to give up the ability to get vacation messages and autoresponders?

Backscatter topic seems interesting, but perhaps it would be better to include it as an option disabled by default. Sure I'll use, as none of my clients use the vacation message nor autoresponders.

Ramon

[nobaloney]

We all need to start thinking about stopping backscatter.

But I think you misunderstand. And I think I'm responsible for your misunderstanding. If you implement this solution it won't stop your users from using autoresponders.

What happens is for anyone implementing this solution, their users won't GET mail from autoresponders that are configured as DirectAdmin configures autoresponders.

So for example, if hotmail implements this, and someone writes you from hotmail while you're on vacation, they won't get your vacation message.

And as another example, If your friend using any provider goes on vacation you won't get his vacation message if your server implements this anti-backscatter solution.

Perhaps we should just tell our clients that on today's Internet we no longer guarantee they'll get vacation messages or autoresponders. Or that theirs will get delivered.

Here's a question about backscatter for you:

Who gets the backscatter? The individual sender? Or the sending server? If the latter, maybe the answer is to use a different server for sending email, that doesn't receive any. That's very easy to implement.

Jeff

[Chrysalis]

I would guess 90% or so of backscatter is lost, it is sent to non existant addresses,

The remaining 10% or so may well hit valid domains which are the victims of spoofing.

But a important issue as well is that if a server is bouncing spam it can very well find itself on a spam blacklist. CBL is one that defenitly comes to mind.

[interfasys]

I've looked carefully at user redesb's solution above, and I'm going to use it in the next release candidate for SpamBlocker3.

Is it available yet? Because it's really annoying when emails bypass the spam filters simply because they're being sent from the user's email address ;)

[nobaloney]

The next version of SpamBlocker will be out before the end of July, to resolve the issue with Sorbs going away.

Jeff

[nobaloney]

I almost like John's idea, and I may implement it myself.

That said, I think I've found a way to eliminate most of the backscatter:

# Mailer-Daemon messages must be for us
deny senders = ^mailer-daemon@.*
domains = !+local_domains
message = We don't host the domain to which you're sending
added to the ACLs just under the one that checks for port 587.

If I'm thinking right this morning, then this should keep a lot of backscatter off our server (someone please correct me soon if I'm wrong :))

I've tested it; it works, and it's going into a new release candidate some time today. Since most backscatter comes from mailer-daemon, this should work well for many of us.

Or am I missing something?

Look for RC 3.2.3

Jeff

[Chrysalis]

looks good jeff, I will add it to 1 or 2 servers myself and report back if any problems.

[nobaloney]

Hurry :).

I'm finally ready to release the final. I'm working on documentation.

Jeff

[ClayRabbit]

Jeff, I'm affraid your code "deny senders = ^mailer-daemon@.*" isn't correct, because "mailer-daemon@*" commonly is not a sender address of bounce message but only From: header value. Sender adress for bounces is: <>, so I beleive correct code will look like:
deny senders = :
...

(Oh, I have misunderstand meaning of Jeff's ACL rule, so next words has no direct relation to this ;) So I have whitened text)
Yes it's very simple solution to protect users from backscatter, but it will reject all delivery error messages, not only misderected ones. Personally, I don't like it. Moreover when one exim MTA will send bounce (correct one, not misderected), to another exim MTA with such configuration, message will be frozen on first server and will keept in mail queue for few days (not a big deal, but it doesn't look "correct" behavior, and in some cases it can aggravate the situation with queue overloading).
OMG! And with such configuration your email wouldn't be accepted by any exim host that using "sender callout" verification (I'm considering that check very useful and it's used on our servers by default.) For example, you are sending mail from directadmin@nobaloney.net to me, during SMTP session my exim connecting to your server and trying "MAIL FROM: <>\nRCPT TO: <directadmin@nobaloney.net>", your server answers "550 We don't host the domain to which you're sending", our exim thinks "A-ha! It's a spammer who are trying to submit email with fake sender adddress!" and rejects your mail...
Oh, and finally I'm sure such bounce rejection is agaunst RFC rules.

For our customers we have a plugin where they have an option to discard (but not reject) bounces for their domain similar way (as well as an option to disable callout verification).

So in my view, the only bounces that we can treat as "misderected" reliably enough and reject - it's bounces that routed to "catchall" alias. But it's require some (a bit complicated) exim configuration hacking. Other bounces must be accepted or silently discarded, but not rejected.

[ClayRabbit]

But I think this thread addresses more complicated and maybe even more important problem - how prevent our exim from sending misdirected bounces (since hitting spamtraps and receiveing complains even may lead to blacklisting).

AFAIK, currently this can happen in 2 cases
1) Exim failed to deliver message (with forged sender address) to local mailbox because it's full or user exceeded filesystem quota.
2) Exim failed to forward message to remote server.

Most other cases (including topicstarter's issue) will be covered and solved by "verify = recipient" condition inside ACL.

For now I have solution only for 2nd case (just 2-3 additional rows in exim.conf), since 1st case as it seems can't be solved by means of exim, but I think it can be implemented with additional function in exim.pl or an additional daemon.

[nobaloney]

[quote]Sender adress for bounces is: <>, so I believe correct code will look like:
deny senders = :
..
Yes it's very simple solution to protect users from backscatter, but it will reject all delivery error messages, not only misderected ones. Personally, I don't like it. Moreover when one exim MTA will send bounce (correct one, not misderected), to another exim MTA with such configuration, message will be frozen on first server and will keept in mail queue for few days (not a big deal, but it doesn't look "correct" behavior, and in some cases it can aggravate the situation with queue overloading).
OMG! And with such configuration your email wouldn't be accepted by any exim host that using "sender callout" verification (I'm considering that check very useful and it's used on our servers by default.) For example, you are sending mail from directadmin@nobaloney.net to me, during SMTP session my exim connecting to your server and trying "MAIL FROM: <>\nRCPT TO: <directadmin@nobaloney.net>", your server answers "550 We don't host the domain to which you're sending", our exim thinks "A-ha! It's a spammer who are trying to submit email with fake sender adddress!" and rejects your mail...
Oh, and finally I'm sure such bounce rejection is agaunst RFC rules.
Will adding this:

domains = !+local_domains to your suggestion work, and yet resolve all the issues you've mentioned above?

Have you actually tried accepting mail from me with sender callout verification enabled?


PS: And BTW error message you have used will mislead anyone who want's to know why message was rejected :)
This I'm not sure what you mean, since the error should only be sent back if the domain isn't hosted on our server.

Do you suggest I can I remove it and replace it with your code but with that one line (see above) added? Or should I just remove it as undable easily in exim.conf?

Jeff

[ClayRabbit]

Oh. Sorry, I completely missed "domains = !+local_domains" string. But in that case I can't understand the meaning of your construction at all. Mail to non-local domains is rejected by default (on "verify = recipient" check) if sender is not authenticated, and authenticated users is not a source of bounces. So this rule do nothing?

PS: I have re-edited my previous post.

[nobaloney]

ClayRabbit, you may be on to something...

My construction (repeated here so no-one has to scroll up):

# Mailer-Daemon messages must be for us
deny senders = ^mailer-daemon@.*
domains = !+local_domains
message = We don't host the domain to which you're sending
And my point was to deny email for which mailer-daemon was the sender, because otherwise it's whitelisted and would be accepted by the server.

Do I need to do it somewhere else? Please give me your thoughts. Anyone else with ideas, please give me your thoughts as well; I'm ready to do the final release but I'm now waiting for more suggestions.

Thanks for your help; I really appreciate more than just my eyes on this vexing problem.

Jeff

[ClayRabbit]

Jeff, actually I'm not familiar with SpamBlocker3 so can you point me the ACL rule that will accept such message? Or just ignore my criticism, maybe I'm just wrong with that.

But once again, in fact sender address for bounce messages is <> (empty).

[nobaloney]

The real question is what does exim look for as the sender? Since they use the plural, senders, I'm just not sure and will try to find out today.

So far all I've found is here (http://www.faqs.org/docs/linux_network/x-087-2-exim.delivery.html); if you search for mailer daemon you'll read:

MAILER-DAEMON is used by Exim as the sender address in bounce messages. It is also recommended that root be set up as an alias for an administrator, especially when deliveries are being run under the permissions of the recipient users, in order to avoid running any delivery as root.
I've always taken this to mean that when you check for senders in an acl you'll find Mailer-Daemon. Maybe I'm wrong.

Also note lines 836 through 849 and 851 through 863 in my exim.conf file found here (http://www.nobaloney.net/downloads/spamblocker/DirectAdminSpamBlocker3/exim.conf.3.2.3-RC).

I didn't write this code; it may have been written by John or Mark as original DirectAdmin code. It also presumes that you can identify mailer-daemon sent email by looking at the sender.

Also look at paragraph A.12.12, here (http://www.ibiblio.org/pub/linux/docs/HOWTO/Spam-Filtering-for-MX).

I'm going to ask on the exim-users list. In the meantime, since the ACL does no harm, there's no reason to make any change.

Jeff

[nieuwhier]

Hi. I implemented the newest spamblocker3 on my servers a few weeks ago.
Reason was the increasing number of times that one of my ip's was listed on backscatterer.org.

I thought the problem was solved but this week more ip's came on that list. (with
This week however more ip's became listed so the problem is growing I guess.

I will try to find some answer myself too.

[nieuwhier]

PCreate:
/usr/local/directadmin/scripts/domain_create_post.sh
Shouldn't this be:

/usr/local/directadmin/scripts/custom/domain_create_post.sh

[nieuwhier]

echo "*: :fail:" >> $FILE.tmp


This should not be in this script I think, it removes all catch-all addresses?

[nobaloney]

I'm going to test a backscatter solution which may work for us. I've been delayed because I had our main office system fail, and I've been busy restoring it.

Jeff

[ClayRabbit]

Also note lines 836 through 849 and 851 through 863 in my exim.conf file found here (http://www.nobaloney.net/downloads/spamblocker/DirectAdminSpamBlocker3/exim.conf.3.2.3-RC).I believe those sender checks inside routers is useless (and incorrect) since commonly server is generating bounces and auto-replies to regular email-addresses but not to "mailer-daemon@.*" and etc, since return-path (and $sender_adddress) for such messages is <> - empty.

Also look at paragraph A.12.12, here (http://www.ibiblio.org/pub/linux/docs/HOWTO/Spam-Filtering-for-MX).
Example in A.12.2 is pretty correct.
Condition
!senders = : postmaster@*means sender is not empty (sic!) and not postmaster@.

[ClayRabbit]

Last few days I have worked on solution to cover issues I have stated before (http://www.directadmin.com/forum/showpost.php?p=167041).
Here is the example
1) To prevent bounces about quota overusage, I have created folowing ACL ruleset:


# User quota check
warn domains = +local_domains
set acl_m_dontcare = ${if eq{$domain}{$primary_hostname} {$local_part} {${lookup{$domain}lsearch{/etc/virtual/domainowners}}}}
condition = ${if !eq{$acl_c_rcptuser}{$acl_m_dontcare}}
set acl_c_rcptuser = $acl_m_dontcare
set acl_c_quotauser = ${if and{{def:acl_c_rcptuser}{exists{/home/$acl_c_rcptuser/}}} \
{${run{/usr/bin/quota "-f/home/$acl_c_rcptuser/" -q "$acl_c_rcptuser"}{}{1}}}{0}}

defer domains = +local_domains
condition = $acl_c_quotauser
message = User quota exceeded
log_reject_target = reject

# Virtual mailbox quota check
warn domains = +local_domains
condition = ${if !eq{$acl_c_rcpt}{$local_part@$domain}}
set acl_m_dontcare = /home/$acl_c_rcptuser/imap/$domain/$local_part/Maildir/maildirsize
set acl_c_rcpt = $local_part@$domain
set acl_c_quotavirtual = ${if eq{$domain}{$primary_hostname} {no} \
{${if exists{$acl_m_dontcare} {${perl{check_maildirsize}{$acl_m_dontcare}}}{false}}}}

deny domains = +local_domains
condition = $acl_c_quotavirtual
condition = ${if >{${eval:$tod_epoch-$acl_c_quotavirtual}}{432000}}
message = Mailbox quota exceeded for a long time
log_reject_target = reject

defer domains = +local_domains
condition = $acl_c_quotavirtual
message = Mailbox quota exceeded
log_reject_target = reject
Also
quota_is_inclusive = false
maildir_use_size_file should be added to virtual_localdelivery: router inside exim.conf

check_maildirsize function inside exim.pl:
sub check_maildirsize
{
my $quota;
my $limit;
my ($sizefile) = @_;
if ($sizefile) {
open (FILE, $sizefile) || return 0;
$_=readline (FILE);
($limit) = (/^(\d+)S/);
if ($limit){
$quota=0;
while (<FILE>) { ($_) = split(/\s/); $quota+=$_; }
if ($quota >= $limit) {
$quota = (stat(FILE))[9];
close (FILE);
return $quota;
}
}
close (FILE);
}

return 0;
}
dovecot.conf modifications needed for maildirsize file handling:
--- dovecot.conf 2007-10-23 05:22:56.000000000 +0400
+++ dovecot.conf 2009-10-30 00:46:55.000000000 +0300
@@ -65,6 +65,8 @@

protocol imap {

+ mail_plugins = quota imap_quota
+
# Maximum IMAP command line length in bytes. Some clients generate very long
# command lines with huge mailboxes, so you may need to raise this if you get
# "Too long argument" or "IMAP command line too large" errors often.
@@ -107,6 +109,8 @@

protocol pop3 {

+ mail_plugins = quota
+
# Don't try to set mails non-recent or seen with POP3 sessions. This is
# mostly intended to reduce disk I/O. With maildir it doesn't move files
# from new/ to cur/, with mbox it doesn't write Status-header.
@@ -230,3 +234,6 @@
#count = 1
}

+plugin {
+ quota = maildir:ignore=Trash
+}

Quota file should be readable by exim uid/gid (or by world) for user quota check to work.

Oh. Almost forgotten... Virtual mailbox quota checking implemented above still wouldn't work for a while since exim creates "maildirsize" file with 600 permissions and it's not readable from exim.pl (http://bugs.exim.org/show_bug.cgi?id=727) On my machine I have patched my exim to fix that.

[ClayRabbit]

2. To prevent bounces from failed remote deliveries i have added
errors_to = ${if eq{$original_domain}{$domain} {fail}{}} inside "lookuphost:" router and
return_path = ${sender_address}inside "remote_smtp:" transport.

[nobaloney]

I have some code that should work but we had a failure of our main office system which required an update of our office systems (old libraries, software wouldn't work, etc) so I haven't had time to implement it. I'm going to look at your code (above) and mine, and bring out another release candidate ... BUT ...

I can't require changes that force a rebuild of exim, in anything I deliver, unless I can work together with John at JBMC (the publishers of DirectAdmin) so everything will just work.

Jeff

[nieuwhier]

Did you get any further on this ?

[nobaloney]

There's a new RC on my download site now (I put it there last evening); you can find it here (http://www.nobaloney.net/downloads/spamblocker/DirectAdminSpamBlocker3/).

The specific code is:

# RC 3.2.4 09-nov-2009
# Mailer-Daemon messages must be for us
deny senders = :
message = We don't host the recipient domain
hosts = !+relay_hosts
domains = !+local_domains
!authenticated = *
It looks good to me, but it hasn't caught anything for me in about 24 hours on the active server on which I'm testing it.

Care to try it? :)

Jeff

[nieuwhier]

I put the code in serval servers. I will let you know the results.

4 of my servers were listed again at backscatterer.org. 3 DA and one windows plesk server.

These 4 servers have not sent much mail in that period and the windows servers is configured totaly different than the DA servers, I am beginning to doubt the quality of that backscatterer list.

Some say that you should use that list reversed; that IF you are listed everything is OK.

[nobaloney]

If you just inserted the code into your current file, please check the new file; some positions have changed.

Thanks.

Jeff

[nieuwhier]

I compared the new file with mine.... :-)

[nobaloney]

Great. I'm sure the file does no harm, but I have no convincing proof it does good, either.

Anyone else care to try it? If so, see the new thread for the new version.

Jeff

[nieuwhier]

I have it implemented on 8 servers with each a load of at least 100.000 mails each day and have not seen one entry in the logfiles yet (after 12 hours).

[nieuwhier]

It is not working.

what I see in my mail queue is undeliverable mails with this:

049 X-Failed-Recipients: bordellofua31@xxx.com
029 Auto-Submitted: auto-replied
063F From: Mail Delivery System <Mailer-Daemon@myservername.xx>

I guess this is the problem, this one cannot be sent be the ones that were sent are not in the queue of course.

The problem is that the recipient is bordellofua31@xxx.com. This recipient does not exist on the server and there is no catch all active.

So it should have been refused in the recipient phase instead of accepted and then send back ?

[nobaloney]

Our latest code does check for it when mail is first received, and it checks for a blank sender.

And I've finally seen it. So I don't know why it's not working for you.

The only problem I've found (working on it tonight) is that valid mailer-daemon mail is being rejected if the server sends mail for a domain, but the mx record points elsewhere. I should be able to fix this and have a new RC up tomorrow.

Please do some investigating to see why you're not catching the email.

Jeff

[nieuwhier]

And I've finally seen it. So I don't know why it's not working for you.
Please do some investigating to see why you're not catching the email.
Jeff

I did a compare and the only thing I have different is this:
#accept local_parts = postmaster
# domains = +local_domains

# accept mail to abuse in any local domain, regardless of source
#accept local_parts = abuse
# domains = +local_domains

# accept mail to hostmaster in any local domain, regardless of source
#accept local_parts = hostmaster
# domains =+local_domains

I have created blackholes for current and new domains so I do not need those.

This still happens when I look into a queue:
036T To: Anthony-henpento@customerdomain.com
058F From: Mailer Daemon <Mailer-Daemon@punt-3.mail.demon.net>

The use address does not exist; no catch all, no forwarders, no vacation messages etc.

Weird.

[nobaloney]

I've thought about it; I've never said it worked; only that it did no harm.

But, moving on ...

Is Anthony-henpento@customerdomain.com a real email address on your server?

If not, is customerdomain.com a real domain name on your server. My code does not block mailer-daemon for non-existent users, only for non-existent domains.

Perhaps I have to rewrite it, but I'm awaiting resolution of an issue I brought up in my SpamBlocker 3.2.4-RC now ready for testing (http://www.directadmin.com/forum/showthread.php?t=33574) thread; I'm not going to spend any more time on it until I know I can get the help I need to include it at all.

Help if you can :).

Jeff

[nieuwhier]

I've never said it worked; only that it did no harm.
I know!


If not, is customerdomain.com a real domain name on your server. My code does not block mailer-daemon for non-existent users, only for non-existent domains.
Yes. That is the problem.

The domain does exist, but the mailaddress does not. Mail is accepted, then the recipient does not exist and a bounce message is created.
This was no problem for years but since the backscatter problem is growing it is.

Don't know why it was not that clear to me sooner ;-)

I am staring at the exim.conf right now but I still look like chinese to me. But I am learning ;-)

[nieuwhier]

No; that was not the cause. Unknown recipients are blocked well in the rcpt acl. No problem there.

I traced back some of the messages and I think this is the cause:
2009-11-13 21:06:15 217.19.237.55 whitelisted in list.dnswl.org

That is the reason why the message is accepted although the recipient does not exist ?

[nieuwhier]

I checked a few more and found the same.

Email is send to non-existing address. Normaly not accepted but because the ip is in the whitelist it is accepted.

196.25.211.12 whitelisted in list.dnswl.org

[nobaloney]

Yes, that's a problem. I probably need to move the block to above the whitelist. Please (and this is important) send me an email to remind me of this as I'm out now, and I need to have note of this when I'm back at my system. I think I can solve both causes for the whitelist by where I move things.

Jeff

[interfasys]

There's a new RC on my download site now (I put it there last evening); you can find it here (http://www.nobaloney.net/downloads/spamblocker/DirectAdminSpamBlocker3/).

The specific code is:

# RC 3.2.4 09-nov-2009
# Mailer-Daemon messages must be for us
deny senders = :
message = We don't host the recipient domain
hosts = !+relay_hosts
domains = !+local_domains
!authenticated = *
It looks good to me, but it hasn't caught anything for me in about 24 hours on the active server on which I'm testing it.

Care to try it? :)

Jeff

Maybe it would be worth adding a check in the backscatterer list?
Something like what is listed here: http://www.backscatterer.org/?target=usage

# Mailer-Daemon messages must not be from known backscatterers
deny senders = :
message = You seem to be a backscatter: $dnslist_text
hosts = !+relay_hosts
domains = !+local_domains
!authenticated = *
dnslists = ips.backscatterer.org

[nobaloney]

This is a totally separate issue than keeping our server from creating backscatter. Personally I won't include this; I believe it will block too much good mail. You can add it if you want; if you do, be sure to let us know if it appears to be blocking good mail.

Jeff

[nieuwhier]

Maybe it would be worth adding a check in the backscatterer list?
Never use that list!!! It is horrible. You almost can use it as a whitelist....

[interfasys]

Duly noted :), although, in our tests, nothing has been tagged by it so far.

[Wunk]

We decided to just setup an extra mailserver which handles all bounce messages for directadmin servers. Hollowing out the mail protocol wasn't really acceptable in our view, so we now have a (sendmail) mailserver that handles all bounces and empties the queue if a message is >3 hours old.

Companies not wanting to receive bounces can just blacklist the thing or use the backscatterer blacklist.

Implementing it:

First setup a dedicated mailserver which is used for relaying only, we call it 'bouncer.yourdomain.com' and add your directadmin server(s) to the relay list.

Then edit the exim.conf on your directadmin machine and add the following below the begin routers line as a first entry:



bouncer:
driver = manualroute
domains = !+local_domains
senders = ^postmaster@.*:^mailer-daemon@.*:^hostmaster: :
transport = remote_smtp
route_list = * bouncer.yourdomain.com


This will send any bounce mail which isn't destined for a local domain through the 'bouncer.yourdomain.com' mailserver.

[scsi]

Cool now make a guide how to setup the bouncer server :D

[Wunk]

Well that's not too hard:

Install a CentOS server with sendmail on it

Edit the /etc/mail/sendmail.mc file and remove the Addr=127.0.0.1 value from the DAEMON_OPTIONS line (so it listens on the external IP's too and not just on the local one) and save the file

type: make -C /etc/mail

make sure sendmail is started at boot (use the 'setup' program or chkconfig commandline tool), restart it for now: service sendmail restart

Now do a: 'cd /etc/mail', open the 'access' file in your favorite editor and add a line like:

1.2.3.4 RELAY

(where 1.2.3.4 is your directadmin server's IP)

then type: makemap hash access.db < access

And voila, bouncer server configured, might want to edit the /etc/mail/sendmail.cf for some timeout values, but that's some general tweaking

Make sure to set a working hostname when installing the server, a DNS A record pointing to the bouncer.domainname.com and a PTR reverse record for the IP it's running on with that same name in it to prevent excessive spam scoring.

[scsi]

Im still kinda confused on what this bouncer actually does...

[Wunk]

Im still kinda confused on what this bouncer actually does...

Prevents your 'real' mailserver being listed on backscatterer.org, a list which is being used as a blacklist by gmail and hotmail.

Any default directadmin install WILL eventually turn up on the backscatterer blacklist due to the mail bounces exim generates.

[dannygoh]

hello,

i believe my server been turn to backscatter. how do i check if my server really been hit. what should i look into email header, body or logs.

[interfasys]

Old thread, but I just wanted to add that the script posted to redirect post, host and abuse to blackhole doesn't work:


#!/bin/sh
FILE=/etc/virtual/$domain/aliases
grep -v '*' $FILE > $FILE.tmp
echo "abuse: :blackhole:" >> $FILE.tmp
echo "postmaster: :blackhole:" >> $FILE.tmp
echo "hostmaster: :blackhole:" >> $FILE.tmp
echo "*: :fail:" >> $FILE.tmp
mv -f $FILE.tmp $FILE
chmod 600 $FILE
chown mail:mail $FILE
exit 0;

The alias file doesn't get chmodded to mail:mail and it makes it impossible for users to change the way the catch-all is acting.

[quadium]

This is a long thread, but it's obviously a relevant issue.

Mail is arriving at my server from a spoofed sender address, then because it's sent to a non-existent address on our end, a Mail Delivery Failure goes out to the spoofed sender... who obviously never sent the e-mail.

It happens to me quite a bit from other people who spoof my address, but I keep getting listed on Backscatterer.org who tell me my mailserver is a pile of garbage.

I disagree with this but being on Backscatterer.org delays all Google (Gmail, Etc) messages to me for several hours before they get delivered. (At least this is what Google is trying to tell me.) I believe they call it greylisted?

It's frustrating and it ONLY affects Google mail services... any idea how to solve THAT problem? Or is Backscatterer.org trying to get us to turn off all returned messages and leave the other end not knowing that their message was sent to a non-existent e-mail address.

To be fair, we also have several Exchange boxes that Gmail does this too as well... which is really starting to tick both me and the end users off...

[nobaloney]

The latest version of SpamBlocker powered exim.conf file for DirectAdmin, Version 4 probably will fix the issue; it has for most (if not all) of us.

You can find it here (http://www.nobaloney.net/spamblocker.html) (nobaloney.net).

If for some reason you don't want to switch to Version 4, you can always figure out the changes and make them to the version you are using.

Jeff