SpamBlocker 3.2.6-RC now ready for testing

Jeff,

[RESOLVED DISREGARD]

Just noticed this in comparison to the 3.0 I have been using. This new config is making two calls to spamd for some reason or another, whereas the old one only made one. This one makes one as user nobody then one as the actual user. That could be a little stressful on a production server. Any ideas what could be causing it?

May 24 15:02:45 persephone spamd[60268]: spamd: connection from localhost [127.0.0.1] at port 60692
May 24 15:02:45 persephone spamd[60268]: spamd: setuid to nobody succeeded
May 24 15:02:45 persephone spamd[60268]: spamd: checking message <087401cafb8c$dd499260$97dcb720$@com> for nobody:65534
May 24 15:02:46 persephone spamd[60268]: spamd: clean message (-0.0/5.0) for nobody:65534 in 0.8 seconds, 7236 bytes.
May 24 15:02:46 persephone spamd[60268]: spamd: result: . 0 - SPF_PASS scantime=0.8,size=7236,user=nobody,uid=65534,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=60692,mid=<087401cafb8c$dd499260$97dcb720$@com>,autolearn=ham
May 24 15:02:46 persephone spamd[60267]: prefork: child states: II
May 24 15:02:46 persephone spamd[60268]: spamd: connection from localhost [127.0.0.1] at port 55102
May 24 15:02:46 persephone spamd[60268]: spamd: setuid to petpimps succeeded
May 24 15:02:46 persephone spamd[60268]: spamd: processing message <087401cafb8c$dd499260$97dcb720$@com> for petpimps:1012
May 24 15:02:46 persephone spamd[60268]: spamd: clean message (0.4/2.0) for petpimps:1012 in 0.8 seconds, 7258 bytes.
May 24 15:02:46 persephone spamd[60268]: spamd: result: . 0 - AWL,SPF_PASS scantime=0.8,size=7258,user=petpimps,uid=1012,required_score=2.0,rhost=localhost,raddr=127.0.0.1,rport=55102,mid=<087401cafb8c$dd499260$97dcb720$@com>,autolearn=ham
May 24 15:02:46 persephone spamd[60267]: prefork: child states: II

BigWil
 
Last edited:
I have no idea. But I'll check into it.

In which logfile do you see this? If I have to do something to enable the logfile, what do I have to do?

Which RC are you using?

Jeff
 
Disregard Jeff. The unexplainable has occurred and the issue isn't there anymore.

BigWil
 
Also, you can probably remove cbl.abuseat.org as its part of PBL which is part of zen.spamhaus.org. You also may want to consider adding the barracudacentral reputation blocklist.

On our setup, spamcop and spamhaus capture 90% of the RBL blocks and Barracuda an additional 8-9%.

Josh
This has been mentioned before :). 2 lists need to be removed as they are already covered by zen.
BRBL is a great list, especially if you want to save $250/y in Spamhaus fees. BTW, this should be mentioned in the Spamblocker documentation.
 
Disregard Jeff. The unexplainable has occurred and the issue isn't there anymore.
I'd like to, BigWil; it's easier on me. But then what do I make of that post you've since deleted? Was there an error in your logic?

Thanks for any clarification you can supply.

Jeff
 
This has been mentioned before :). 2 lists need to be removed as they are already covered by zen.
Thanks for updating me; I'll fix this. After all, it's a bug, not a feature.
BRBL is a great list, especially if you want to save $250/y in Spamhaus fees. BTW, this should be mentioned in the Spamblocker documentation.
I'm not sure what I should mention. That you can save $250? I'm not sure we need to give reasons.

Jeff
 
I'd like to, BigWil; it's easier on me. But then what do I make of that post you've since deleted? Was there an error in your logic?

Thanks for any clarification you can supply.

Not exactly sure and that's why I was trying to not confuse any future readers. That segment I can't even track down. I have searched my own archives and still can't find it. Thus I thought it came into play from RC6. However, looking over RC6 I don't see it in there either. So the "unexplainable" occurred. If that piece didn't look familiar then yah you can write it off as an error in my logic.

BigWil
 
There's still an issue in this version with the spamassassin logic. Currently messages are checked by SA if there is no 'X-Spam-Flag:' header. However we've seen a recent rise of incoming spam messages with this header already set so they bypass the spam filter and leads to complaints from customers.

Maybe we should remove these headers on incoming messages right before they are passed through spamassassin? Any other suggestions?
 
There a spam mails scored with 102.7 points which drops to my inbox directly although I set it to send spam mails to spam folder and above 15 points to delete automatically. Is this problem causes by spamassassin or exim? How can I fix?
 
Currently messages are checked by SA if there is no 'X-Spam-Flag:' header. However we've seen a recent rise of incoming spam messages with this header already set so they bypass the spam filter

Cyril,

I don't think that is an accurate statement. I can send emails from one of our servers to another and they get scanned. I know for a fact that the X-Spam-Flag: header element is being set on server_1 and when it comes into server_2 it is scanned again by spamassassin there.

I think you need to look into other reasons that the receiving server isn't scanning. Some thing I have already noted that Jeff might want to adjust is this in the spamcheck_director. I have set ours to 200k instead:

Code:
{<{$message_size}{100k}} \

I have noticed that many marketing companies are adding keywords and elements and sending in both HTML and plaintext in order to make their spam greater than 100kb. One company is sending stuff out in the 275kb range even so I am thinking that they may have caught on to this.

Of course you will not know if a message was skipped or not unless you add something of this nature like I did right below acl_check_message. This tells me if it was skipped and what machine skipped it:

Code:
warn message   = X-Spam-Flag-Size: Skipped scanning on $primary_hostname; size greater than 200KB
  condition      = ${if >={$message_size}{200k} {1}{0}}

Hope that is helpful.

BigWil
 
I think you should mention in Spamblocker that using the Spamhaus RBLs is not free and requires a yearly subscription.
http://www.spamhaus.org/organization/dnsblusage.html
I've ready their TOS and I believe we comply with it. Please follow my logic.

Here, specifically is what your link says:
If you do not fit all three of these criteria then please do not use our public DNSBL servers, instead see 'Professional Use'.
We do NOT use their public DNSBL servers. We look up a zone in our upstream's nameserver? Semantic? Maybe. Maybe not. I tend to follow the rules rather than try to understand why they were written.

But my resolvers (the nameservers listed in /etc/resolv.conf) are big commercial companies such as Google, OpenDNS, etc., and since they're the ones who may be actually using the Spamhaus servers for lookups, they're the ones that actually qualify.

Remember how DNS works? Once the lookup is made by the resolving server, it's kept in memory until it expires.

My understanding is that if I don't run my own resolving servers there's no way I can use Spamhaus servers directly. Unless I do forwarding of DNS queries.

I don't host resolving DNS servers, and I don't forward. So I don't require a paid license.

That's exactly what their terms say.

Perhaps I should put a disclaimer into the file itself, but you may be surprised when you see the actual release file; it will have almost NO comments; all comments will be in a separate file. So maybe the warning belongs in the separate file.

But honestly, will most people understand what I've pointed out?

If you disagree with me please feel free to do so, and to explain your argument to me here.

Jeff
 
I think the best way to check your theory would be to ask them directly. The problem I see with it is that if everybody is using Google DNS, then in effect, Google becomes a sponsor of Spamhaus as it pays larger and larger fees because more and more people are using their DNS. Until they cut you off or ask you to participate because you're making 500 000 requests a day.
Spamhaus doesn't mention resolvers, etc. in their TOS. They don't go technical at all.
To me it reads: "If you use dnlist = zen.spamhaus.com in your exim.conf file and you're an ISP, then you should get a subscription".
In their example, they mention that a spam filtering appliance needs a license. Obviously, such a device would be talking to resolvers and yet, they want money if you use the RBLs.
 
Code:
# deny if the HELO pretends to be one of the domains hosted on the server
    deny message = Bad HELO - Host impersonating domain name [$sender_helo_name]
        condition = ${if match_domain{$sender_helo_name}{+local_domains}{true}{false}}
        hosts = ! +relay_from_hosts

Jeff,

I think your +relay_from_hosts used here is supposed to be +relay_hosts. Simple deduction because relay_from_hosts is never defined only relay_hosts is. I believe this was pointed out in a previous thread as well.

Unless it was meant to be like that for some reason. Dunno.

BigWil
 
@BigWill:

Thanks for bringing this to my attention. I'll fix it in the final release.

@interfasys,

The reality is of course that (not quite, but to some reasonably large extent) everyone is using Google DNS or OpenDNS.

And SpamHaus has no way of checking to who the requests from Google are really from. Which means that only Google is in a position to see who's checking against Spamhaus DNS. It also means that whether or not you pay, SpamHaus may still cut you off by cutting off Google. They can't guarantee they'll continue serving you through Google (for example)...

So if you do decide to pay Spamhaus you're either hoping they'll keep serving Google, or you're setting up your own authoritative server and using rsync. And hoping no one finds your server and misuses it.

And of course with the amount of spam being checked, it's unlikely that one request from isn't being used by hundreds of servers, perhaps thousands or even more.

Are you saying that SpamHaus, who presumably know quite a bit about how DNS works (at least I'd think so) wrote something in their TOS other than what they mean?

In the final release SpamHaus will be in a separate stanza, and it will be commented out by default.

But of course that means that some lists otherwise included in Spamhaus will need to be listed individually.

Any server operator is welcome to (and probably should) clarify the SPamhaus TOS directly with the company if they're not sure they understand it.

Jeff
 
I just got this one. I'm quite puzzled how this can happen. The hostname is changed, but I can assure you the ip resolves to server.domain.tld and there's no typographic error in one of them.

H=server.domain.tld [123.123.123.123] rejected EHLO or HELO server.domain.tld: Bad HELO - Host impersonating domain name [server.domain.tld]
 
Since you've changed everything you've removed all the clues we could use to help you. You can assure us of all you want, but you'll have to fix it yourself if you're not willing to give us unadulterated information so we can test.

As of right now all I can to help you is tell you that since server.domain.tld doesn't resolve to 123.123.123.123, your server did what it was supposed to do.

Oh, you've already told us that. See above.

Jeff
 
When I have sender verify enabled I'm getting this pretty often

Could not complete sender verify

Would it be possible if after 5-10 seconds there is no reply it proceeds along in the checks? Rather than failing?

It seems that when this happens the remote server is bouncing a message to sender that the email was undeliverable.
 
Most of us leave sender verify disabled.

What would be the point of continuing after a few seconds? Do you have some kind of empirical proof that spammers stop trying and that good guys keep waiting? If that's not the case, then waiting won't do anything.

Jeff
 
Back
Top