backscatter issue with exim config??

Before you blackhole your postmaster address you should probably read this 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.

The default acl for accepting postmaster email posted there is what we use:
Code:
  # 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
 
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' 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
 
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
 
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. 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
 
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.
 
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. 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
 
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
 
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.
 
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 ;)
 
The next version of SpamBlocker will be out before the end of July, to resolve the issue with Sorbs going away.

Jeff
 
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:
Code:
  # 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
 
looks good jeff, I will add it to 1 or 2 servers myself and report back if any problems.
 
Hurry :).

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

Jeff
 
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:
Code:
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 [email protected] to me, during SMTP session my exim connecting to your server and trying "MAIL FROM: <>\nRCPT TO: <[email protected]>", 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.
 
Last edited:
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.
 
Sender adress for bounces is: <>, so I believe correct code will look like:
Code:
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 [email protected] to me, during SMTP session my exim connecting to your server and trying "MAIL FROM: <>\nRCPT TO: <[email protected]>", 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:
Code:
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
 
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.
 
Last edited:
ClayRabbit, you may be on to something...

My construction (repeated here so no-one has to scroll up):
Code:
# 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
 
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).
 
Back
Top