[Mimedefang] Back into the loop...

[Philip Prindeville]

Hi.

Been off working on other projects and hence haven't spent a lot of
attention to this list the last few months (sniff!), but I have more free
time lately (largely due to being made redundant, woo-hoo!).

Anyway, if these questions have been asked before, sorry.

A few issues/questions I was thinking of...

First, I want to add some sort of throttling to MdF so that if the
filter rejects a connection during the HELO or RCPT TO or
MAIL FROM stages, that it will (for the duration of a throttling
period) reject incoming connections during the CONNECT stage,
and indeed if new connections come in during that period, it
will double or quadruple that window.

For instance, if it sees

HELO localhost.localdomain

from 192.150.1.3, then it will reject that the session... with a 5xx
message... and will also blacklist incoming connections from that
site for the next 4 hours...  If another connection comes in from
that address during that 4 hour period, maybe double or quadruple
the wait period.

One other thing I wasn't sure about doing, was adding "simultaneity"
locking as well.  That is, blacklisting additional connections from
the same site during the duration of a connection.  Most legitimate
MTA's will open a single connection per site, and then spool
multiple messages over a single connection.

Only ratware seems to like to open multiple connections in parallel.

On a note related to the blacklisting above...  I want to persistently
store the tuple of (ip-address, time-of-blacklist-expiration) into
a database...  and I was wondering what sort of Perl tied hash
would work well that handles locking and concurrency transparently.

Anyone prefer one Perl module over another?

Let's see, what else?

I've been wondering about coming up with a standardized format
for tests, and a way to express tests in XML... and then rather than
configuring the mimedefang-filter file, you just configure the XML
script as a series of tests to run (I was working on a commercial
H.323 gatekeeper implementation that does call admission control
this way, and it seemed pretty powerful).

The downside of this method is that the mimedefang-filter file would
have to contain all (or almost all) possible tests, and have an "engine"
that loaded and parsed the XML script, calling out the appropriate
methods to implement that tests... tests would return one of three
possible values, ACCEPT (without further processing), REJECT
(without further processing), or CONTINUE (test inconclusive,
proceed to next test).

So we'd have to decide on a standard format for the XML test
scripting, and a standard calling convention for the methods embedded
in mimedefang-filter.

One other thing...  about a year ago, I asked about adding a sort of
IP CIDR based set of rules to Mimedefang, and was told to use
rDNS instead of CIDR addresses (or alternatively, country codes)
to block certain parties permanently.

At the time, I grudgingly accepted this bit of common wisdom, but
a year later, I've noticed that this isn't a complete solution.  A lot
of providers don't provide rDNS for their clients... or else the
clients run their own rDNS, and it's either flaky or there are way
too many domains to blacklist them all...  and while the country-
code test also works nicely most of the time, there are instances
where the data is missing or wrong (a lot of entries say "eu" that
aren't, for example).

The bottom line is that rDNS and country-codes alone aren't
sufficient.  There's still a place for CIDR-based tests.

Thanks,

-Philip