SpamBlocker 3.2.4-RC now ready for testing

Status
Not open for further replies.
Jeff,

Have you solved the backscatter problems yet? I recognize it isn't all in your court to solve but I was hoping that it was finally solved. It is becoming such a big issue with our clients. An expensive issue.

It just takes one errant backscatter email to backscatter.org and you have to pay them 50 Euros to get off of their list or you end up having emails blocked to gmail accounts and others. I have 500 + sites per server and one backscatter listing effects all of those sites on a shared server.

John @ DirectAdmin - wasn't Jeff waiting for some help from you on this? Please get together and solve this backscatter issue once and for all. It is costing us all a lot of money. I'd throw some cash at this to pay Jeff and John to finally fix this - anybody else willing to contribute cash to push this forward - we've been talking about backscatter problems for a few years.
 
I haven't had time to revisit this in quite a while. I'm going to revisit the entire exim.conf file by early March at the latest.

Jeff
 
gerrybakker said:
John @ DirectAdmin - wasn't Jeff waiting for some help from you on this? Please get together and solve this backscatter issue once and for all. It is costing us all a lot of money. I'd throw some cash at this to pay Jeff and John to finally fix this - anybody else willing to contribute cash to push this forward - we've been talking about backscatter problems for a few years.
Click to expand...

I think backscatter.org is scamming a lot of people with their removal fee. That being said, I hope DA can either help Jeff fix the problem, or fix it themselves...as I'm beginning to loose customers who loose money when their email bounces.

At 50 buck a removal and lost customers, it won't take too long to view the hosting business as a non-profit, but the IRS won't let me get away with that.

I would think that if other control panels don't have this problem, DA might want to fix it just to preserve sales.

Thom
 
I'm revisiting exim.conf this weekend. If I can find on these forums or on exim forums, how to easily resolve the problem and still stay RFC compliant, my new version of exim.conf will resolve the problem.

If not, then it won't.

Jeff
 
Some answers:

I've rewritten the Mailer-Daemon code today:
Code: 
 # Mailer-Daemon messages must be for us
    accept senders = :
           domains = +relay_domains
This will probably work and should solve the backscatter problem as it won't accept Mailer-Daemon messages for domains not hosted by the server. It's possibly oversimplified, but it came recommended on Exim mailing list :).

Jeff
 
Last edited:
interfasys said:
# deny if the HELO pretends to be one of the domains hosted on the server
drop message = Bad HELO - Host impersonating [$sender_helo_name] R2
condition = ${if match_domain{$sender_helo_name}{+local_domains}{true}{false}}
hosts = ! +relay_from_hosts
Click to expand...
I don't like the above because it means a user can't use a different server for outgoing email. So I'm not including it.
This is to add in the acl_check_recipient acl because we need to skip authenticated users
Code: 
  # deny if the HELO is neither a FQDN nor an address literal
  drop message = HELO should be a Fully Qualified Domain Name or an address literal (See RFC2821 4.1.1.1) R1
      !authenticated = *
      condition   = ${if match{$sender_helo_name}{\N^\[\N}{no}{yes}}
      condition   = ${if match{$sender_helo_name}{\N\.\N}{no}{yes}}

  drop message = HELO should be a Fully Qualified Domain Name or an address literal (See RFC2821 4.1.1.1) R2
      !authenticated = *
      condition   = ${if match{$sender_helo_name}{\N\.$\N}}

  drop message = HELO should be a Fully Qualified Domain Name or an address literal (See RFC2821 4.1.1.1) R3
      !authenticated = *
      condition   = ${if match{$sender_helo_name}{\N\.\.\N}}

I've removed this from Spamblocker:
Code: 
  # RC 3.2.3  05-sep-2009 deny all unauthenticated if Helo not FQDN
  deny hosts   = !+relay_hosts 
       message = HELO should be Fully Qualified Domain Name  Host.Domain.Tld  See RFC821
       !authenticated = *
       condition =  ${if !match\
                     {$sender_helo_name}\
                     {\N.*[A-Za-z].*\..*[A-Za-z].*\N}\
                     {yes}{no}}
Click to expand...
I've not made the above change. Is there an important reason I should?

EDIT... I SEE THE PROBLEM NOW; SEE MY ADDITIONAL RESPONSE BELOW

So far, I see a lot of RFC2821 4.1.1.1 compliant messages being rejected. I need to do more testing with exceptions to be able to tell if it's working a 100%.

Edit: Uncommented the domain checker
Edit2: Split the checks in 2 ACLs in order to be nice to Outlook clients...
Click to expand...
I hope your original post is up-to-date; I'm depending on it :).

Jeff
 
Last edited:
interfasys said:
This is to add in the acl_check_recipient acl because we need to skip authenticated users
Code: 
  # deny if the HELO is neither a FQDN nor an address literal
  drop message = HELO should be a Fully Qualified Domain Name or an address literal (See RFC2821 4.1.1.1) R1
      !authenticated = *
      condition   = ${if match{$sender_helo_name}{\N^\[\N}{no}{yes}}
      condition   = ${if match{$sender_helo_name}{\N\.\N}{no}{yes}}

  drop message = HELO should be a Fully Qualified Domain Name or an address literal (See RFC2821 4.1.1.1) R2
      !authenticated = *
      condition   = ${if match{$sender_helo_name}{\N\.$\N}}

  drop message = HELO should be a Fully Qualified Domain Name or an address literal (See RFC2821 4.1.1.1) R3
      !authenticated = *
      condition   = ${if match{$sender_helo_name}{\N\.\.\N}}

I've removed this from Spamblocker:
Code: 
  # RC 3.2.3  05-sep-2009 deny all unauthenticated if Helo not FQDN
  deny hosts   = !+relay_hosts 
       message = HELO should be Fully Qualified Domain Name  Host.Domain.Tld  See RFC821
       !authenticated = *
       condition =  ${if !match\
                     {$sender_helo_name}\
                     {\N.*[A-Za-z].*\..*[A-Za-z].*\N}\
                     {yes}{no}}
Click to expand...
I'm not sure what I'm looking at above, though I know my code doesn't work.

My code doesn't work because of International Domain names not properly matching. Does your code solve that problem?

Do the last two conditions even work? They don't have the {no}{yes} section after them.

I'm trying it today but swapping deny for drop as I like to tell people why we don't like them. I hope it doesn't break anything, and I hope it solves the IDN issue.

Jeff
 
Last edited:
Yes, the code is current and it's working for us.
The first rule (RFC2821 4.1.1.1 R1) works very well (25% of the total numbers of spams, after spamhaus (50%)). The others seem correct but rarely catch anything.

I do have users who use international domain names, but I'm not sure if I can bring a definitive answer to your question. I'll try and do a test this week.

Olivier
 
interfasys said:
I do have users who use international domain names, but I'm not sure if I can bring a definitive answer to your question. I'll try and do a test this week.
Click to expand...
Please let us know. If IDNs fail then no one using an IDN can reach servers which include those tests.

We have found one problem.

Many home networks send email using a helo line of a single word (block of characters). Of course we should block them. The problem of course is they may be our customers. If they are, they'll be contacting us and telling us that email is broken. So now they need to use port 587; they cannot use port 25 anymore. For a few accounts on the same server we use, this has resulted in some calls today.

Jeff
 
webquarry said:
So are all these various scattered code changes available anywhere in a complete exim.conf file? I'm eager and willing to test this but I can't find anywhere the current "golden master" of exim.conf. The latest complete one that I see is at:

http://www.nobaloney.net/downloads/spamblocker/DirectAdminSpamBlocker3/exim.conf.3.2.4-RC
Click to expand...

That link will go away this evening and be replaced by the latest Release Candidate, 3.2.5-RC. You should never try going directly to an RC url; but instead go to:
http://www.nobaloney.net/downloads/spamblocker/DirectAdminSpamBlocker3/
and link from there. So you can also get the ReadMe file. The files there marched as ARCHIVE (including the one above which will soon be marked ARCHIVE) can't be downloaded except by special permission as we've changed their permissions to 000.

There'll be a new announcement in a new thread as soon as the new RC is uploaded.

Jeff
 
If you're using
!authenticated = *
Click to expand...
in the acl_check_recipient acl, then your Outlook users shouldn't be affected. That's the reason I had to split the HELO acl in two.

If a server is connecting to your smtp port, then the hostname will be a fqdn or it's a zombie.
 
It's there. And it blocked two users, at least one of which had a helo component of only capital letters. Once it's posted feel free to look at it in case I've made an error.

I still have no understanding of how it works and that bothers me. Do you understand it?

You see, there's NO accept there, so if it doesn't match the first denys it moves to the seocnd, and then to the third.

And only the first one is checking against no/yes, so I don't see how the others are doing anything. I'd feel a lot better about using this if someone knew what it does.

Should I post it to exim-users?

Thanks!

Jeff
 
Which rule did catch these users?

I've checked, this should work with IDN domain names since it's not checking for the characters themselves, but for dots.
4.1.1.1 R1 checks if there are dots or if it's an IPV6 address
4.1.1.1 R2 makes sure that the hostname doesn't end with a dot
4.1.1.1 R3 checks if there are double dots

Could you check your user's hostname against these rules?
 
Thanks for the clarification. I'll add the documentation to the final RC file, now scheduled for release today my time.

Can you find any clarification in exim documentation on not using the no/yes construction? I'd like to see clarification of that.

I thought I made it clear; the hostnames blocked were all similar to:

XVFBUJX

In other words they should have been blocked. Nevertheless, lots of users have this kind of hostname, and we've never blocked them before. So we're going to see issues from some clients. That's okay with me, but may not be with some admins.

Jeff
 
People should not be blocked if they're authenticated, but maybe Exim doesn't consider people using the DA popb4smtp feature the same?
 
Can you find any clarification in exim documentation on not using the no/yes construction? I'd like to see clarification of that.
Click to expand...
From experience and by reading the mailing list.
In the ACL section, if you just want to know whether a condition is true, you don't need to specify anything.
For R1, the condition is reversed, so we need to generate a "yes" if it doesn't match. The other conditions work normally.

From the shell, you can type the condition directly in Exim and you will see that the result is the same, you get a "true" for a correct value, if that's what you expect. If you specify yes,no, then you'll get a yes. Same result.
 
Authenticated users on port 587 are not blocked. So far we've not been able to get it to work with popb4smtp, and I haven't figured out why; we simply teach our users to use port 587 as the authentication port as it was always meant to be used.

And we always tell new users to use their ISP's outgoing email server if possible.

Jeff
 
Status
Not open for further replies.
Back
Top