SpamBlocker3 exim.conf file now ready for Beta testing

Status
Not open for further replies.
I could not test if using RBL's would actually send backscatter.

My theory is that if email gets forwarded from server1 to server2 and server2 rejects it because server1 is blocklisted what does server1 do? Will it send it back to the possibly faked from address?
 
floyd said:
But upon further meditation I found that using RBLs could probably cause backscatter as well.

I was not able to test it at the time because I did not have any blocklisted ip's.
Click to expand...

As soon as I removed the RBL function I stopped being labeled as a backscatterer....but of course the amount of spam coming in has increased dramatically.

maybe we need a user option

Engage anti-spam measures and not be able to send emails to many systems
or
Insure that mail can be sent to many systems and accept spam
or
Send money to backscatter scam headquarters to be unlisted because
both options above are unacceptable.

Thom
 
It doesn't have to be that way, Thom. If I'm on any backscatter lists, I don't know it; how would I find out. And I use RBLs very aggressively.

How can I find out if I'm on backscatter lists?

If someone would be kind enough to write out either just pseudocode, or an actual old-fashioned flow-chart of how anti-backscatter should work, please do so (fast :)) and I'll get to work on it.

Jeff
 
jlasman said:
How can I find out if I'm on backscatter lists?
Click to expand...
http://www.backscatterer.org/index.php?target=test

And if you do get on their list, here's the bad news:

The listing will expire automatically and free of charge 4 weeks after the last abuse is seen from that IP.
Expedited manual expressdelisting is available as an option, in case you do not want to wait for the automatic and free expiration.
You will be charged 50 Euro's using one of the following payment services.
WARNING: Before requesting expressdelisting make sure the problem which caused the listing is fixed, otherwise you are at risk to get listed again if new abuse becomes known.

So it would appear that every server they list is a potential source of income.
 
gerrybakker said:
Perhaps setting up "Safe Mode" as per this page http://www.backscatterer.org/?target=usage would help. They seem to have Exim specific instructions to implement it.
Click to expand...

But isn't that safe mode for people who use their database...rather than those who are sending mail?

It seems that the major sin in their eyes is bouncing mail if the bounce messages are in response to those that have MAIL FROM: is <> or postmaster only.

Thom
 
Here is an example of backscatter:

2010-02-24 08:12:23 1NkH2N-0006N2-O0 <= [email protected] H=pool-74-110-232-248.rcmdva.east.verizon.net ([192.168.0.98]) [74.110.232.248] P=esmtp S=651 [email protected] T="test" from <[email protected]> for [email protected]
2010-02-24 08:12:24 1NkH2N-0006N2-O0 ** [email protected] F=<[email protected]> R=lookuphost T=remote_smtp: SMTP error from remote mail server after RCPT TO:<[email protected]>: host mail.biblefinder.com [74.117.232.12]: 550 "Unknown User"
2010-02-24 08:12:24 1NkH2N-0006N2-O0 Completed

2010-02-24 08:12:24 1NkH2O-0006N5-S4 <= <> R=1NkH2N-0006N2-O0 U=mail P=local S=1604 T="Mail delivery failed: returning message to sender" from <> for [email protected]
2010-02-24 08:12:26 1NkH2O-0006N5-S4 => [email protected] F=<> R=lookuphost T=remote_smtp S=1647 H=f.mx.mail.yahoo.com [98.137.54.237] C="250 ok dirdel"
2010-02-24 08:12:26 1NkH2O-0006N5-S4 Completed
Click to expand...

The recipient server rejected the email because of unknown user. The sending server delivered the bounce to the faked sender address.

The sending server should only be allowed to deliver bounces to email that it sent to a local user.

The concept is simple. How to implement it I have no idea. Sorry.

Maybe if it is "from <>" it can only be delivered to local domains. But then how do legitimate senders get bounces on another server?
 
Last edited:
I think what needs to be done is first determine policies or logic and let each admin determine what he wants his policy to be.

Policy 1: Prevent backscatter. This would mean that if an email sent from server1 to server2 and then server2 forwards it to server3 and server3 rejects the email then server2 must at that point simply drop the email since it cannot possibly return it to the sender since the sender From address cannot be trusted. Nobody gets the rejection notices.

Policy 2: The From address gets rejection notices. This is how it is set up now and potentially creates backscatter. But legit senders get the notices

Backscatter is aka unsolicited bounces.

I do not know of any way for the server in the middle to return the rejection to the original ip, server1, since is past the initial stage of accepting the email from server1.
 
I also see that by default exim accepts email for postmaster@ and then later tries to return it to the forged email address.

This might be technically correct for RFC however if the mail is being returned then it is obviously not getting to the intended recipient and being read. So what is the point of accepting it and then bounce it?

Don't accept mail for anybody unless it is possible to be delivered.
 
floyd said:
I also see that by default exim accepts email for postmaster@ and then later tries to return it to the forged email address.

Don't accept mail for anybody unless it is possible to be delivered.
Click to expand...

But that doesn't solve the problem of mail coming in to a real address on the server that's "from" a fictional address.....if we detect it and bounce it, we're contributing to the pollution.

Me thinks the RFC needs to be rethought.

Thom
 
tlchost said:
But that doesn't solve the problem of mail coming in to a real address on the server that's "from" a fictional address.....if we detect it and bounce it, we're contributing to the pollution.
Click to expand...

If its sending to a real local address it should not bounce.

The problem with bounces is when email is forwarded on to another server and that server rejects the email and then the server in the middle then bounces the email to the forged From address. I have not figured out a way to disable bounces yet.

Remember a bounce is different than a rejection.

if we detect it and bounce it, we're contributing to the pollution.
Click to expand...

Detect what?
 
floyd said:
Policy 1: Prevent backscatter. This would mean that if an email sent from server1 to server2 and then server2 forwards it to server3 and server3 rejects the email then server2 must at that point simply drop the email since it cannot possibly return it to the sender since the sender From address cannot be trusted. Nobody gets the rejection notices.
Click to expand...
Okay. How do I do it? Anyone?
Policy 2: The From address gets rejection notices. This is how it is set up now and potentially creates backscatter. But legit senders get the notices
Click to expand...
There is a way to do this, and still avoid backscatter: simply don't accept mail unless the sender can receive email; check first. The problem is that this breaks the ability to accept a lot of automated email. So it'll never be a standard for anything I produce.

My bottom line is if someone will do the analysis on exactly how to do it I can convert it into exim.conf code.

Jeff
 
I will state it here too. We need to handle the addresses postmaster, hostmaster, and abuse differently now. We cannot allow exim to accept them and then not be able to deliver to them. I now believe this is how most of the backscatter is generated. Exim accept the email but finds it cannot deliver it and then has no choice but to issue a bounce to the probably forged From address.
 
I think you're right; I've been considering this for the last few days. It's time to look at changes to the RFC-mandated email addresses.

I've been setting up the addresses for all my clients as part of setting them up on the server. Should they instead be forwards to the admin account?

Jeff
 
Status
Not open for further replies.
Back
Top