Christopher Bort wrote:
> This is really not a SpamAssassin issue, but since this list is
> populated by people who are interested in spammer behavior, I'm throwing
> it out for comment. If it's too far off topic, my apologies and I'll let
> it go at that.
>
> At $DAYJOB I run a mail server and a name server for several domains,
> both our own and for clients. At home, I run a mail server and a name
> server for a couple of personal domains. The home name server is a slave
> for most of the domains hosted at $DAYJOB. The home mail server is _not_
> configured to handle mail for any of the $DAYJOB domains and it is _not_
> an MX for any of those domains. The only connection is that it is an NS
> for the $DAYJOB domains. These domains _do_ have $DAYJOB mail server as
> their MX.
>
> For a while now, I've been seeing attempts to send mail to the home
> server for addresses in $DAYJOB domains. This is not a problem since the
> volume is low and they are being properly rejected as third-party relay
> attempts (authentication required - relay not permitted). However, the
> fact that someone is apparently trying to send mail to an NS instead of
> an existing MX has piqued my curiosity. It looks like it's all spam (the
> sender addresses tend to support that). So, has anyone else seen this
> sort of behavior and what could be the rationale for trying to deliver
> mail to an NS like this?
>

it's the same as port scans. they look for open relays. they don't care
if the host is an MX, an NS, a www or anything. they just connect to the
IP and try to relay. I've seen this on hosts that "nobody should have
known about".

On the other hand, I also see attempts to connect to A hosts (thus
ignoring MX definitions) and to old MXes. This is different as there is
no relay attempt.

Christopher Bort wrote:
> This is really not a SpamAssassin issue, but since this list is
> populated by people who are interested in spammer behavior, I'm throwing
> it out for comment. If it's too far off topic, my apologies and I'll let
> it go at that.
>
> At $DAYJOB I run a mail server and a name server for several domains,
> both our own and for clients. At home, I run a mail server and a name
> server for a couple of personal domains. The home name server is a slave
> for most of the domains hosted at $DAYJOB. The home mail server is _not_
> configured to handle mail for any of the $DAYJOB domains and it is _not_
> an MX for any of those domains. The only connection is that it is an NS
> for the $DAYJOB domains. These domains _do_ have $DAYJOB mail server as
> their MX.
>
> For a while now, I've been seeing attempts to send mail to the home
> server for addresses in $DAYJOB domains. This is not a problem since the
> volume is low and they are being properly rejected as third-party relay
> attempts (authentication required - relay not permitted). However, the
> fact that someone is apparently trying to send mail to an NS instead of
> an existing MX has piqued my curiosity. It looks like it's all spam (the
> sender addresses tend to support that). So, has anyone else seen this
> sort of behavior and what could be the rationale for trying to deliver
> mail to an NS like this?
>

I have, I have also seen attempts to send to the A record as well. I see
no rational explanation except for the hope a poorly configured server
running multiple services (DNS, Web, Mail, etc) will let something slip
through.

DAve


--
Don't tell me I'm driving the cart!

On 07/21/08 13:04, mouss@netoyen.net (mouss) wrote:

>Christopher Bort wrote:
>>
>>For a while now, I've been seeing attempts to send mail to the
>>home server for addresses in $DAYJOB domains. This is not a
>>problem since the volume is low and they are being properly
>>rejected as third-party relay attempts (authentication
>>required - relay not permitted). However, the fact that
>>someone is apparently trying to send mail to an NS instead of
>>an existing MX has piqued my curiosity. It looks like it's all
>>spam (the sender addresses tend to support that). So, has
>>anyone else seen this sort of behavior and what could be the
>>rationale for trying to deliver mail to an NS like this?
>
>it's the same as port scans. they look for open relays. they don't
>care if the host is an MX, an NS, a www or anything. they just connect
>to the IP and try to relay. I've seen this on hosts that "nobody
>should have known about".

But they don't seem to be randomly looking for any open relay.
If they were just looking for open relays, wouldn't you expect
to see domains in the recipient addresses that have no
connection whatsoever with the target machine? In all of the
relay attempts I'm seeing on this mail server, the recipient
addresses are in domains for which the server is an NS. I don't
see any relay attempts where that is not true which implies, I
think, that they do care that it's an NS. It seems like they're
looking for hosts that will deliver|relay messages for specific
domains, so why don't they just use the existing MX rather than
trying an NS host with which there's no reasonable expectation
that it will relay for the target domain? I suppose they could
be looking for back doors, but that seems like it would be a
very low probability undertaking.

>On the other hand, I also see attempts to connect to A hosts (thus
>ignoring MX definitions) and to old MXes. This is different as there
>is no relay attempt.

The RFCs allow for A hosts to be tried in the absence of MX
records, so there is some rationale for that, however weak it
may be.

--
Christopher Bort

Christopher Bort wrote:
> In all of the relay attempts I'm seeing on this mail server, the
> recipient addresses are in domains for which the server is an NS.

They are looking for any connection possible. A nameserver is an
association. They will hope that perhaps it allows mail. Unlikely to
the extreme but not inconceivable.

> I think, that they do care that it's an NS. It seems like they're
> looking for hosts that will deliver|relay messages for specific
> domains, so why don't they just use the existing MX rather than
> trying an NS host with which there's no reasonable expectation that
> it will relay for the target domain?

You are trying to apply logic to a situation to which no reason can be
applied. Spammers do not operate with a sanity of reason and logic.
There is intelligence. But bludgeoning others for their own gain only
makes sense to them and not to members of society.

> I suppose they could be looking for back doors, but that seems like
> it would be a very low probability undertaking.

Spammers base their existence upon extremely low probabilities
multiplied by very large numbers of messages.

Bob

Christopher Bort wrote:
> This is really not a SpamAssassin issue, but since this list is
> populated by people who are interested in spammer behavior, I'm
> throwing it out for comment. If it's too far off topic, my apologies
> and I'll let it go at that.
>
> At $DAYJOB I run a mail server and a name server for several domains,
> both our own and for clients. At home, I run a mail server and a name
> server for a couple of personal domains. The home name server is a
> slave for most of the domains hosted at $DAYJOB. The home mail server
> is _not_ configured to handle mail for any of the $DAYJOB domains and
> it is _not_ an MX for any of those domains. The only connection is
> that it is an NS for the $DAYJOB domains. These domains _do_ have
> $DAYJOB mail server as their MX.
>
> For a while now, I've been seeing attempts to send mail to the home
> server for addresses in $DAYJOB domains. This is not a problem since
> the volume is low and they are being properly rejected as third-party
> relay attempts (authentication required - relay not permitted).
> However, the fact that someone is apparently trying to send mail to an
> NS instead of an existing MX has piqued my curiosity. It looks like
> it's all spam (the sender addresses tend to support that). So, has
> anyone else seen this sort of behavior and what could be the rationale
> for trying to deliver mail to an NS like this?
>

I don't consider it off topic at all. I'm going to look into this. Seems
like a way to feed right into my blacklist.

On 07/21/08 14:09, bob@proulx.com (Bob Proulx) wrote:

>Christopher Bort wrote:
>>In all of the relay attempts I'm seeing on this mail server, the
>>recipient addresses are in domains for which the server is an NS.
>
>They are looking for any connection possible. A nameserver is an
>association. They will hope that perhaps it allows mail. Unlikely to
>the extreme but not inconceivable.
>
>>I think, that they do care that it's an NS. It seems like they're
>>looking for hosts that will deliver|relay messages for specific
>>domains, so why don't they just use the existing MX rather than
>>trying an NS host with which there's no reasonable expectation that
>>it will relay for the target domain?
>
>You are trying to apply logic to a situation to which no reason can be
>applied. Spammers do not operate with a sanity of reason and logic.
>There is intelligence. But bludgeoning others for their own gain only
>makes sense to them and not to members of society.

True enough. I suppose it's a good thing that I'm not entirely
able to think like a spammer. ;-)

>>I suppose they could be looking for back doors, but that seems like
>>it would be a very low probability undertaking.
>
>Spammers base their existence upon extremely low probabilities
>multiplied by very large numbers of messages.

True again. Your comments essentially reflect my own assessment,
but I was curious enough about it to bring it up on a list like
this one to see if I was missing some twist that would make an
iota of sense, but I guess not. I'll let it go now. 8^) Even
though there's no actual problem, it's still a low grade
irritant to me that someone out there is stupid enough to bang
their head against this wall.

--
Christopher Bort

Christopher Bort wrote:
> Bob Proulx wrote:
> > You are trying to apply logic to a situation to which no reason can be
> > applied. Spammers do not operate with a sanity of reason and logic.
> > There is intelligence. But bludgeoning others for their own gain only
> > makes sense to them and not to members of society.
>
> True enough. I suppose it's a good thing that I'm not entirely
> able to think like a spammer. ;-)

People who see the exploits that are possible but work for the good of
others are called "whitehats". Bruce Schneier made an interesting
comment concerning ant farms related to this type of mindset[1].

I think the important thing is that if you are one of those that
always see how things can fail or be exploited that you work to solve
the problems. (This is where test driven development comes from and
where security comes from and so forth.) And that if you are not one
of those people that you don't become a block to improvements. Too
often people close their eyes, put their fingers in their ears and
hum. Instead they should be receptive to people trying to help them.

> > Spammers base their existence upon extremely low probabilities
> > multiplied by very large numbers of messages.
>
> True again. Your comments essentially reflect my own assessment,
> but I was curious enough about it to bring it up on a list like
> this one to see if I was missing some twist that would make an
> iota of sense, but I guess not.

It does make sense. You don't see it from the spammer's perspective.
Someone who is running a nameserver for a domain just might at some
very small probability be slightly more likely to allow relaying for
that domain than other random servers on the network.

But I think it is the reverse. I think a nameserver for a domain is
more likely to be locked down for relays to that domain. I think
nameservers for a domain would be less likely to relay than random
other machines on the network. But obviously at least one spammer is
testing this theory.

Spammers are already working at very, very low probabilities and so
poking at another low one isn't a problem. So for the spammer it
makes sense to try wild ideas even if the likelihood is extremely
small of it being fruitful.

> I'll let it go now. 8^) Even though there's no actual problem, it's
> still a low grade irritant to me that someone out there is stupid
> enough to bang their head against this wall.

I think it is good that you brought this up and allowed people to
notice this behavior. Perhaps it will be useful to use in relation to
generating block lists. Who knows? It is interesting. I don't think
it is particularly unexpected. In this particular case though they
are way behind the power curve. They are working behind the years of
learning and selection that running any type of open mail relay is
unacceptable.

As far as spammers being stupid, I disagree. I think they show
definite intelligence. The first time I observed a distributed
spamming engine in operation I was definitely impressed.
Unfortunately it is an evil intelligence. It works not for the public
good but against it. Being annoying along the way is just one of the
lessor ways that they show that they care nothing about others.

Bob

[1] http://www.wired.com/politics/securi...tymatters_0320

On Mon, 2008-07-21 at 12:30 -0700, Christopher Bort wrote:

> For a while now, I've been seeing attempts to send mail to the
> home server for addresses in $DAYJOB domains. This is not a
> problem since the volume is low and they are being properly
> rejected as third-party relay attempts (authentication required
> - relay not permitted). However, the fact that someone is
> apparently trying to send mail to an NS instead of an existing
> MX has piqued my curiosity. It looks like it's all spam (the
> sender addresses tend to support that).

Marc, this might be another way for you to collect your spam zombie
data. Offer a free public secondary-DNS service and run your dummy MTA
on that box. That way you're inherently rewarding (at least a little
bit) the people who are cooperating to provide you data.

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
If Microsoft made hammers, everyone would whine about how poorly
screws were designed and about how they are hard to hammer in, and
wonder why it takes so long to paint a wall using the hammer.
-----------------------------------------------------------------------
Today: the 39th anniversary of Man's first steps on the Moon

On Mon, 2008-07-21 at 14:01 -0700, Christopher Bort wrote:
> I suppose they could
> be looking for back doors, but that seems like it would be a
> very low probability undertaking.

Other people's CPU cycles and net bandwidth are cheap (at least for
spammers). If they hit one in fifty thousand as an open relay, it's a
net win for them.

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
If Microsoft made hammers, everyone would whine about how poorly
screws were designed and about how they are hard to hammer in, and
wonder why it takes so long to paint a wall using the hammer.
-----------------------------------------------------------------------
Today: the 39th anniversary of Man's first steps on the Moon

Christopher Bort wrote:
> This is really not a SpamAssassin issue, but since this list is
> populated by people who are interested in spammer behavior, I'm
> throwing it out for comment. If it's too far off topic, my apologies
> and I'll let it go at that.
>
> At $DAYJOB I run a mail server and a name server for several domains,
> both our own and for clients. At home, I run a mail server and a name
> server for a couple of personal domains. The home name server is a
> slave for most of the domains hosted at $DAYJOB. The home mail server
> is _not_ configured to handle mail for any of the $DAYJOB domains and
> it is _not_ an MX for any of those domains. The only connection is
> that it is an NS for the $DAYJOB domains. These domains _do_ have
> $DAYJOB mail server as their MX.
>
> For a while now, I've been seeing attempts to send mail to the home
> server for addresses in $DAYJOB domains. This is not a problem since
> the volume is low and they are being properly rejected as third-party
> relay attempts (authentication required - relay not permitted).
> However, the fact that someone is apparently trying to send mail to an
> NS instead of an existing MX has piqued my curiosity. It looks like
> it's all spam (the sender addresses tend to support that). So, has
> anyone else seen this sort of behavior and what could be the rationale
> for trying to deliver mail to an NS like this?
>
I have seen that spammers usually target most available "A" records of
a domain
So if a domain is example.com All machines , mail.example.com ,
example.com , ns.example.com etc are all targeted.

Remove the A record ns.example.com ( if possible ) and you will see
spams disappear

Unfortunately this works :-( in evading spam filters in far too many
cases. A lot of domains host their websites/mailboxes/DNS on shared
servers who do not offer any protection at SMTP levels .Even if the
customer subscribes to a third party Antispam solution and points his MX
to a spam filter the spammer easily sends his mail to the unportected
mailhost server and gets straight to the inbox. We ourselves had
extremely tough times explaining to clients

Probably Spamassassin Comunity needs to develop a email client plugin
that can detect such mails

Thanks
Ram






================================================== =================
sms START NEWS to 09845398453 for Breaking News and Top
Stories on Business, Sports & Politics. For more services visit
http://www.mytodaysms.com
================================================== =================

There's people out there who are better and faster programmers than I
am. I need a simple utility written We can post it on the SA Wiki when
we're done.

I don't care what it's written in but I'm thinking that xinetd might be
easiest. What I want is something to record the IP address of any host
connection to port 25. Then going to need it to run a one line script
file that runc netcat (nc) and sends me data. Basically I just need te
IP address. I have a collector program listening that feeds the
blacklist system. The collector is.

echo "$*" | nc -w 2
exit 0

The idea of this project is to collect hits on port 25 of computers that
shouldn't be hit on port 25. Thses hits would be 100% spambots and
hackers. They hit it - they get listed.

I'll share my collector code, which is a one line script.

socat -u TCP4-LISTEN:,reuseaddr,fork OPEN:/logfile &

The pair of these programs can be used to collect any kind of data base
on trouble makers hitting port that shouldn't be hit. This could be used
for ssh attempts - anything. These programs feed IP collection systems
and then some task manages the list, rotates it, and generates DNS
blacklists.

I'm thinking such a system might be really useful.

Who likes this idea?

Marc Perkel wrote:
> There's people out there who are better and faster programmers than I
> am. I need a simple utility written We can post it on the SA Wiki when
> we're done.
>
> I don't care what it's written in but I'm thinking that xinetd might
> be easiest. What I want is something to record the IP address of any
> host connection to port 25. Then going to need it to run a one line
> script file that runc netcat (nc) and sends me data. Basically I just
> need te IP address. I have a collector program listening that feeds
> the blacklist system. The collector is.
>
> echo "$*" | nc -w 2
> exit 0
>
You mean you need a script will listen to port 25 instead of a smtpd
daemon ?
Will be a trivial thing to do?
What should this do , just log to syslog the IP's and break connection
immediately after connect





> The idea of this project is to collect hits on port 25 of computers
> that shouldn't be hit on port 25. Thses hits would be 100% spambots
> and hackers. They hit it - they get listed.
>
> I'll share my collector code, which is a one line script.
>
> socat -u TCP4-LISTEN:,reuseaddr,fork OPEN:/logfile &
>
> The pair of these programs can be used to collect any kind of data
> base on trouble makers hitting port that shouldn't be hit. This could
> be used for ssh attempts - anything. These programs feed IP collection
> systems and then some task manages the list, rotates it, and generates
> DNS blacklists.
>
> I'm thinking such a system might be really useful.
Yes , I think that would give a zero fp blacklist on ip's
Any real MTA would mx lookup ,
IMO If mail is sent on non mx ips the mail is spam and the ip is of a
spammer
(internal misconfigured transport relays need to be excluded )









================================================== =================
sms START NEWS to 09845398453 for Breaking News and Top
Stories on Business, Sports & Politics. For more services visit
http://www.mytodaysms.com
================================================== =================

Ramprasad wrote:
> Marc Perkel wrote:
>> There's people out there who are better and faster programmers than I
>> am. I need a simple utility written We can post it on the SA Wiki
>> when we're done.
>>
>> I don't care what it's written in but I'm thinking that xinetd might
>> be easiest. What I want is something to record the IP address of any
>> host connection to port 25. Then going to need it to run a one line
>> script file that runc netcat (nc) and sends me data. Basically I just
>> need te IP address. I have a collector program listening that feeds
>> the blacklist system. The collector is.
>>
>> echo "$*" | nc -w 2
>> exit 0
>>
> You mean you need a script will listen to port 25 instead of a smtpd
> daemon ?
> Will be a trivial thing to do?
> What should this do , just log to syslog the IP's and break connection
> immediately after connect
>
>
Yes - the idea being that you have some service, like a name server,
that there is no reason at all that anything should be connecting to
port 25 on and everything that attempts to connect on it is spam. So
it's not an MTA but just a script (xinetd -> shel script - or perl) that
closes the connection immediately and sends the IP to a central
collector that accumulates information and builds blacklists that can be
used by Spamassassin.

>
>
>
>> The idea of this project is to collect hits on port 25 of computers
>> that shouldn't be hit on port 25. Thses hits would be 100% spambots
>> and hackers. They hit it - they get listed.
>>
>> I'll share my collector code, which is a one line script.
>>
>> socat -u TCP4-LISTEN:,reuseaddr,fork OPEN:/logfile &
>>
>> The pair of these programs can be used to collect any kind of data
>> base on trouble makers hitting port that shouldn't be hit. This could
>> be used for ssh attempts - anything. These programs feed IP
>> collection systems and then some task manages the list, rotates it,
>> and generates DNS blacklists.
>>
>> I'm thinking such a system might be really useful.
> Yes , I think that would give a zero fp blacklist on ip's
> Any real MTA would mx lookup ,
> IMO If mail is sent on non mx ips the mail is spam and the ip is of a
> spammer
> (internal misconfigured transport relays need to be excluded )
>
>

Yep - you got it.

Marc Perkel wrote:

> I don't care what it's written in but I'm thinking that xinetd might be
> easiest. What I want is something to record the IP address of any host
> connection to port 25.

You don't really need to accept the connection. Just logging
connection attenmpts should be enough.

As an examplem something like this (watch for wrapping):

tcpdump -lnpqt -i vr0 'tcp[13] & 2 != 0 and dst port 25 and dst
host 195.67.112.220'

Should output lines like:

213.163.128.161.48278 > 195.67.112.220.25: tcp 0 (DF)
213.163.128.161.48279 > 195.67.112.220.25: tcp 0 (DF)
190.84.222.78.2106 > 195.67.112.220.25: tcp 0 (DF)

for each connection attempt to port 25 on 195.67.112.220.

If port 25 is firewalled usinbg pf, vr0 should probably be
replaced with "pflog0". Similar setup should be doable with other
firewalls that create a log interface for tcpdump.

Then you can filter that output to remove evevrything but the IP
address.

For example

tcpdump -lnpqt -i vr0 'tcp[13] & 2 != 0 and dst port 25 and dst
host 195.67.112.220' | sed -e 's/\.[0-9]* .*$//'

should output just the IP numbers.

So maybe something like this should work:

tcpdump -lnpqt -i 'tcp[13] & 2 != 0 and dst port 25
and dst host ' | sed -e 's/\.[0-9]* .*$//' | nc -u 2


It could be running in a detached session. (And yes, the '-u' is
on purpose, I think UDP is good for this kind of thing.)

Please not that the above is untested and that I'm not used to
working with sed or netcat.

Regards
/Jonas
--
Jonas Eckerman, FSDB & Fruktträdet
http://whatever.frukt.org/
http://www.fsdb.org/
http://www.frukt.org/

Quoting Marc Perkel :

>
>
> Ramprasad wrote:

>>> I don't care what it's written in but I'm thinking that xinetd
>>> might be easiest. What I want is something to record the IP
>>> address of any host connection to port 25. Then going to need it
>>> to run a one line script file that runc netcat (nc) and sends me
>>> data. Basically I just need te IP address. I have a collector
>>> program listening that feeds the blacklist system. The collector is.
>>>

Here is a little program I wrote a while back for just this purpose.
Change lines 58ff as you see fit for your purposes. I have modified
the listening port to 25 and put a plausible looking banner lines on it.

also I have attached an RC file to start it up. Let me know how it works out.

jp









--
Framework? I don't need no steenking framework!

----------------------------------------------------------------
@fferent Security Labs: Isolate/Insulate/Innovate
http://www.afferentsecurity.com

Jonas - thanks for your code. I ran it on one of my name servers that is
the name server for several hundred domains. Unfortunately in the last
hour only 3 IP addresses have hit trying to talk to port 25. So this
isn't turning out to be the wellspring of blacklist data I had hoped it
would be.

Jonas Eckerman wrote:
> Marc Perkel wrote:
>
>> I don't care what it's written in but I'm thinking that xinetd might
>> be easiest. What I want is something to record the IP address of any
>> host connection to port 25.
>
> You don't really need to accept the connection. Just logging
> connection attenmpts should be enough.
>
> As an examplem something like this (watch for wrapping):
>
> tcpdump -lnpqt -i vr0 'tcp[13] & 2 != 0 and dst port 25 and dst host
> 195.67.112.220'
>
> Should output lines like:
>
> 213.163.128.161.48278 > 195.67.112.220.25: tcp 0 (DF)
> 213.163.128.161.48279 > 195.67.112.220.25: tcp 0 (DF)
> 190.84.222.78.2106 > 195.67.112.220.25: tcp 0 (DF)
>
> for each connection attempt to port 25 on 195.67.112.220.
>
> If port 25 is firewalled usinbg pf, vr0 should probably be replaced
> with "pflog0". Similar setup should be doable with other firewalls
> that create a log interface for tcpdump.
>
> Then you can filter that output to remove evevrything but the IP address.
>
> For example
>
> tcpdump -lnpqt -i vr0 'tcp[13] & 2 != 0 and dst port 25 and dst host
> 195.67.112.220' | sed -e 's/\.[0-9]* .*$//'
>
> should output just the IP numbers.
>
> So maybe something like this should work:
>
> tcpdump -lnpqt -i 'tcp[13] & 2 != 0 and dst port 25 and
> dst host ' | sed -e 's/\.[0-9]* .*$//' | nc -u 2
>
> It could be running in a detached session. (And yes, the '-u' is on
> purpose, I think UDP is good for this kind of thing.)
>
> Please not that the above is untested and that I'm not used to working
> with sed or netcat.
>
> Regards
> /Jonas

Ramprasad wrote:
> Marc Perkel wrote:
>> There's people out there who are better and faster programmers than I
>> am. I need a simple utility written We can post it on the SA Wiki when
>> we're done.
>>
>> I don't care what it's written in but I'm thinking that xinetd might
>> be easiest. What I want is something to record the IP address of any
>> host connection to port 25. Then going to need it to run a one line
>> script file that runc netcat (nc) and sends me data. Basically I just
>> need te IP address. I have a collector program listening that feeds
>> the blacklist system. The collector is.
>>
>> echo "$*" | nc -w 2
>> exit 0
>>
> You mean you need a script will listen to port 25 instead of a smtpd
> daemon ?
> Will be a trivial thing to do?
> What should this do , just log to syslog the IP's and break connection
> immediately after connect
>
>
>
>
>
>> The idea of this project is to collect hits on port 25 of computers
>> that shouldn't be hit on port 25. Thses hits would be 100% spambots
>> and hackers. They hit it - they get listed.
>>
>> I'll share my collector code, which is a one line script.
>>
>> socat -u TCP4-LISTEN:,reuseaddr,fork OPEN:/logfile &
>>
>> The pair of these programs can be used to collect any kind of data
>> base on trouble makers hitting port that shouldn't be hit. This could
>> be used for ssh attempts - anything. These programs feed IP collection
>> systems and then some task manages the list, rotates it, and generates
>> DNS blacklists.
>>
>> I'm thinking such a system might be really useful.
> Yes , I think that would give a zero fp blacklist on ip's
> Any real MTA would mx lookup ,
> IMO If mail is sent on non mx ips the mail is spam and the ip is of a
> spammer
> (internal misconfigured transport relays need to be excluded )

There is one caveat in this argument. yes, an MTA would lookup the MX.
but it is the MX as seen in DNS, not as seen in _your_ zone.

in short, if someone declares you as their MX (without your
authorization), you should not start listing clients that try to send
mail to such domains.

This is one problem with the MX "standard". anybody can list your
servers as their MX. there is no authorization mechanism.

so when collecting such "anomalies", you need to do some checks before
listing the client. as a result, you need the "intended" recipient. in
which case, a real smtp daemon is the right choice.

On Tue, 2008-07-22 at 11:37 -0400, Kevin Parris wrote:

> I believe that until a technique is discovered to eliminate ignorance and gullibility from the human population, there will be no solution to the spam problem.

Nah, spammers just need to start dying messy, well-publicised deaths.
The cost side of the cost/benefit analysis needs to be increased, and
trying to increase that cost within the technology-based part of the
system is doomed to failure given the amazing ability of technology to
reduce communication costs.

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
End users want eye candy and the "ooo's and aaaahhh's" experience
when reading mail. To them email isn't a tool, but an entertainment
form. -- Steve Lake
-----------------------------------------------------------------------
13 days until the 273rd anniversary of John Peter Zenger's acquittal

On Tue, Jul 22, 2008 at 12:00 PM, Bob McClure Jr wrote:

> If I may extend this OT thread, I'd like to know how draconian admins
> get with their mail servers. Without considering RBLs, how much do
> you limit client connections:
>
> Allow only those with (PTR and/or A) DNS records?


It's becoming common to reject clients with no PTR, but there are still many
legit hosts using an ISP that doesn't offer PTR. So this is not universally
acceptable and prone to false positives. This also isn't terribly effective
since many botted machines have proper DNS entries.

It would be nice if all ISP's firewalled port 25 and offered a self-service
interface so the customer could unblock it if they run a server. 99% of
customers would never notice that port 25 was blocked.



> Allow only those with MX records?


You mean only accept mail if the sender domain lists the client as an MX?
That doesn't work - too many orginazations use split systems where sending
and receiving hosts are on different IPs or even different netblocks.

SPF is a start at giving the sender control over what IPs are allowed to
send mail, but it's not without problems.



>
>
> I figure only the latter will be the Final Solution to spam. But
> there are probably only two chances of that - slim and none.


There isn't a Final Solution without replacing SMTP with something else, and
there is no agreement on what the "something else" should look like. Likely
it too would be exploited, but in new and interesting ways...


--
Noel Jones