Last Call for Requests

nobaloney

nobaloney

NoBaloney Internet Svcs - In Memoriam †
Joined
Jun 16, 2003
Messages
26,113
Location
California
The final RC for SpamBlocker Version3 will be released by Monday and the final release will be made by me at my website within a week.

So this is the last call for anything you think must be included.

Anything that doesn't make it into this version will be considered for the next version.

Once SpamBlocker Version3 is available from my website I'll notify DirectAdmin staff so they can decide to use it if they wish as the default exim.conf file.

Jeff

Please post any replies to this thread rather than start another.

Thanks.

Jeff
 
I'll check back here some time tonight to see if there are any posts; otherwise the final RC will be ready by some time tomorrow (PDT [-0700]).

Jeff
 
It's working GREAT for us. Installed the latest candidate and saw an immediate and massive reduction of spam. Thank you. Thank you. Thank you.
 
SpamBlocker3 is not yet on the DirectAdmin site. The version on my site (nobaloney.net) is not the final release candidate, which will be very different, and hopefully even better.

Unfortunately it's not done yet; it turns out it's a bit more complex than I thought.

Jeff
 
Well, if it were easy, I wouldn't have to ask for help, then, would I ;)?

The final release candidate has been on my site (see URL above) for almost 20 hours; it's still appearing to work very well for me. The delay was mostly in getting the documentation even semi-available.

It should be gold some time this week, after I get some user reports that it's working for others as well without any issues.

Jeff
 
The Final Release Candidate is still working well for me on multiple servers. It's blocked a lot of spam, but still requires help from Spam Assassin and from Spam Filters. We're very happy with it, and unless someone posts some unforseen problem or I see a problem through the weekend, I'll probably release it as Version 3.2 some time Monday.

Then it'll be up to John and Mark to decide whether or not they make it a part of DirectAdmin. They can only do that if they either phase out support for mbox email (probably no longer allowing it on new installs) or rewrite it to work with mbox, since I no longer support mbox.

Jeff
 
Hello Jeff,
Did you take my recent request into consideration?
The one that asks for Spamblocker to block/filter emails sent from a local user when it's not being sent from the local server.
The problem right now is that if the address is local, the message doesn't go through the filters.
Cheers,
 
If you didn't post it in this thread and get a reply from me, then you cannot expect it to be included. Please post it in this thread. If you do it today and it's very simple, it could still get in; if it requires extensive testing, if it doesn't work by default for everyone, or if I don't understand it, then it won't make it; I want to go gold on Version 3 this week.

Please also post a link to your original suggestion.

Jeff
 
OK. I mentioned it in another thread.

Basically, if a user has an email address like [email protected] and a spammer uses it in the From field, Exim just doesn't do any tests on the email, It assumes it is safe and stores it.
So if your name is John and the spamers use a list of known first names, then you will get lots of spam that go through.

I'd like to see a condition/test where Exim actually checks that emails being sent from a known local address are really being sent by a local user.
I guess the alternative would be to have a switch that disables that local user whitelisting.

Does it make sense?
 
I have been getting hit with the back scatter from massive joe jobs about twice a week (usually Monday and Friday). I am running RC1 and things seemed to be working OK until today. Around noon EST today, I got blasted with another round but this time the back scatter ended up in the queue - a sample log entry is:

2009-07-28 12:24:34 217.19.237.55 whitelisted in list.dnswl.org
2009-07-28 12:24:34 1MVpTe-0008JL-Ep <= <> H=mx.mailprotect.be [217.19.237.55] P=esmtp S=3366 [email protected] T="Undelivered Mail Returned to Sender" from <> for [email protected]

These are intermixed with lots and lots of "rejected RCPT" messages. As far as I can tell at this point, all 3K items that ended up in the queue got there via the dnswl.org whitelist (many, many IPs)! Apparently there is no RCPT check after a white-list hit??? If so, that is a big problem....
 
interfasys said:
Basically, if a user has an email address like [email protected] and a spammer uses it in the From field, Exim just doesn't do any tests on the email, It assumes it is safe and stores it.
So if your name is John and the spamers use a list of known first names, then you will get lots of spam that go through.
Click to expand...
I've just checked the code in SpamBlocker Version 3.2; it shouldn't do that unless you've either put [email protected] or domain.com into one of the whitelists. You should Never put local domains or email addresses into whitelist; I've said before that this opens your system to being used as a spam relay. Whitelists are a way to accept email from others who otherwise would be blocklisted.
I'd like to see a condition/test where Exim actually checks that emails being sent from a known local address are really being sent by a local user.
Click to expand...
Our exim.conf file does NOT whitelist local users' email addresses by default.
I guess the alternative would be to have a switch that disables that local user whitelisting.
Click to expand...
Local addresses are NOT automatically whitelisted unless they originate on the server or they're authenticated.

Jeff
 
gaw said:
As far as I can tell at this point, all 3K items that ended up in the queue got there via the dnswl.org whitelist (many, many IPs)! Apparently there is no RCPT check after a white-list hit??? If so, that is a big problem....
Click to expand...
Whitelists are just that; they do an immediate accept. For more information read exim.org; look for documentation on ACLs (Access Control Lists).

I tested the dnswl.org list for about a half year without issues and I still believe in it; of course there may be problems from time to time.

However you don't have to use it; you can comment out that particular ACL and restart exim.

For those who don't know, the dnswl.org list is a list of mailservers supplied by ISPs and others; in other words official mailservers of reputable organizations. We use this list so we don't get as many false positives. However you can certainly comment it out and restart exim to avoid using it.

You can contact those reputable organizations sending you those bounces; they shouldn't be.

Or you can block based on the RFC-Ignorant list before you accept based on the dnswl.org whitelist. We don't recommend this because you'll block an awful lot of email you really want.

Or you can create your own rule for blocking all emails from outside with null senders. We don't recommend this because (a) it's against RFCs and (b) it will keep your server from getting legitimate bounces as well.

I'm not sure if you're describing a joe-job or not; if a joe-job, then the email should be going to your users, not the queue. More logically to me it's a reply to email coming from servers who identify us as the sending server, but with their own from-address.

If you have any suggestions as to how to fix your problem, I'd like to see them; I haven't found anything I can easily do that will work for everyone.

Remember no exim.conf file, not even SpamBlocker Version 3.2, is all things for all people.

Jeff
 
Thank you Jeff. I did find the email address I was thinking about in a whitelist...Should be all good now. Testing 3.2 RC.
 
A NDR with from "<>" bounces when the From address is a non-existent mailbox as long as the sender is not in dnswl.org. AFAIK that is the desired behavior because the RFC only requires you to accept mail from "<>" if the NDR is to someone who sends mail. In this case, the NDR recipients are all non-existent (i.e. F=<> R="virtual_aliases" and hence frozen). Technically this is not a "joe job" because each message was sent with from a valid domain with a randomly generated mailbox name.

Since dnswl.org contains "reputable organizations" like google and facebook, it is absolutely suicidal to accept mail solely on a hit in a public white list - my last incident was 33k messages arriving within 1 hour and white listing let in roughly 10% - you better believe dnswl.org was disabled!

But don't get me wrong, with the above exception, the RC has worked very well. Actually, the beta was not bad either - I turned to that after the first incidents left my mail queue a mess. Thank you jeff!

One last note, if you use dnsawl.org you may find the following useful someday:

exim -bpru | grep "*** frozen ***" | awk {'print $3'} | xargs exim -Mrm > deleted-frozen.txt
 
I left the other public white list (hostkarma.junkemailfilter.com) to see if the problem was just dnswl.org. Answer came with this mornings 1GB of trash : 4k messages about 400 whitelisted by hostkarma. So it is gone too.

Sample headers from one of the hostkarma whitelisted messages shown below. There is no [email protected] so this crap ends up frozen - you still think public white lists are viable?

1MWWEy-0001SN-L2-D
This is a MIME-formatted message.
Portions of this message may be unreadable without a MIME-capable mail program.

--9B095B5ADSN=_01CA10A05BBD7E3C00006573lsvrexch.sandler
Content-Type: text/plain; charset=unicode-1-1-utf-7

This is an automatically generated Delivery Status Notification.

Unable to deliver message to the following recipients, due to being unable to connect successfully to the destination mail server.

[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]




--9B095B5ADSN=_01CA10A05BBD7E3C00006573lsvrexch.sandler
Content-Type: message/delivery-status

Reporting-MTA: dns;lsvrexch.sandlerseating.com
Received-From-MTA: dns;192.168.1.247
Arrival-Date: Tue, 28 Jul 2009 15:01:08 +0100

Final-Recipient: rfc822;[email protected]
Action: failed
Status: 4.4.7

Final-Recipient: rfc822;[email protected]
Action: failed
Status: 4.4.7

Final-Recipient: rfc822;[email protected]
Action: failed
Status: 4.4.7

Final-Recipient: rfc822;[email protected]
Action: failed
Status: 4.4.7

Final-Recipient: rfc822;[email protected]
Action: failed
Status: 4.4.7

Final-Recipient: rfc822;[email protected]
Action: failed
Status: 4.4.7

Final-Recipient: rfc822;[email protected]
Action: failed
Status: 4.4.7

Final-Recipient: rfc822;[email protected]
Action: failed
Status: 4.4.7

Final-Recipient: rfc822;[email protected]
Action: failed
Status: 4.4.7

Final-Recipient: rfc822;[email protected]
Action: failed
Status: 4.4.7

--9B095B5ADSN=_01CA10A05BBD7E3C00006573lsvrexch.sandler
Content-Type: message/rfc822

Received: from 192.168.1.247 ([192.168.1.247]) by lsvrexch.sandlerseating.com with Microsoft SMTPSVC(6.0.3790.3959);
Tue, 28 Jul 2009 15:01:08 +0100
Received: from 18924032068.user.veloxzone.com.br[189.24.32.68] by mail.sandlerseating.com;
28-Jul-2009 15:02:12 +0100
Date: Tue, 28 Jul 2009 11:01:39 -0300
Message-Id: <[email protected]>
sender:<[email protected]>
From: Kurt Godwin <[email protected]>
To: [email protected]
Subject: conquer the impossible, look great today
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
return-path:<[email protected]>
X-OriginalArrivalTime: 28 Jul 2009 14:01:08.0796 (UTC) FILETIME=[DB525FC0:01CA0F8B]
 
Last edited:
You must log in or register to reply here.
Back
Top