Adjustments and Stuff

[BigWil]

My conclusions on SpamBlocker3/ClamAV/SpamAssassin. Problems, adjustments, etc. This is not a Howto but rather just feedback that one can take or leave. No disclaimer is required because no advice is given. If you think something might work for you give it a shot.

There are some nice new tricks in the new exim.conf that can cut back on spam considerably. However, there are a couple of caveats to make an admin ask himself if they are really worth it. Lets start with the main problem and work are way down followed by a few of my own adjustments and additions:
------------

deny message = Forged Gmail, not sent from your account.
senders = *@gmail.com
condition = ${if match {$sender_host_name}{\N(gmail|google).com$\N}{no}{yes}}

This is a great new addition in that it will block those nasty spam messages coming off of one host and saying they are for example a gmail account. However here are the issues. As I recall Gmail lets you POP your gmail account and therefore the $sender_host_name doesn't always match the email addy domain. Calls regarding this have been minimal, solution below.

Tell them to use the SMTP server of for instance Gmail and not to use their dsl, cable, or dialin ISP's. Easy resolve.

Here is the BIG issue. Server softwares such as some e-commerce platforms allow for the configuration where when a Consumer places an order, and the Merchant gets the confirmation of the order, the confirmation comes From: the Consumer. This makes it easy for the Merchant to reply to the confirmation email in order to email the Consumer. But guess what happens when the Consumers' email address is a gmail address. The e-commerce software function dies with the error: Forged Gmail, not sent from your account.

Although it currently works badly for our purposes due to our use of two softwares that allow the above configuration, I still think it is a step in the right direction. For now here is the modification I made that allows the software to send if and only if it comes from "localhost".

Forged Gmail, not sent from your account.

deny message = Forged Gmail, not sent from your account.
senders = *@gmail.com
condition = ${if match {$sender_host_name}{\N(gmail|google).com|localhost$\N}{no}{yes}}

This seems to work. I made the changes to all of these except for paypal.com. I only use Gmail here as an example.

In a perfect world there could be added a condition that if $sender_host_name doesn't match gmail and localhost is used that some sort of wrapper is used to log the entry into a /var/log/localforgeries log file. This way Admins can keep an eye on local script that may have been exploited which used a From:*@yahoo.com email address.
------------

Next I added a few parameters to the existing and these work great. I have already seen several bonified denies from what seem like spammers trying to hit the MX of record and doing a sloppy job of it.

smtp_banner = "SMTP" #added
message_size_limit = 20M
smtp_receive_timeout = 5m
smtp_accept_max = 100
message_body_visible = 3000
print_topbitchars = true
smtp_accept_max_nonmail = 7 #added
smtp_max_unknown_commands = 1 #added
smtp_accept_max_per_host = 5 #added

Google the last 3 for more info on those. The SMTP banner should really be a default as it leaves both spammers and hackers in the dark as to what MTA is being used. Always a good option not give them a starting point for their illegal activities.
------------

SORBS.ORG is still reporting DSL and Dialup customers that aren't really spammers but rather got stuck with an IP that previously was. This is a HUGE headache and accounts for about 30% of my customer support calls in a day. So if you want to cut back about 30% comment out the entry for safe.dnsbl.sorbs.net like so.

# deny using safe.dnsbl.sorbs.net
# deny message = Email blocked by SORBS - Some message here.
# hosts = !+relay_hosts
# domains = +use_rbl_domains
# !authenticated = *
# dnslists = safe.dnsbl.sorbs.net
-------------

I believe highly in fine tuning. The more fine tuning one does the more room is left for research and development. The use of sbl.spamhaus.org and not sbl-xbl.spamhaus.org is just that kind of instance. I have changed the sbl.spamhaus.org to sbl-xbl.spamhaus.org and commented out the cbl.abuseat.org like so.

# deny using spamhaus
deny message = Email blocked by SPAMHAUS - Some message here.
# only for domains that do want to be tested against RBLs
hosts = !+relay_hosts
domains = +use_rbl_domains
!authenticated = *
dnslists = sbl-xbl.spamhaus.org

#....snip....#

# deny using cbl
# deny message = Email blocked by CBL - Some message here.
# hosts = !+relay_hosts
# domains = +use_rbl_domains
# !authenticated = *
# dnslists = cbl.abuseat.org
----------------

Another addition is that I added a couple of recommended ACL usages recommended by comrads on both the Exim and Spamassassin mailing lists.

# acl_smtp_connect = check_connect
acl_smtp_helo = check_helo #added
acl_smtp_vrfy = check_vrfy #added
acl_smtp_rcpt = check_recipient
acl_smtp_data = check_message

#....snip....#

begin acl

#Right below the future implementation of the check_connect MX record check.

check_helo:
deny message = Your server announcement ($sender_helo_name) is a single word rather than a FQDN. This is in breach of RFC2821
condition = ${if match {$sender_helo_name} {\.} {no}{yes}}
deny message = Your server announces itself ($sender_helo_name) with a plain IP address which is in breach of RFC2821.
condition = ${if match {$sender_helo_name} {^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\$} {yes}{no}}
accept

check_vrfy:
deny message = VRFY not allowed - it assists spammers.
----------------

Last but not least I monitored the loads very carefully and saw great spikes due to SpamAssasin scanning friendly file attachments such as users sending others files, pictures, etc. The scores were all very low and I never did see a real piece of spam for this test. In the end I tested the theory that normally spam is always small in size (less than say 80k). So why scan the big stuff and risk the load on the server. So I decided not to scan any piece of mail greater than 80k in size.

In the Spamcheck_Director:

Below this:
{!def:h_X-Spam-Flag:} \

Added this:
{!>={$message_size}{80k}} \

#....snip....#

Below this:
deny message = This message contains an attachment of a type which we do not accept (.$found_extension)
demime = bat:com:pif:prf:scr:vbs

Added this:
warn message = X-Spam-Flag: Skipped scanning; size greater than 80KB
condition = ${if >={$message_size}{80k} {1}{0}}


And that about does it. Everything is smoooooth as silk over here now. Spam is very low or identified properly so that the customer can choose their desired options. Customers aren't calling anymore. Softwares on the servers are running accordingly and so far no vulnerability problems. Now I need a vacation but then again I needed one before I even started.

Big Wil

[smtalk]

deliver_queue_load_max should be also included into SpamBlocker v3

[jlasman]

Why? What's your rationale?

Jeff

[smtalk]

Because now exim also delivers mails when server load is 20+ etc.

[nzyme]

one of the most interesting settings is the banner perhaps :)

Jeff, what are your words on this.. since your the maintainer/creater of spamblocker..
If you agree with the above suggestions then perhaps they can be implemented in a next version ? (perhaps the current beta3 brach?)

[BigWil]

Smtalk has a good one. I did a little research and it looks like it is best used in combination with a couple others. I was just having a pretty heavy "exim moment" due to httpd being hit hard and webalizer doing its own thing at primetime hours (don't know what is up with that) and I tried these entries. It quieted exim down while httpd finished doing its thing. Nice.

deliver_queue_load_max = 3.0
queue_only_load = 3.0
queue_run_max = 1

Big Wil

[jlasman]

Originally posted by smtalk
Because now exim also delivers mails when server load is 20+ etc.
Good point. The old Sun Cobalt RaQs have this enabled in their sendmail.cf. I still have a few clients running RaQs. They call me several times a week to tell me to restart their email server (they get an email when it goes down), and by the time I log in the serverload has dropped and the MTA is already running again.

Often, though not always, the MTA is the cause of the load going so high. So it just bounces around all day.

Still, possibly worth adding.

Jeff

[jlasman]

Originally posted by BigWil
queue_run_max = 1
What's your rationale for only one queue run?

Hooray! I'm finally getting some ideas. Which is exactly what I was hoping for when I took the time to set up these new subforums :) .

Jeff

[smtalk]

There should be also something like this in configuration:

auto_thaw = 3d

And you should take a look at http://exim.org/exim-html-4.66/doc/html/spec_html/ch14.html to add more great features to SpamBlocker.

[jlasman]

Why 3 days instead of the default?

Thanks.

Jeff

[freshmint]

So... will these be added/modified to SpamBlocker3? :)

Seems worth.

[smtalk]

jlasman, take a look at http://www.tldp.org/HOWTO/Spam-Filtering-for-MX/exim.html and write a "future releases" plan, in this way it will be easier to release a final and bug-free version :)
e.g.

2007-04-21 SpamBlocker v3 beta2 release. New features added.
2007-05-29 SpamBlocker v3 beta3 release. New features added.
2007-06-18 SpamBlocker v3 RC1 (Release Candidate 1) release. Feature frozen.
2007-08-01 SpamBlocker v3 final release.

[panamaspace]

Just a question.



Next I added a few parameters to the existing and these work great. I have already seen several bonified denies from what seem like spammers trying to hit the MX of record and doing a sloppy job of it.

smtp_banner = "SMTP" #added
message_size_limit = 20M
smtp_receive_timeout = 5m
smtp_accept_max = 100
message_body_visible = 3000
print_topbitchars = true
smtp_accept_max_nonmail = 7 #added
smtp_max_unknown_commands = 1 #added
smtp_accept_max_per_host = 5 #added

Google the last 3 for more info on those. The SMTP banner should really be a default as it leaves both spammers and hackers in the dark as to what MTA is being used. Always a good option not give them a starting point for their illegal activities.
------------




#Right below the future implementation of the check_connect MX record check.

check_helo:
deny message = Your server announcement ($sender_helo_name) is a single word rather than a FQDN. This is in breach of RFC2821
condition = ${if match {$sender_helo_name} {\.} {no}{yes}}
deny message = Your server announces itself ($sender_helo_name) with a plain IP address which is in breach of RFC2821.
condition = ${if match {$sender_helo_name} {^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\$} {yes}{no}}
accept


I basically use all of the tricks on this thread, but, after minor testing, will have to pass on the smtp banner advice for now, though I like it.

I wonder if in fact, if somebody implemented both, on the one hand you won't advertise your smtp correctly, but might not allow mail from anybody who behaves just like you.

This is the warning on dnsstuff.com for using smtp_banner ="SMTP" on exim.conf

WARNING: One or more of your mailservers is claiming to be a host other than what it really is (the SMTP greeting should be a 3-digit code, followed by a space or a dash, then the host name). If your mailserver sends out E-mail using this domain in its EHLO or HELO, your E-mail might get blocked by anti-spam software. This is also a technical violation of RFC821 4.3 (and RFC2821 4.3.1). Note that the hostname given in the SMTP greeting should have an A record pointing back to the same server. Note that this one test may use a cached DNS record.

the greeting should look really like this:

220 cp.example.com ESMTP Exim 4.63 Tue, 03 Jul 2007 00:58:49 -0400

Could this actually affect mail delivery to other servers? or does this work ONLY when receiving emails, and doesn't affect your outgoing mail?


Thanks.

[BigWil]

I suppose what you could do is to use "cp.example.com SMTP' as the banner. Myself I don't much care for half of the tests used at DNSStuff including this one. But if you would prefer the above should suppress that error.

Again, the purpose of using 'SMTP' is to not give away what the mail server software and version are. If you give hackers a place to start they are more prone to attack you. If you give them a generic answer such as 'SMTP' then they have to spend a large amount of time trying to figure out which server the machine is running and in doing so they will probably make enough mistakes that detection will be much easier.

And no it wouldn't effect outgoing just connections inbound.

BigWil

[panamaspace]

Good enough! Thanks!

[jlasman]

My conclusions on SpamBlocker3/ClamAV/SpamAssassin. Problems, adjustments, etc. This is not a Howto but rather just feedback that one can take or leave. No disclaimer is required because no advice is given. If you think something might work for you give it a shot.
I've been attempting to add some of your ideas to SpamBlocker3, but ...
This doesn't appear to work:
check_helo:
deny message = Your server announcement ($sender_helo_name) is a single word rather than a FQDN. This is in breach of RFC2821
condition = ${if match {$sender_helo_name} {\.} {no}{yes}}
deny message = Your server announces itself ($sender_helo_name) with a plain IP address which is in breach of RFC2821.
condition = ${if match {$sender_helo_name} {^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\$} {yes}{no}}
accept
My tests show that single word helo's are being accepted (first condition), and that IP#s alone are being blocked by your second condition, but IP#s in brackets (which many spammers use) are accepted.

Have you tried this using this command:
exim -bh foo
followed immediately by this comand:
ehlo foo
For me, it gets accepted.

I'd really like to include these; they'll block lots of spam, but currently they don't seem to work :( .

Any ideas?

Jeff

[BigWil]

Jeff,

Good catches and thanks for giving me an easy way of testing. I feel like an idiot doing the trial and error I was previously. :-(

Here ya go:


check_helo:
deny message = Your server announcement ($sender_helo_name) is a single word rather than a FQDN. This is in breach of RFC2821
condition = ${if ! match {$sender_helo_name}{\N^[^.].*\.[^.]+$\N}}
deny message = Your server announces itself ($sender_helo_name) with a plain IP address which is in breach of RFC2821.
condition = ${if match {$sender_helo_name} {^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\$|^\[[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\]\$} {yes}{no}}
accept


Seems to catch the single words and the IPs inside of brackets.

Big Wil

[jlasman]

good catches and thanks for giving me an easy way of testing. I feel like an idiot doing the trial and error I was previously. :-(
Don't feel like an idiot... if you do, then I have to, for accepting your code into my new alpha (the new beta running only on my system) without testing it.

We all live and learn.

Thanks for the quick fix.

I'll test it and hopefully be able to include it.

Jeff

[BigWil]

I have gotten feedback from valid customers today that are using a Mac with Entourage.

2007-09-17 10:13:09 H=static-69-95-157-215.man.choiceone.net ([192.168.1.100]) [69.95.157.215] rejected EHLO or HELO [192.168.1.100]: Your server announces itself ([192.168.1.100]) with a plain IP address which is in breach of RFC2821.

I am going to add their static IP to the allowed hosts but I sure hope this doesn't become a habbit. If only every IT guy knew how to setup a network properly so the workstations actually have a name on the network, the world would be a brighter place.

Well adding them to the allowed hosts didn't work of course because the check_helo runs first. Any ideas?

Big Wil

[BigWil]

Editing what was here completely.

I am going to test some new ones and will post the ones that work well here. The (Singleword) isn't exactly a good idea as there is hardly ever a . in it unless it is a mailserver connecting. Whenever a remote user is sending mail direct from their workstation it almost always uses something like (Singleword) which equates to the workstation name. So unless we could check to see if they are authenticating first then this is pretty much useless.

The [nnn.nnn.nnn.nnn] is in fact RFC2821 compliant and we can't block those.

However there are other ways to fill the holes and I just found a goldmine. I will convert them to the typical Spamblocker syntax and give them a shot. Will post results shortly.

Big Wil

[BigWil]

http://www.ietf.org/rfc/rfc2821.txt

Looks like the [nnn.nnn.nnn.nnn] are compliant domain literals. See section 4.1.3 of the RFC. Based on that I don't think we should include the check with the brackets.

We should hold onto the single word and the nnn.nnn.nnn.nnn without the brackets though.

Big Wil

[jlasman]

Whenever a remote user is sending mail direct from their workstation it almost always uses something like (Singleword) which equates to the workstation name. So unless we could check to see if they are authenticating first then this is pretty much useless.
I've done some tests on getting authentication to work first; what I tried to do was set a variable (in my case acl_m1) if it was a single word, and then later if acl_m1 was set but the user wasn't authenticated, refuse the email.

However that didn't work; I couldn't get it check of acl_m1 was properly set. If you can figure it out, great; otherwise we'll end up asking the exim community.
The [nnn.nnn.nnn.nnn] is in fact RFC2821 compliant and we can't block those.
I think we can under the same authentication conditions; I've checked weeks of logs and it seems that only spammers use it, and they use it a lot.
However there are other ways to fill the holes and I just found a goldmine. I will convert them to the typical Spamblocker syntax and give them a shot. Will post results shortly.
I'm looking forward to your posts.

Jeff

[BigWil]

Homework is telling me that the reason that outgoing smtp clients have a HELO/EHLO of "SingleWord" is because Outlook Express passes only the Netbios name. Leave it to Microsoft!


deny message = Your server announcement ($sender_helo_name) is a single word rather than a FQDN. This is in breach of RFC2821
condition = ${if ! match {$sender_helo_name}{\N^[^.].*\.[^.]+$\N}}
hosts = ! +whitelist_hosts_ip
!authenticated = *


I have been testing this one and everything I read tells me it should work. But instead it results in this error. Any ideas?

"451 Temporary local problem - please try later"

Big Wil

[BigWil]

Wasn't able to get the one above to work ever. I suppose this is because of where check_helo is running. Though for the "singleword" I have been tinkering with this one.


# Uncomment the following 3 lines if you want to block singleword HELO as and force them to use 587
# deny message = RFC2821 breach with ($sender_helo_name). Use SMTP port 587 instead.
# condition = ${if and {{eq{$interface_port}{25}}{! match {$sender_helo_name}{\N^[^.].*\.[^.]+$\N}}}}
# hosts = ! +whitelist_hosts_ip


It has been tested and works as it should. As you can see here I have it commented out and used as an option. Reason for this is that Popb4SMTP or port 25 using Outlook is almost always going to send a single word. Uncommenting the administrator would be agreeing to use 587 for any of those customers, or put them into whitelist_hosts_ip file if they have a static IP.

Just something to consider. There are more coming but I am going to back burner this one as it is.

Big Wil

[jlasman]

Thanks, BigWil. I'm going to test this and it'll probably make it into the next SpamBlocker beta. Probably the IP#s and [IP#] code as well even though some people may not like the latter. But I'll leave it commented out by default.

Jeff

[BigWil]

Those are on their way along with a couple more. I think another thing that has been missing from SB for awhile is an easy way of identifying who the big sources are so they can be added to the local blacklist. I am looking into a way of logging the major violators of these helo rules. Somebody shows up alot; easy to identify and block them without trudging through the rejectlog.

Maybe even firewall rule additions but I would do that on my own.

Big Wil

[BigWil]

Try these on for size. I will try to revise for the logging if so desired:


check_helo:
## Uncomment the following 3 lines if you want to block singleword HELO as and force them to use 587
## deny message = RFC2821 breach with ($sender_helo_name). Use SMTP port 587 instead.
## condition = ${if and {{eq{$interface_port}{25}}{! match {$sender_helo_name}{\N^[^.].*\.[^.]+$\N}}}}
## hosts = ! +whitelist_hosts_ip

## Uncomment the following 3 lines if you want to block IP literals that ARE surrounded with []
## deny message = Your server announces itself ($sender_helo_name) as a simple IP literal.
## condition = ${if match {$sender_helo_name} {^[[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+]\$} {yes}{no}}
## hosts = ! +whitelist_hosts_ip

# Check that no empty HELO values are being attempted. Rare.
deny message = RFC2821 breach polite hosts say HELO first. See RFC 2821 section 4.1.1.1
condition = ${if eq{$sender_helo_name}{}{1}{0}}
hosts = ! +whitelist_hosts_ip

# Check that plain IP isn't being sent either V4 or V6 - IP address without []
deny message = RFC2821 breach $sender_helo_name is an IP and not a name
condition = ${if or {{ isip{$sender_helo_name}}{ isip6{$sender_helo_name}}}}
hosts = ! +whitelist_hosts_ip

# Forged (localhost or my IP) from a host that isn't allowed to relay
deny message = Security breach $sender_helo_name is MY name/IP!
condition = ${if or {{ match{$sender_helo_name}{$interface_address}}{ eq{$sender_helo_name}{localhost}}}}
hosts = ! +relay_hosts

# Forged hostname in helo matches one of our own without being in relays
deny message = Security breach $sender_helo_name is one of MY names!
condition = ${lookup{$sender_helo_name} lsearch{/etc/virtual/domains}{1}{0}}
hosts = ! +relay_hosts
accept


The best for the "localhost" test I could do was to do it live. Test wouldn't work very well locally as it would always succeed. You may have different strategies which would work. But it worked live allowing me through remote, allowed me through on 127.0.0.1 using "localhost" but not from elsewhere trying to use "localhost". Seems to be working to me.

I am figuring you will be testing these well before including them. Two sets of eyes are better than one.

Big Wil

[jlasman]

Thanks for all your help. Yes, I test everything, on a server that hosts ONLY an old ISP domain I own. There's only a few good email addresses on it, for testing. All other email addresses are dead and have been for years (I cleaned the domain from being sent to by legitimate senders by pointing the ISPs mx record to 127.0.0.1 for two years) and are managed by a catchall for testing purposes to see what comes through.

It gets thousands of spam emails a day, and eventually I'm going to create a local blocklist with all those IP#s.

But I have to rebuild that server (old hard disk crashed; the server is ancient) before I can test again so this may take a few days (or more :( ).

Jeff

[Chrysalis]

MX pointed to 127.0.0.1 for 2 years and it still gets spam? crazy.

[BigWil]

I have added these to our corporate server and am testing some logwrite options. I can already tell that our results with these HELO rules are going to be phenomenal. I am wondering which would be better on some of them a drop or a deny. We definately want a deny with message on the "singleword" rule to attempt to reduce support call on the transition since it clearly tells them to switch to 587. At least savy endusers will figure it out.

Modifying the "singleword" rule to the following:

## Uncomment the following 3 lines if you want to block singleword HELO as and force them to use 587
deny message = RFC2821 breach with ($sender_helo_name). Use SMTP port 587 instead.
condition = ${if and {{eq{$interface_port}{25}}{! match {$sender_helo_name}{\N^[^.].*\.[^.]+$\N}}}}
logwrite = :panic: HELOVIO-1:helo=$sender_helo_name [$sender_host_address,$sender_host_name]
hosts = ! +whitelist_hosts_ip


I received all of these results in just a few minutes. This is our corporate server so we can easily identify what is ours and isn't. We changed to 587 so none of ours are in here. These are all violating users that we don't want.


2007-09-20 10:52:36 HELOVIO-1:helo=fnztm [189.25.55.59,]
2007-09-20 10:53:36 HELOVIO-1:helo=epotmv [85.139.154.123,]
2007-09-20 10:57:06 HELOVIO-1:helo=azc6tr2rzecqic5 [91.122.147.16,ppp91-122-147-16.pppoe.avangard-dsl.ru]
2007-09-20 11:05:40 HELOVIO-1:helo=PC186249116308 [83.26.111.110,aod110.neoplus.adsl.tpnet.pl]
2007-09-20 11:13:25 HELOVIO-1:helo=sujata [71.184.153.109,pool-71-184-153-109.bstnma.fios.verizon.net]
2007-09-20 11:15:17 HELOVIO-1:helo=danibcsi [82.131.188.64,82.131.188.64.pool.invitel.hu]
2007-09-20 11:15:17 HELOVIO-1:helo=danibcsi [82.131.188.64,82.131.188.64.pool.invitel.hu]
2007-09-20 11:15:17 HELOVIO-1:helo=danibcsi [82.131.188.64,82.131.188.64.pool.invitel.hu]
2007-09-20 11:15:17 HELOVIO-1:helo=danibcsi [82.131.188.64,82.131.188.64.pool.invitel.hu]
2007-09-20 11:15:17 HELOVIO-1:helo=danibcsi [82.131.188.64,82.131.188.64.pool.invitel.hu]
2007-09-20 11:16:21 HELOVIO-1:helo=olcsec [200.110.20.6,]
2007-09-20 11:16:23 HELOVIO-1:helo=olcsec [200.110.20.6,]
2007-09-20 11:16:44 HELOVIO-1:helo=rkcizor [70.107.81.251,pool-70-107-81-251.ny325.east.verizon.net]
2007-09-20 11:16:44 HELOVIO-1:helo=yuwrcy [70.107.81.251,pool-70-107-81-251.ny325.east.verizon.net]
2007-09-20 11:18:00 HELOVIO-1:helo=francisc78iw89 [200.126.102.171,200-126-102-171.bk7-dsl.surnet.cl]
2007-09-20 11:18:00 HELOVIO-1:helo=francisc78iw89 [200.126.102.171,200-126-102-171.bk7-dsl.surnet.cl]
2007-09-20 11:18:00 HELOVIO-1:helo=francisc78iw89 [200.126.102.171,200-126-102-171.bk7-dsl.surnet.cl]
2007-09-20 11:18:00 HELOVIO-1:helo=francisc78iw89 [200.126.102.171,200-126-102-171.bk7-dsl.surnet.cl]
2007-09-20 11:18:00 HELOVIO-1:helo=francisc78iw89 [200.126.102.171,200-126-102-171.bk7-dsl.surnet.cl]
2007-09-20 11:18:00 HELOVIO-1:helo=francisc78iw89 [200.126.102.171,200-126-102-171.bk7-dsl.surnet.cl]
2007-09-20 11:18:00 HELOVIO-1:helo=francisc78iw89 [200.126.102.171,200-126-102-171.bk7-dsl.surnet.cl]
2007-09-20 11:18:00 HELOVIO-1:helo=francisc78iw89 [200.126.102.171,200-126-102-171.bk7-dsl.surnet.cl]
2007-09-20 11:18:02 HELOVIO-1:helo=francisc78iw89 [200.126.102.171,200-126-102-171.bk7-dsl.surnet.cl]
2007-09-20 11:18:02 HELOVIO-1:helo=francisc78iw89 [200.126.102.171,200-126-102-171.bk7-dsl.surnet.cl]
2007-09-20 11:18:03 HELOVIO-1:helo=francisc78iw89 [200.126.102.171,200-126-102-171.bk7-dsl.surnet.cl]
2007-09-20 11:19:18 HELOVIO-1:helo=family [72.89.95.57,pool-72-89-95-57.nycmny.fios.verizon.net]


The only problem with this rule is making the switch to 587 on production machines. Users will certainly be calling in even if we send out a notification. But it will be worth it in the long run I am sure as the load on bounces will certainly reduce.

Big Wil

[BigWil]

Jeff,

Could we maybe move our discussions here over to another thread. "HELO Checks" might be good.

I have decided on my live/testing server over here to use the logging to paniclog. Paniclog is hardly ever used and whenever it is I always know what to look for. So since exim is keeping it open anyways why not put it to good use. Unfortunately I can't see a way of creating another log file handle.

With the use of my logging and the syntax here I am going to write a Perl/DBI script that will collect data from the paniclog and place it into MySQL. It will rate them depending on how often they try to make a bad HELO connect within a 24 hour period. Those that rate an 8 or higher will be added to not only the local blacklist but the firewall rules as well. Those between 4 and 7 just get added to the blacklist. This should all keep them nicely blocked from spiking the Exim load which is what has been causing my spikes and kernel panics in another thread.

I also put the deny or drop theoretics to the test. In all cases that we don't feel the need to talk back to a customer on a false positive I say use drop. In the case of the "use 587" message for the singleword filter I am using deny. Works really good and the exim child processes are closing alot faster than making them sit around and timeout because some spammer server isn't answering at all. I am also reading in a few places that there are worries about someone being able to get to the RCPT even though the HELO failed and a drop will certainly keep that from happening.

My final cut follows:

check_helo:
## Uncomment the following 4 lines if you want to block singleword HELO and force them to use 587. Comment out logwrite if you don't want logging.
# deny message = RFC2821 breach with ($sender_helo_name). Use SMTP port 587 instead.
# condition = ${if and {{eq{$interface_port}{25}}{! match {$sender_helo_name}{\N^[^.].*\.[^.]+$\N}}}}
# logwrite = :panic: HELOVIO-1 helo:$sender_helo_name ip:$sender_host_address host:$sender_host_name
# hosts = ! +whitelist_hosts_ip

# Uncomment the following 4 lines if you want to block IP literals that ARE surrounded with []. Comment out logwrite if you don't want logging.
# drop message = Your server announces itself ($sender_helo_name) as a simple IP literal.
# condition = ${if match {$sender_helo_name} {^[[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+]\$} {yes}{no}}
# logwrite = :panic: HELOVIO-2 helo:$sender_helo_name ip:$sender_host_address host:$sender_host_name
# hosts = ! +whitelist_hosts_ip

# Check that no empty HELO values are being attempted. Rare.
drop message = RFC2821 breach polite hosts say HELO first. See RFC 2821 section 4.1.1.1
condition = ${if eq{$sender_helo_name}{}{1}{0}}
# logwrite = :panic: HELOVIO-3 helo:$sender_helo_name ip:$sender_host_address host:$sender_host_name
hosts = ! +whitelist_hosts_ip

# Check that plain IP isn't being sent either V4 or V6 - IP address without []
drop message = RFC2821 breach $sender_helo_name is an IP and not a name
condition = ${if or {{ isip{$sender_helo_name}}{ isip6{$sender_helo_name}}}}
# logwrite = :panic: HELOVIO-4 helo:$sender_helo_name ip:$sender_host_address host:$sender_host_name
hosts = ! +whitelist_hosts_ip

# Forged (localhost or my IP) from a host that isn't allowed to relay
drop message = Security breach $sender_helo_name is MY name/IP!
condition = ${if or {{ match{$sender_helo_name}{$interface_address} }{ eq{$sender_helo_name}{localhost}} \
{eq{$sender_helo_name}{localhost.localdomain}}}}
# logwrite = :panic: HELOVIO-5 helo:$sender_helo_name ip:$sender_host_address host:$sender_host_name
hosts = ! +whitelist_hosts_ip

# Forged hostname in helo matches one of our own without being in relays
drop message = Security breach $sender_helo_name is one of MY names!
condition = ${lookup{$sender_helo_name} lsearch{/etc/virtual/domains}{1}{0}}
# logwrite = :panic: HELOVIO-6 helo:$sender_helo_name ip:$sender_host_address host:$sender_host_name
hosts = ! +whitelist_hosts_ip
accept


One last quick note in the HELOVIO-5 rule above I added the test for localhost.localdomain. So far this has caught several .de and .dk servers with all in all bad HELOs. It is amazing sitting here tailing the paniclog how much these are all catching. And this is a single server receiving mail for a single domain (ours).

[jlasman]

I don't have time to respond to this thread right now :( so I hope you'll post to it again some time Saturday morning if you don't see some responses from me :) .

Thanks.

Jeff

[BigWil]

Today's not Saturday but .... bump anyways.

I think one idea we might want to consider for the [nnn.nnn.nnn.nnn] IP literals is this. If an IP literal is being used it will either give the IP of the router or the private IP of the machine behind a firewall. If this is the case then another IP would never be used. So if $sender_helo_name equals [nnn.nnn.nnn.nnn], doesn't equal [$sender_host_address], doesn't equal [192.168.*.*] and doesn't equal [90.0.*.*] then it should be denied I think. Still want to test it though to be sure.

I see alot of spammers hitting with this scenario. They are being caught by the other rules but how about those that aren't? Can someone help me out with the regex for 192.168.*.*. My regex is showing various results like blocking 192.169.*.* as well. I am not real big on regex I am afraid to say. Just one of those things.

Big Wil

[jlasman]

I'm going to look at these today. If you can get the regex then post it; I'm going to look at this thread later today.

Jeff

[jlasman]

I want to bring out SpamBlocker3rc1 as early as this week; anyone have any more up-to-date stuff for me to look at?

Jeff

[czotos]

Hi Jeff!

I know that you will probably include a 'README.TXT' file together with the release of your SpamBlocker3-RC1 which will describe to users how to upgrade their existing SpamBlocker versions, right?

You see, I am currently running SpamBlocker3-BETA (with ClamAV and SpamAssassin) and I was wondering...

Is the upgrade of SpamBlocker as simple as replacing the current 'exim.conf' file with the new 'exim.conf' file??

Is there anything else that needs to be done?

Thanks in advance, and keep up the good work!! You won't believe how much we appreciate your efforts :)