backscatter issue with exim config??

empowering

Verified User
Joined
Aug 2, 2005
Messages
169
Location
New York
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:

Code:
2008-11-25 02:17:11 1L4sAZ-0007AJ-Al <= [email protected] 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 <[email protected]> for [email protected]
2008-11-25 02:17:12 1L4sAZ-0007AJ-Al ** [email protected] F=<[email protected]> 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 [email protected]
2008-11-25 02:17:12 1L4sAZ-0007AJ-Al Completed

The [email protected] 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.

Code:
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 [email protected]
2008-11-25 02:17:17 1L4sAa-0007AN-0V => [email protected] 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
 
Last edited:
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:
Code:
# 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
 
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.
 
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.
 
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?
 
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
 
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
 
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. :)
 
I previously wrote:
jlasman said:
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
 
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
 
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 [email protected]. 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#:
Code:
$ 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:
Code:
whois 67.112.189.210

In which case you can just block :).

Jeff
 
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
 
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
 
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
 
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
 
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
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:
Code:
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
 
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
 
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
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:
Code:
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?
 
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
 
Back
Top