please dont rip this site

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:

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:

See also:


file: /Techref/inet/smtppop3/mercury/transadd.htm, 11KB, , updated: 2020/6/24 09:28, local time: 2020/7/3 03:13,
TOP NEW HELP FIND: 
3.235.22.104:LOG IN

 ©2020 These pages are served without commercial sponsorship. (No popup ads, etc...).Bandwidth abuse increases hosting cost forcing sponsorship or shutdown. This server aggressively defends against automated copying for any reason including offline viewing, duplication, etc... Please respect this requirement and DO NOT RIP THIS SITE. Questions?
Please DO link to this page! Digg it! / MAKE!

<A HREF="http://www.piclist.com/Techref/inet/smtppop3/mercury/transadd.htm"> inet smtppop3 mercury transadd</A>

After you find an appropriate page, you are invited to your to this massmind site! (posts will be visible only to you before review) Just type in the box and press the Post button. (HTML welcomed, but not the <A tag: Instead, use the link box to link to another page. A tutorial is available Members can login to post directly, become page editors, and be credited for their posts.


Link? Put it here: 
if you want a response, please enter your email address: 
Attn spammers: All posts are reviewed before being made visible to anyone other than the poster.
Did you find what you needed?

  PICList 2020 contributors:
o List host: MIT, Site host massmind.org, Top posters @20200703 RussellMc, Bob Blick, Jason White, Neil, David C Brown, madscientistatlarge, Sean Breheny, Harold Hallikainen, James Cameron, Allen Mulvey,
* Page Editors: James Newton, David Cary, and YOU!
* Roman Black of Black Robotics donates from sales of Linistep stepper controller kits.
* Ashley Roll of Digital Nemesis donates from sales of RCL-1 RS232 to TTL converters.
* Monthly Subscribers: Gregg Rew. on-going support is MOST appreciated!
* Contributors: Richard Seriani, Sr.
 

Welcome to www.piclist.com!

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  .