All the Transaction Filter files here make your transflt.mer file bigger than your current transflt.mer file. You will need to use a text editor, as the file becomes too big for Mercury's built-in editor, which has a 32K limit in file size. USE AN OUTSIDE TEXT EDITOR when making changes!
{the actual file is missing. If you have a copy, please email me}
transadd.txt
add to the bottom of your own working transflt.mer
or replace the old [dated] section you added before
These are
my expressions which are added to the original transflt.mer to create
my replacement transall.txt.
This file has several sections of expressions matching:
1. Dynamic or other wacko netrange identities. Remember, we're not
blocking because the IP is dynamic, it's because the incoming connecting
server is IDENTIFYINIG itself as dynamic or in a way that a real mail server
would not: for instance #.#.#.#.*.*
Above connections are DROPped and blacklisted for
30 minutes
The following remaining Sections are Refused and given
the error message 554.
2. Special lines to catch third-world *#.#.#.#* connections.
3. Spam sources which actually identify themselves as to who they
are.
For example: freelotto.com
4. SUBJECTS section which I have not developed. I'm hoping someone
will send me a nice verfied and strong list of Subjects to add here.
In the Transaction Filter files I offer, we monitor:
These last two, spammer domains and Subject content are fairly
self-evident why we are lookinig at them.... it's the very content we wish
to filter out.
But the first set of expressions, the HELO expressions, takes a lot
more judgement. I take a very large dose of caution when I write these
expressions.
If one sits back and really thinks about it, one can easily see that a mail
administrator is highly unlikely to ever name a mail server or MX relay with
it's full IP address, like this:
mail.#.#.#.#.domain.name.com
That would be very strange and I've never seen a legitimate mail server use
even three numbers like that: *.#.#.#.domain.name.com
Personally, I would feel fairly safe to filter for any incoming quad-numbers
or other obvious signs in an incoming HELO:
*[0-9]+.[0-9]+.[0-9]+.[0-9]+.* or *.dialup* or *dynamic*
Persons running their own small server or operating with lots of children,
like at a school, may in fact want to do this.
But in designing a public list that could be reliably expected not to create
false-positives, I have developed the list from:
Essentially we are looking for incoming mail engines identifying
themselves with wacko or dialup or dynamic netrange identities.
Remember, we're not blocking because the IP is dynamic, it's because the
incoming connecting server is IDENTIFYING itself in a way that a real
mail server would not identify itself:
And example is using it's quad IP numbers: #.#.#.#.*.*
Take a look at
c68.187.148.76.stc.mn.charter.com to see what I mean.
(Often such lookups are shown to be on infected trojan lists...)
As I wrote in the Mercury support email list:
the new Transaction filtering wonderfully
lets me block a lot of them with little chance of false-positives.
Here's my thinking: Although, yes, some people really do run mail servers
on dynamic IP connections (I did for a while when static was not available
locally), none, to my way of thinking, would identify their server that way.
For instance, in Mercury, we tell it what to Announce itself as: in my
case, mail.listserver.info.
I would never give my mail server the DNS name of a dynamic IP such as
user-cablemodem-somenumber.rr.com
However, lots of spam engines out there know that some servers reject mail
which has no response for a DNS lookup -- so the spam engine, checks it's
IP, looks it up, and uses it's name to identify itself. (at least that's
how *I* think it works)
So I do transaction blocking for any mail server that identifies itself as
on a dynamic range.
Examples:
ppp-6*.dialup.*.swbell.net
216-229-*-cablemodem*.fidnet.com
cm61*.hkcable.com.hk
Another clue is multiple dotted numbers in the name:
c24.#.#.#.dul.mn.charter.com
who would name a mail server like that? Not many, thinks I.
another looks like this:
pool-???-#-#-#.#.east.verizon.net
notice this uses - (dash/hyphen) instead of dots.
sometimes they use the "_" underline character
So take a look at http://listserver.info/mercury/Transaction/transadd.txt
and let me know what you think
I now have half the volume of mail for Mercury to sift through.
Pretty good for a simple Transaction filter! Good Going David!
|
One last
point which I think is critical: someone deliberately arranged for
these mail engines to announce themselves the way they are. THOUSANDS
of them. And every one that I've ever seen was delivering spam. Every
legitimate mail server I've ever seen had something sensible such as
mail09.wanadoo.fr
or
RELAY01.AOL.COM
but
not
ip#.#.#.#.something.aol.com
or
user.blah.number.number.number.blah.wanadoo.fr
So I ask myself the question: Just who does want to announce themselves that
way? The first answer that comes to me is a spammer who knows that
some mail servers will not accept email from an IP that will not DNS-resolve
to a name. But if the spam engine software writer (or trojan proxie
writer) hard-codes the announcement, then we'd all just refuse that connection.
So they developed a technique: they do a DNS look of the IP they are on and
then use the resulting identity.
That fools some servers, but it also gives us an open door to seeing when
this is happening.
By the way. At the time of this writing, I'm firmly in the belief that
most of these types of connections are from trojan-infected machines which
are infected with SoBig or a "non-destructive" virus of which the payload
is planting spam relaying engines which identify themselves with the DNS
name of the IP they are on.
If this is true, I'm sorry to say that the next big virus that plants mail
relay engines/proxies might not use this technique for it's announcement.
But as of January 2004 those engines are still running full blast. Have Fun
with my files while we can!
Questions: