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.

My Thoughts On Using Transaction Filtering To Block Spam

In the Transaction Filter files I offer, we monitor:

• the HELO announcement used by the incoming connection which wishes to deposit mail in our system.
• known spammer domains, such as freelotto.com
• we look at the Subject, such as Prescripti0n or va|ium

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:

• looking up incoming spam HELOs at http://openrbl.org     --    like this: c68.187.148.76.stc.mn.charter.com
• looked for some other indicator, such as the word cablemodem

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: