SpamBlocker-Powered exim.conf, Version 4

Modified that one, thanks!

On the HELO problem: Is it possible that Outlook detected by SpamBlocker 3 that it has to login, and doesn't understand the "R1"-error that SpamBlocker 4 returns if Outlook doesn't give any (valid) user credentials?

Because that would explain why the users didn't have to login in SpamBlocker 3, and popb4smtp just worked.
 
I thought I'd responded to this, but it appears that I didn't :(.

No, The R-1 error shouldn't mean anything to Outlook; Exim should return a standard numerical error code before the custom error message, and Outlook should respond to that.

The problem is most likely in the HELO requirement. If you can prove otherwise (remove the HELO requirement and see if popb4smtp works) then we can look at how to make popb4smtp avoid the HELO acl stanza, though I haven't found out how.

Jeff
 
Hi Jeff, I just got help from smtalk to install SpamBlocker4 and it works just fine in every way but in Horde webmail client in which email cant be sent.
I get the error listed below:
Failed to add recipient: [email protected] [SMTP: Invalid response code received from server (code: 550, response: R1: HELO should be a FQDN or address literal (See RFC 2821 4.1.1.1))]

It worked before SB4 was installed. :confused:
 
Last edited:
As stated in my message: R1

It is the following lines in the config that throws the error:
# 1st deny checks if it's a hostname or IPV4 address with dots or IPV6 address
deny message = R1: HELO should be a FQDN or address literal (See RFC 2821 4.1.1.1)
!authenticated = *
condition = ${if match{$sender_helo_name}{\N^\[\N}{no}{yes}}
condition = ${if match{$sender_helo_name}{\N\.\N}{no}{yes}}

When those were commented out it works again.
 
This means that Horde is connecting via smtp on port 25 and isn't sending a fully qualified hostname. You can either set Horde to connect through the sendmail interface rather than via smtp, or comment out that particular check.

Jeff
 
Thanks for Your answer Jeff.
I have commented those lines out and it works now.
How does that affect SB's actions in stopping SPAM ?

Mats
 
You'll be receiving more Spam. My recommendation would be to set Horde to connect through the Sendmail interface instead. However I don't know how to do that.

Jeff
 
Backscatter?

So am I correct in assuming that this version handles the backscatter problem that DA has?
 
It should solve the backscatter issue. If not, I'll continue to work on it, but I've gotten no report as of yet that backscatter is still an issue.

Jeff
 
I can confirm that the previous version 3 of spamblocker solved the backscatter issue. I just wanted to confirm that those bit were still present in v4. I'll give it a try. Thanks for your efforts on this. :):):)
 
SpamBlocker 3 was the beta for SpamBlocker Powered exim.conf, Version 4. I did not intentionally make any changes which would disable the backscatter solution. I'm anxiously awaiting your confirmation.

Jeff
 
Question regarding Edit #38 (require verify = sender)

Hi, I have been preparing to upgrade from SpamBlocker 2.0 to SpamBlocker 4.0 and have a question about the section that pertains to Edit #38 in regards to Sender Verification. The instructions in the ReadMe say that "by default we do NOT require sender verification" and then goes on to say to "comment out" the line if you do not want to require sender verification.

When I look at supplied exim.conf I see this...
Code: 
#EDIT#38:
require verify = sender

If the default behavior is to NOT require sender verification as the ReadMe states then shouldn't this line be commented out by default? Or am I misunderstanding something completely here. I went through my 2.0 exim.conf file and in that file the line is commented out which I believe was the default behavior.
 
Error in the ReadMe file; I'll change it today. It should read that by default we DO require sender verification.

Jeff
 
I just want so say THANK YOU!

Your Spamblocker Exim.conf, has pretty much taken care of my spam I get on my server.

Its actually doing better then Google's Postini service!

Again THANK YOU!
 
Hi, after the change to spamblocker 4 some customer reported me this kind of error:

2010-10-20 12:04:52 H=(PC4) [151.xxx.xxx.xxx] F=<[email protected]> rejected RCPT <[email protected]>: R1: HELO should be a FQDN or address literal (See RFC 2821 4.1.1.1)

As stated in my message: R1

It is the following lines in the config that throws the error:
# 1st deny checks if it's a hostname or IPV4 address with dots or IPV6 address
deny message = R1: HELO should be a FQDN or address literal (See RFC 2821 4.1.1.1)
!authenticated = *
condition = ${if match{$sender_helo_name}{\N^\[\N}{no}{yes}}
condition = ${if match{$sender_helo_name}{\N\.\N}{no}{yes}}

When those were commented out it works again.
Click to expand...

Suggest to use this as temporary solution to this issue, there is another solution or awaiting a final solution?

Thanks
 
The problem which has been discussed several times already, is that unless the user logs in using plain-text authentication on port 587, the ACL you quote will block email unless the sending system uses a qualified domain name as part of the helo protocol.

The proper way to submit email from an mua (such as outlook, etc.) is by using port 587 and plaintext authentication. If you don't want to require that of your users then you'll need to comment out that section. You can consider it a temporary solution if you intend to have your users use the proper protocol but want to give them time to make the change. Or you can leave it commented out forever and accept that your system(s) will get more spam.

Jeff
 
We changed from SpamBlocker 2.1.1 to 4 and it works great!
I want to share some thoughts.

1. Some time ago we had a problem (2 times, different servers) that ClamAV stopped working. It wasn't running anymore and therefore every incoming mail was denied! This happened with 2.1.1 but I expect the same effect with the newest SpamBlocker. I searched for a solution and came across the parameter /defer_ok. This means (as far as I understood) that mail go through clamav, but if it can't handover the e-mail to clamav it will be skipped. This is from the Exim manual:
- You can append /defer_ok to the malware condition to accept messages even if there is a problem with the virus scanner. Otherwise, such a problem causes the ACL to defer.
Source: http://www.exim.org/exim-html-current/doc/html/spec_html/ch41.html

The /defer_ok can be used for spamassassin either. Possibly it needs another approach, but I'm not very familiar with that.

2. You're using the demime directive. I don't know about a different way, but I read: "There is another content-scanning configuration option for Local/Makefile, called WITH_OLD_DEMIME. If this is set, the old, deprecated demime ACL condition is compiled, in addition to all the other content-scanning features."

Probably I misunderstood, but it looked to me that demime is deprecated.
Source: http://www.exim.org/exim-html-current/doc/html/spec_html/ch41.html

3. There are a lot of differences in approaches for rbl checking. You're checking in the recipient state (acl_check_recipient) of the SMTP transaction which happens very often, but I also read about checking this within the connect ACL (acl_connect). At the connect state there only is a connection from the sending SMTP server and it could be rejected very early in the process. Disadvantage should be alot more RBL lookups. Maybe you can think of more advantages than disadvantages. See http://slett.net/spam-filtering-for-mx/exim-final.html#acl_connect_final for more details. There're also some HELO check which maybe interesting.

4. I don't understand why we wouldn't accept messages larger than 1000K to be scanned by clamav.
# Accept but put warning into headers if message over 1000k
warn message = X-Antivirus-Scanner: Skipped scanning; size over 1000K. You should use an Antivirus Scanner
condition = ${if >={$message_size}{1000k} {1}{0}}

In SpamBlocker 2.1.1 this limitation wasn't there and I never came across problems or had performance issues with it. The exim.conf accept messages of 20MB by default and we put the same into clamd.conf, so there shouldn't be a problem, right? Messages larger than 1000K have attachments that should be scanned in my opinion.

5. Why are you using the whitelisting approach with dnswl.org? This list is used by SpamAssassin for scoring messages:
# DNSWL
score RCVD_IN_DNSWL_LOW 0 -1 0 -1
score RCVD_IN_DNSWL_MED 0 -4 0 -4
score RCVD_IN_DNSWL_HI 0 -8 0 -8

Besides that I think that allowing all whitelisted IP's/servers will lead to much more spam. When used I think that only high, or medium and high, trust servers should be accepted. See:
The following config snippit scans an email for spam unless the sending ip is a medium or high trust level in dnswl.org:
warn
! dnslists = list.dnswl.org&0.0.0.2
spam = nobody:true

Trust Level Description
High Never sends spam.
Medium Extremely rare spam occurrences, corrected promptly.
Low Occasional spam occurrences, actively corrected but less promptly.
This is the default for most categories.
None Legitimate mail server, may also send spam.
This is the default for some categories (eg Email Marketing Provider).

I don't know how to use this exactly by now, but such approach looks better to me than also allowing Low trust servers and the None trustlevel.

Source: http://dnswl.org/tech#exim

6. SMTP transaction delay. Connecting SMTP servers are delayed at several states within the transaction. This starts at the acl_connect:
acl_connect:
accept delay = 5s
hosts = *

With this setting it takes 5 seconds before the server is sending it's greeting.

The idea is that spam sending servers are configured for high delivery rates and slowing them down would send them away. Maybe the first 5 seconds wouldn't be enough, but the delay can be added at every deny statement for example. With every HELO check that gives a deny you could delay the session 2 more seconds or something like that.

See: http://tldp.org/HOWTO/Spam-Filtering-for-MX/smtpdelays.html
and http://www.deer-run.com/~hal/sysadmin/greet_pause.html

The concept is primitive but effective as far as I understand everything I've read. Don't delay to much, because that could deny legitimate e-mail.
 
You must log in or register to reply here.
Back
Top