[milters] Archive

Lists Index Date Thread Search

Article: 1597
From: Anthony Howe
Date: 2007-05-30 11:31:03 -0400
Subject: Re: BarricadeMX released...

Removal...........: milters-request@milter.info?subject=remove
More information..: http://www.milter.info/#Support
--------------------------------------------------------

Grant Taylor wrote:
>> http://www.snertsoft.com/barricademx.php
> 
> Can we get any sort of information (read:  sales pitch) on what it 
> offers differently than multiple of your very good milters in 
> combination with each other?  I'm not asking for the technical guts, 
> just some persuasion to use it over your milters.  ;)

Hmm. There is so MUCH in BarricadeMX it will be hard to list everything, 
but I'll try:

-- By unifying all the various techniques into one product, you end up 
with fewer processes for one. It is a threaded application, NEVER 
creates a temporary file, uses SQLite for all the databases instead of 
Berkeley DB which is now owned by Oracle.

-- Multicast / unicast cache. This is the code that was suppose to go 
into milter-gris et al., but I held off. This make sharing the cache 
between local and remote MXes a breeze.

-- The enhanced grey-list has two significant optimisations:
the PTR grey-list key element which resolves the problem when you have a 
pool of mail servers sharing a common mail queue, think gmail.com; 
second if you only grey-list a mail server ONCE and NOT for each 
different sender/recipient from the same mail server - once you know the 
machine retries, no point grey-list further mail from it.

-- Connection rate throttling and concurrency limits. Similar to 
sendmail, might be faster implementation, but in principal the same.

-- Enhanced Message-ID Email Watermark: an evolution of milter-null. 
Blocks backscatter like milter-null, BUT can also white list replies in 
response to previously sent message from content filtering. Combined 
with dns-gl could be interesting.

-- client-is-mx heuristic will soften the impact of client-ptr-required 
and client-ip-in-ptr. How many times have you wanted to enforce a PTR 
requirement or an reject from something that looks dynamic, but can't 
because the tests are normally to strong and deny legit systems that 
have no control over their PTR or its value. Essentially client-is-mx 
aims to make those test safer by waiting until you know the MAIL FROM: 
domain and checking if it is a listed MX.

-- dns-gl is a bit of a misnomer, but we couldn't think of anything 
better to call it. Essentially similar to a dns-wl, but only white lists 
past the pre-DATA tests, after which content filtering is applied. You 
might want to use this with an internal dns-wl or with dns-wl that you 
have less confidence in, but still want to some filtering.

-- Application of URIBL to on the client hostname, HELO, and/or MAIL 
FROM: domains. Not novel, but not widely applied either.

-- Multiline banner combined with command-pause is will catch about 20% 
spam / bad actors.

-- ehlo-no-helo and helo-schizophrenic: from the documentation...

"The smtp-enable-esmtp option when disabled causes some badly written 
spam software that fails to fall-back to regular SMTP to disconnect or 
become out-of-sync (see the ehlo-no-helo counter). Regular mail software 
is unaffected and falls-back correctly. Other spam software will send an 
EHLO and when the command is rejected, send a HELO, but using a 
different host/domain argument to the EHLO that was previously sent; 
smtpf will reject and drop these connections (see the helo-schizophrenic 
counter).

-- Lots of runtime statistics counters for progress monitoring. See 
below for example output.

-- While not my favourite, some people like the idea of tar-pitting. 
Rather than tar-pit everything, I tar pitting negative SMTP responses. 
Consider a dictionary attack. If an SMTP command fails, assume MAIL 
FROM:, then you delay the response by one second, next failure 2 
seconds, third failure 4 seconds, continue until they disconnect or the 
delay forces the client to timeout. A well behaved client should not 
cause any failures and so not be delayed.

-- One beta tester had a single MX that was getting pounded by spam and 
lots of simultaneous connections. They were the only I recall to reach 
the default process max. file handle limit, so we double it, and they 
reached it AGAIN, at 1018 connections. We thought about increasing it 
further, but didn't have time and never revisited. Nice thing was the 
application didn't keel over from the load, the mail kept flowing, and 
the client didn't get any reports of lost mail. Can sendmail 8 handle 
1018 connections without bring the box to its knees? Maybe the new MeTA1 
(previously sendmail X) can since it uses state threads, but sendmail 8 
not possible without mega hardware I would think.

Those are some of the highlights. I'm sure there is more I could be saying.

Anthony

----
Example stats from a spam trap, restarted about an hour ago, so it is 
not as impressive as it could be, but it should give you an idea.

Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
220-XXX.XXXXX.XXX ESMTP Welcome to smtpf
220 Copyright 2006, 2007 by SnertSoft. All rights reserved.
stats
214-2.0.0 smtpf/1.0.126 (runtime)
214-2.0.0 start-time=Mon, 28 May 2007 16:21:52 -0400
214-2.0.0 age=155181
214-2.0.0 active-connections=3
214-2.0.0 high-connections=41 (100.00%)
214-2.0.0 high-session-time=394 (100.00%)
214-2.0.0 total-KB=28884 (100.00%)
214-2.0.0 CLIENTS=64644 (100.00%)
214-2.0.0 dropped=57188 (88.47%)
214-2.0.0 data-354=2241 (3.47%)
214-2.0.0 client-io-error=4311 (6.67%)
214-2.0.0 client-timeout=104 (0.16%)
214-2.0.0 server-io-error=974 (1.51%)
214-2.0.0 admin-commands=281 (0.43%)
214-2.0.0 auth-pass=0 (0.00%)
214-2.0.0 auth-fail=0 (0.00%)
214-2.0.0 bogus-helo=1 (0.00%)
214-2.0.0 concurrent=0 (0.00%)
214-2.0.0 connect-bl=0 (0.00%)
214-2.0.0 connect-lan=0 (0.00%)
214-2.0.0 connect-localhost=291 (0.45%)
214-2.0.0 connect-relay=291 (0.45%)
214-2.0.0 connect-wl=0 (0.00%)
214-2.0.0 dns-bl=50511 (78.14%)
214-2.0.0 dns-gl=245 (0.38%)
214-2.0.0 dns-wl=0 (0.00%)
214-2.0.0 ehlo-no-helo=753 (1.16%)
214-2.0.0 helo-claims-us=0 (0.00%)
214-2.0.0 helo-ip-mismatch=0 (0.00%)
214-2.0.0 helo-schizophrenic=25 (0.04%)
214-2.0.0 idle-retest-timer=0 (0.00%)
214-2.0.0 rate-client=1765 (2.73%)
214-2.0.0 rate-throttle=13 (0.02%)
214-2.0.0 client-ip-in-ptr=0 (0.00%)
214-2.0.0 client-ptr-required=0 (0.00%)
214-2.0.0 client-ptr-required-error=0 (0.00%)
214-2.0.0 rfc2821-strict-helo=0 (0.00%)
214-2.0.0 smtp-command-non-ascii=8 (0.01%)
214-2.0.0 smtp-command-pause=1174 (1.82%)
214-2.0.0 smtp-drop-after=102 (0.16%)
214-2.0.0 smtp-drop-unknown=0 (0.00%)
214-2.0.0 smtp-enable-esmtp=5495 (8.50%)
214-2.0.0 smtp-greet-pause=953 (1.47%)
214-2.0.0 smtp-reject-delay=0 (0.00%)
214-2.0.0 uri-bl-helo=0 (0.00%)
214-2.0.0 uri-bl-ptr=0 (0.00%)
214-2.0.0 SENDERS=8391 (100.00%)
214-2.0.0 null-sender=863 (10.28%)
214-2.0.0 call-back-cache=0 (0.00%)
214-2.0.0 call-back-made=0 (0.00%)
214-2.0.0 cli-envelope=0 (0.00%)
214-2.0.0 client-is-mx=2602 (31.01%)
214-2.0.0 grey-continue=710 (8.46%)
214-2.0.0 grey-tempfail=5063 (60.34%)
214-2.0.0 mail-bl=0 (0.00%)
214-2.0.0 mail-wl=0 (0.00%)
214-2.0.0 mail-parse=22 (0.26%)
214-2.0.0 require-sender-mx=0 (0.00%)
214-2.0.0 require-sender-mx-error=0 (0.00%)
214-2.0.0 siq-query-cache=0 (0.00%)
214-2.0.0 siq-query-made=0 (0.00%)
214-2.0.0 siq-score-reject=0 (0.00%)
214-2.0.0 siq-score-tag=0 (0.00%)
214-2.0.0 spf-pass=2583 (30.78%)
214-2.0.0 spf-fail=634 (7.56%)
214-2.0.0 spf-none=8076 (96.25%)
214-2.0.0 spf-neutral=272 (3.24%)
214-2.0.0 spf-softfail=187 (2.23%)
214-2.0.0 spf-perm-error=31 (0.37%)
214-2.0.0 spf-temp-error=240 (2.86%)
214-2.0.0 uri-bl-mail=0 (0.00%)
214-2.0.0 RECIPIENTS=8331 (100.00%)
214-2.0.0 rcpt-reject=937 (11.25%)
214-2.0.0 one-rcpt-per-null=0 (0.00%)
214-2.0.0 rcpt-bl=0 (0.00%)
214-2.0.0 rcpt-wl=0 (0.00%)
214-2.0.0 rcpt-parse=0 (0.00%)
214-2.0.0 MESSAGES=2519 (100.00%)
214-2.0.0 msg-accept=635 (25.21%)
214-2.0.0 msg-discard=0 (0.00%)
214-2.0.0 msg-drop=12 (0.48%)
214-2.0.0 msg-reject=1872 (74.32%)
214-2.0.0 dsn-sent=0 (0.00%)
214-2.0.0 7bit-headers=0 (0.00%)
214-2.0.0 cli-content=0 (0.00%)
214-2.0.0 infected=0 (0.00%)
214-2.0.0 junk-mail=0 (0.00%)
214-2.0.0 line-length=0 (0.00%)
214-2.0.0 message-limit=0 (0.00%)
214-2.0.0 message-size=0 (0.00%)
214-2.0.0 ret-pass=0 (0.00%)
214-2.0.0 ret-fail=416 (16.51%)
214-2.0.0 ret-ttl=0 (0.00%)
214-2.0.0 strict-dot=0 (0.00%)
214-2.0.0 uri-bl=1456 (57.80%)
214-2.0.0 uri-max-limit=0 (0.00%)
214-2.0.0 uri-max-test=28 (1.11%)
214 2.0.0 End.

-- 
Anthony C Howe          Skype: SirWumpus                    SnertSoft
+33 6 11 89 73 78         ICQ: 7116561      Sendmail Milter Solutions
http://www.snert.com/                 
     http://www.snertsoft.com/

Lists Index Date Thread Search