You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Steve Radich <st...@bitshop.com> on 2008/02/21 21:48:31 UTC
Bogus MX -> blacklist service viable?
What's everyone's opinion on something like:
defermx.<domain>.com
bogusmx.<domain>.com
provide this hosted (i.e. I'm thinking of offering), but instead of ONLY
log it somehow feed / create a blacklist based on this?
I'm not as familiar with blacklists as many of you, but the network /
smtp / logging side of this is easy for me to implement.
I'm thinking make this a very public (free) service to gather data for
the blacklist, anyone could list the mx.
Thoughts?
Steve Radich - http://www.aspdeveloper.net /
http://www.virtualserverfaq.com
BitShop, Inc. - Development, Training, Hosting, Troubleshooting -
http://www.bitshop.com
Large spam IP list - was Re: Bogus MX -> blacklist service viable?
Posted by Larry Ludwig <la...@gmail.com>.
> 79.137.219.171
> 79.137.223.42
> 79.137.225.194
> 79.137.231.242
> 79.137.233.223
> 79.137.235.210
> 79.137.235.252
> 79.137.237.210
Slightly off subject,
This list of class Cs appears to be a HUGE block 79.137.170ish.0/24 -
79.137.240.0ish a russian spam gang. They appear to right now be using the
odd ending class/24s. I suspect they will be using the evens in the next
few weeks.
-L
--
Larry Ludwig
Empowering Media
1-866-792-0489 x600
Managed and Unmanaged Xen VPSes
http://www.hostcube.com/
Re: Bogus MX -> blacklist service viable?
Posted by Marc Perkel <ma...@perkel.com>.
Rob McEwen wrote:
> Aaron Wolfe wrote:
>> I have 24 hours of data to play with.. at first results seemed
>> promising. I found over 300,000 hosts that had connected only to my
>> highest MX and did not issue a quit. But.. of that group:
>>
>> 96.0% are listed on spamhaus (zen, i did not breakdown onto the
>> individual lists)
>> 2.3% of the hosts *not* listed on spamhaus are listed on Rob McEwen's
>> ivmSIP list (note that this is over 50% of the remaining hosts, about
>> 10% higher than this list's hit rate with my normal mail flow).
>> ...<snip>...
>> I'm sure my quick test is not perfect. The remaining 1.7% of hosts
>> may include some amount of non spam sources (very small if any I would
>> guess). Also, I ran the RBL checks all at once at the end of the
>> cycle. so some of the hits were 24 hours old. Some amount of the
>> remainder were probably on the RBLs at the time they hit my server and
>> were since removed
>
> Aaron,
>
> Here are my thoughts/observations:
>
> Assuming that you ran these dnsbl checks *after* the 24 hour period
> (as I think you are saying...), then I believe that the 96% "also
> caught by Zen" would probably be lower, not higher. IPs (from recent
> spam!) don't generally expire out of any lists THAT quickly, if at
> all. However, in contrast, there is typically a propagation delay
> before *some* of these get into DNSBLs. (this delay can vary widely
> between dnsbls). So if you ran this test after the fact, you actually
> gave Zen some time to "catch up".
>
> You mentioned that, of these "IPs that only connected to the highest
> MX" batch, half of the IPs that Zen didn't catch were already on "Rob
> McEwen's ivmSIP list". Thanks for the plug!
>
> But I fear that this may accidentally paint an inaccurate picture of
> ivmSIP. This seems to imply that half my list is made up of IPs that
> would be caught if someone were using the "connected only to the
> highest MX" method. (I know you didn't intend to imply this.. but
> there is the potential for someone to interpret it that way.) In fact,
> just so *others* will know, I should add that there is MUCH spams that
> my lists catches which the "IPs that only connected to the highest MX"
> method misses.
>
> For example, I took that last 100 ivmSIP catches and ran them against
> Zen.
>
> 88 of these 100 were already caught by Zen.
>
> Of the 12 left, 3 were caught by widely used and respected dnsbls:
>
> 84.79.21.212 (spamcop)
> 200.66.32.226 (dsbl/psbl)
> 212.147.5.133 (spamcop & Mark Perkel's "host karma" list)
>
> As shown, of the 12 left, (and of these three), 1 was caught by
> Perkel's host karma list, which, therefore, is probably the *only* IP
> of these 12 that the "connected only to the highest MX" method would
> have caught.
>
> (of those not caught by zen...)
> While your stats show that 50% of what the "connected only to the
> highest MX" method catches was also caught by ivmSIP. These additional
> stats above show that the "connected only to the highest MX" method
> catches *only* 8% of the spams that ivmSIP catches (again, of those
> not already in Zen.)
>
> Of these twelve, 9 of them are IPs that would NOT have been caught by
> ANY reliable FP-safe DNSBLs, nor would these (likely) be caught by the
> "connected only to the highest MX" method.
>
> Here are those 9 "uniques" (for anyone to examine/critique):
>
> 79.137.219.171
> 79.137.223.42
> 79.137.225.194
> 79.137.231.242
> 79.137.233.223
> 79.137.235.210
> 79.137.235.252
> 79.137.237.210
> 213.254.194.26
>
> 9 "uniques" out of 100 doesn't sound impressive... and most of these
> were already caught by UCEPROTECT's "level 3", but that is UCE's most
> FP-risky list... and certainly a list too FP-riskly to outright block
> or score high on... UCE even states that this list, "probably will
> cause collateral damage to innocent users when used to block email"
>
> But since, in contrast, ivmSIP has an extremely low FP-rate and seeks
> to *not* ever create collateral damage, then, unlike UCE-3, when these
> IPs show up in ivmSIP, they are safe to outright block (or score very
> high, for those who are ultra careful) without fear of FPs.
>
> (of course, during the time it took me to type this message, another
> 1,142 IPs were added to ivmSIP. This was an 'ad hoc" snapshot... I
> suspect that a few of these "uniques" will get into other lists by the
> time that some people read this post. But, in the meantime, spams send
> from these IPs to those who use ivmSIP have been blocked.)
>
> FINAL NOTE: ivmSIP seeks to be a supplemental list focused mostly on
> new series of spams... and purposely skips out on listing spammer's
> IPs that have been in circulation for more than X number of
> weeks/months... therefore, Zen is going to list many IPs that ivmSIP
> isn't even trying to list. So ivmSIP is NOT trying to be a Zen
> replacment, but, instead, more of a supplement.
>
> Rob McEwen
>
Rob - you make a good point about the 24 hours after issue. I can detect
the spambots in almost real time. The combination of the no quit and
only hitting the highest numbered MX takes about 2 minutes. (The
connection inavtivity timeout). Once detected the IP is added to a list
and then on the next 5 minute cycle I have them in my black list ready
for the world to read. What I'm seeing is that I'm blacklisting faster
that Spamhaus is so many of these IPs that overlap 24 hours later might
not overlap if you compared them in real time.
Re: Bogus MX -> blacklist service viable?
Posted by Rob McEwen <ro...@invaluement.com>.
Aaron Wolfe wrote:
> I have 24 hours of data to play with.. at first results seemed
> promising. I found over 300,000 hosts that had connected only to my
> highest MX and did not issue a quit. But.. of that group:
>
> 96.0% are listed on spamhaus (zen, i did not breakdown onto the
> individual lists)
> 2.3% of the hosts *not* listed on spamhaus are listed on Rob McEwen's
> ivmSIP list (note that this is over 50% of the remaining hosts, about
> 10% higher than this list's hit rate with my normal mail flow).
> ...<snip>...
> I'm sure my quick test is not perfect. The remaining 1.7% of hosts
> may include some amount of non spam sources (very small if any I would
> guess). Also, I ran the RBL checks all at once at the end of the
> cycle. so some of the hits were 24 hours old. Some amount of the
> remainder were probably on the RBLs at the time they hit my server and
> were since removed
Aaron,
Here are my thoughts/observations:
Assuming that you ran these dnsbl checks *after* the 24 hour period (as
I think you are saying...), then I believe that the 96% "also caught by
Zen" would probably be lower, not higher. IPs (from recent spam!) don't
generally expire out of any lists THAT quickly, if at all. However, in
contrast, there is typically a propagation delay before *some* of these
get into DNSBLs. (this delay can vary widely between dnsbls). So if you
ran this test after the fact, you actually gave Zen some time to "catch up".
You mentioned that, of these "IPs that only connected to the highest MX"
batch, half of the IPs that Zen didn't catch were already on "Rob
McEwen's ivmSIP list". Thanks for the plug!
But I fear that this may accidentally paint an inaccurate picture of
ivmSIP. This seems to imply that half my list is made up of IPs that
would be caught if someone were using the "connected only to the highest
MX" method. (I know you didn't intend to imply this.. but there is the
potential for someone to interpret it that way.) In fact, just so
*others* will know, I should add that there is MUCH spams that my lists
catches which the "IPs that only connected to the highest MX" method misses.
For example, I took that last 100 ivmSIP catches and ran them against Zen.
88 of these 100 were already caught by Zen.
Of the 12 left, 3 were caught by widely used and respected dnsbls:
84.79.21.212 (spamcop)
200.66.32.226 (dsbl/psbl)
212.147.5.133 (spamcop & Mark Perkel's "host karma" list)
As shown, of the 12 left, (and of these three), 1 was caught by Perkel's
host karma list, which, therefore, is probably the *only* IP of these 12
that the "connected only to the highest MX" method would have caught.
(of those not caught by zen...)
While your stats show that 50% of what the "connected only to the
highest MX" method catches was also caught by ivmSIP. These additional
stats above show that the "connected only to the highest MX" method
catches *only* 8% of the spams that ivmSIP catches (again, of those not
already in Zen.)
Of these twelve, 9 of them are IPs that would NOT have been caught by
ANY reliable FP-safe DNSBLs, nor would these (likely) be caught by the
"connected only to the highest MX" method.
Here are those 9 "uniques" (for anyone to examine/critique):
79.137.219.171
79.137.223.42
79.137.225.194
79.137.231.242
79.137.233.223
79.137.235.210
79.137.235.252
79.137.237.210
213.254.194.26
9 "uniques" out of 100 doesn't sound impressive... and most of these
were already caught by UCEPROTECT's "level 3", but that is UCE's most
FP-risky list... and certainly a list too FP-riskly to outright block or
score high on... UCE even states that this list, "probably will cause
collateral damage to innocent users when used to block email"
But since, in contrast, ivmSIP has an extremely low FP-rate and seeks to
*not* ever create collateral damage, then, unlike UCE-3, when these IPs
show up in ivmSIP, they are safe to outright block (or score very high,
for those who are ultra careful) without fear of FPs.
(of course, during the time it took me to type this message, another
1,142 IPs were added to ivmSIP. This was an 'ad hoc" snapshot... I
suspect that a few of these "uniques" will get into other lists by the
time that some people read this post. But, in the meantime, spams send
from these IPs to those who use ivmSIP have been blocked.)
FINAL NOTE: ivmSIP seeks to be a supplemental list focused mostly on new
series of spams... and purposely skips out on listing spammer's IPs that
have been in circulation for more than X number of weeks/months...
therefore, Zen is going to list many IPs that ivmSIP isn't even trying
to list. So ivmSIP is NOT trying to be a Zen replacment, but, instead,
more of a supplement.
Rob McEwen
Re: Bogus MX -> blacklist service viable?
Posted by Aaron Wolfe <aa...@gmail.com>.
On Fri, Feb 22, 2008 at 7:55 AM, Marc Perkel <ma...@perkel.com> wrote:
>
>
>
> Aaron Wolfe wrote:
>
> On Thu, Feb 21, 2008 at 11:47 PM, Marc Perkel <ma...@perkel.com> wrote:
>
>
> Steve Radich wrote:
> > Sorry; apparently I was unclear.
> >
> > MX records I'm saying as follows:
> > 100 - Real
> > 200 - Real perhaps, as many "real" as you want
> > 300 - Bogus - one that blocks port 25 with tcp reset for example
> > 400 - accept port, logs ip -> blacklist (not to be scored
> > aggressively at all) with a 421/retry.
> >
> > If a whole bunch of places are seeing the same smtp server hitting this
> > 400 level MX then I'm saying that seems like a useful thing to be
> > included in a blacklist using a low score in sa.
> >
> > The point was to offer the 400 level mx as a free service to log the ips
> > quickly for those that don't want to set up the server themselves.
> >
> > In theory the 400 level MX wouldn't be used by "real" smtp very often,
> > hence it's likely a spammer and therefore the IP could be auto
> > blacklisted. Realize I'm NOT proposing we block on this, just score
> > based on this list.
> >
> > Steve Radich - http://www.aspdeveloper.net /
> > http://www.virtualserverfaq.com
> > BitShop, Inc. - Development, Training, Hosting, Troubleshooting -
> > http://www.bitshop.com
> >
> >
>
> I'm actually doing something like that. What I do is track hits on the
> highest MX that has not hit the lowest numbered MX, then because I use
> Exim I can track which IP addresses don't send the QUIT command to close
>
> I am thinking about playing around with the same type of thing here..
> Is this any different from looking for "lost connection after DATA" or
> "lost connection after RCPT" errors in a postfix server's logs? Not
> sure why you can detect this because you run Exim specifically. Or
> am I missing something?
>
> Exim has ACLs that let you do things when the QUIT is received or not
> received. Exim probably has 100x the commans that Postfix does and you can
> do a lot of tricky stuff in Exim that no other MTA has.
>
>
>
>
> the connection. This combination creates a highly reliable blacklist and
> I'm currently tracking about 1.1 million virus infected spambots that
> have tried to spam me in the last 4 days.
>
> It's my hostkarma list.
>
>
>
> Sounds interesting.. do you block based on this list or just use it
> for scoring in SA or something like that? What is the false positve
> rate?
>
>
>
> Yes, I do block based on this list. Ther are some false positives but it's
> rare. I have a way for people to remove themselves from the list. There are
> other criteria that we blacklist on as well that makes for a few FP. But
> it's extremely low. I've put a lot of effort into getting it right.
>
>
Ok... I have 24 hours of data to play with.. at first results seemed
promising. I found over 300,000 hosts that had connected only to my
higest MX and did not issue a quit. But.. of that group:
96.0% are listed on spamhaus (zen, i did not breakdown onto the
individual lists)
2.3% of the hosts *not* listed on spamhaus are listed on Rob McEwen's
ivmSIP list (note that this is over 50% of the remaining hosts, about
10% higher than this list's hit rate with my normal mail flow).
I don't have the zone files for any other RBLs and I didn't want to
send out 300k queries via DNS. But I think the picture is fairly
clear.. a vast majority of the hosts hitting the fake high MX will be
hosts already listed in major RBLs.
I'm sure my quick test is not perfect. The remaining 1.7% of hosts
may include some amount of non spam sources (very small if any I would
guess). Also, I ran the RBL checks all at once at the end of the
cycle. so some of the hits were 24 hours old. Some amount of the
remainder were probably on the RBLs at the time they hit my server and
were since removed.
I will continue to look into this to see if today was a typical day.
Based on these number though... is this a promising way to reduce
server load/blacklist more hosts... or is this pointless? I'm
interested in what people think since the data is so easy to gather
and use, if it makes any sense to use it.
-Aaron
Re: Bogus MX -> blacklist service viable?
Posted by Marc Perkel <ma...@perkel.com>.
Aaron Wolfe wrote:
> On Thu, Feb 21, 2008 at 11:47 PM, Marc Perkel <ma...@perkel.com> wrote:
>
>> Steve Radich wrote:
>> > Sorry; apparently I was unclear.
>> >
>> > MX records I'm saying as follows:
>> > 100 - Real
>> > 200 - Real perhaps, as many "real" as you want
>> > 300 - Bogus - one that blocks port 25 with tcp reset for example
>> > 400 - accept port, logs ip -> blacklist (not to be scored
>> > aggressively at all) with a 421/retry.
>> >
>> > If a whole bunch of places are seeing the same smtp server hitting this
>> > 400 level MX then I'm saying that seems like a useful thing to be
>> > included in a blacklist using a low score in sa.
>> >
>> > The point was to offer the 400 level mx as a free service to log the ips
>> > quickly for those that don't want to set up the server themselves.
>> >
>> > In theory the 400 level MX wouldn't be used by "real" smtp very often,
>> > hence it's likely a spammer and therefore the IP could be auto
>> > blacklisted. Realize I'm NOT proposing we block on this, just score
>> > based on this list.
>> >
>> > Steve Radich - http://www.aspdeveloper.net /
>> > http://www.virtualserverfaq.com
>> > BitShop, Inc. - Development, Training, Hosting, Troubleshooting -
>> > http://www.bitshop.com
>> >
>> >
>>
>> I'm actually doing something like that. What I do is track hits on the
>> highest MX that has not hit the lowest numbered MX, then because I use
>> Exim I can track which IP addresses don't send the QUIT command to close
>>
>
> I am thinking about playing around with the same type of thing here..
> Is this any different from looking for "lost connection after DATA" or
> "lost connection after RCPT" errors in a postfix server's logs? Not
> sure why you can detect this because you run Exim specifically. Or
> am I missing something?
>
Exim has ACLs that let you do things when the QUIT is received or not
received. Exim probably has 100x the commans that Postfix does and you
can do a lot of tricky stuff in Exim that no other MTA has.
>
>> the connection. This combination creates a highly reliable blacklist and
>> I'm currently tracking about 1.1 million virus infected spambots that
>> have tried to spam me in the last 4 days.
>>
>> It's my hostkarma list.
>>
>>
>>
>
> Sounds interesting.. do you block based on this list or just use it
> for scoring in SA or something like that? What is the false positve
> rate?
>
>
Yes, I do block based on this list. Ther are some false positives but
it's rare. I have a way for people to remove themselves from the list.
There are other criteria that we blacklist on as well that makes for a
few FP. But it's extremely low. I've put a lot of effort into getting it
right.
Re: Bogus MX -> blacklist service viable?
Posted by Aaron Wolfe <aa...@gmail.com>.
On Thu, Feb 21, 2008 at 11:47 PM, Marc Perkel <ma...@perkel.com> wrote:
>
>
> Steve Radich wrote:
> > Sorry; apparently I was unclear.
> >
> > MX records I'm saying as follows:
> > 100 - Real
> > 200 - Real perhaps, as many "real" as you want
> > 300 - Bogus - one that blocks port 25 with tcp reset for example
> > 400 - accept port, logs ip -> blacklist (not to be scored
> > aggressively at all) with a 421/retry.
> >
> > If a whole bunch of places are seeing the same smtp server hitting this
> > 400 level MX then I'm saying that seems like a useful thing to be
> > included in a blacklist using a low score in sa.
> >
> > The point was to offer the 400 level mx as a free service to log the ips
> > quickly for those that don't want to set up the server themselves.
> >
> > In theory the 400 level MX wouldn't be used by "real" smtp very often,
> > hence it's likely a spammer and therefore the IP could be auto
> > blacklisted. Realize I'm NOT proposing we block on this, just score
> > based on this list.
> >
> > Steve Radich - http://www.aspdeveloper.net /
> > http://www.virtualserverfaq.com
> > BitShop, Inc. - Development, Training, Hosting, Troubleshooting -
> > http://www.bitshop.com
> >
> >
>
> I'm actually doing something like that. What I do is track hits on the
> highest MX that has not hit the lowest numbered MX, then because I use
> Exim I can track which IP addresses don't send the QUIT command to close
I am thinking about playing around with the same type of thing here..
Is this any different from looking for "lost connection after DATA" or
"lost connection after RCPT" errors in a postfix server's logs? Not
sure why you can detect this because you run Exim specifically. Or
am I missing something?
> the connection. This combination creates a highly reliable blacklist and
> I'm currently tracking about 1.1 million virus infected spambots that
> have tried to spam me in the last 4 days.
>
> It's my hostkarma list.
>
>
Sounds interesting.. do you block based on this list or just use it
for scoring in SA or something like that? What is the false positve
rate?
-Aaron
>
Re: Bogus MX -> blacklist service viable?
Posted by Marc Perkel <ma...@perkel.com>.
Steve Radich wrote:
> Sorry; apparently I was unclear.
>
> MX records I'm saying as follows:
> 100 - Real
> 200 - Real perhaps, as many "real" as you want
> 300 - Bogus - one that blocks port 25 with tcp reset for example
> 400 - accept port, logs ip -> blacklist (not to be scored
> aggressively at all) with a 421/retry.
>
> If a whole bunch of places are seeing the same smtp server hitting this
> 400 level MX then I'm saying that seems like a useful thing to be
> included in a blacklist using a low score in sa.
>
> The point was to offer the 400 level mx as a free service to log the ips
> quickly for those that don't want to set up the server themselves.
>
> In theory the 400 level MX wouldn't be used by "real" smtp very often,
> hence it's likely a spammer and therefore the IP could be auto
> blacklisted. Realize I'm NOT proposing we block on this, just score
> based on this list.
>
> Steve Radich - http://www.aspdeveloper.net /
> http://www.virtualserverfaq.com
> BitShop, Inc. - Development, Training, Hosting, Troubleshooting -
> http://www.bitshop.com
>
>
I'm actually doing something like that. What I do is track hits on the
highest MX that has not hit the lowest numbered MX, then because I use
Exim I can track which IP addresses don't send the QUIT command to close
the connection. This combination creates a highly reliable blacklist and
I'm currently tracking about 1.1 million virus infected spambots that
have tried to spam me in the last 4 days.
It's my hostkarma list.
RE: Bogus MX -> blacklist service viable?
Posted by Steve Radich <st...@bitshop.com>.
Sorry; apparently I was unclear.
MX records I'm saying as follows:
100 - Real
200 - Real perhaps, as many "real" as you want
300 - Bogus - one that blocks port 25 with tcp reset for example
400 - accept port, logs ip -> blacklist (not to be scored
aggressively at all) with a 421/retry.
If a whole bunch of places are seeing the same smtp server hitting this
400 level MX then I'm saying that seems like a useful thing to be
included in a blacklist using a low score in sa.
The point was to offer the 400 level mx as a free service to log the ips
quickly for those that don't want to set up the server themselves.
In theory the 400 level MX wouldn't be used by "real" smtp very often,
hence it's likely a spammer and therefore the IP could be auto
blacklisted. Realize I'm NOT proposing we block on this, just score
based on this list.
Steve Radich - http://www.aspdeveloper.net /
http://www.virtualserverfaq.com
BitShop, Inc. - Development, Training, Hosting, Troubleshooting -
http://www.bitshop.com
-----Original Message-----
From: mouss [mailto:mouss@netoyen.net]
Sent: Thursday, February 21, 2008 8:25 PM
Cc: users@spamassassin.apache.org
Subject: Re: Bogus MX -> blacklist service viable?
McDonald, Dan wrote:
> On Thu, 2008-02-21 at 21:58 +0100, Raymond Dijkxhoorn wrote:
>
>> Hi!
>>
>>
>>> provide this hosted (i.e. I'm thinking of offering), but instead of
ONLY
>>> log it somehow feed / create a blacklist based on this?
>>>
>>> I'm not as familiar with blacklists as many of you, but the network
/
>>> smtp / logging side of this is easy for me to implement.
>>>
>>> I'm thinking make this a very public (free) service to gather data
for
>>> the blacklist, anyone could list the mx.
>>>
>> Whats wrong with :
>>
>> http://www.rfc-ignorant.org/tools/submit_form.php?table=bogusmx
>>
>>
>
> wrong direction. That lists domains that don't have their MX records
> set up properly, not ip addresses that attempt to send mail to sites
> that are not MX records.
>
and the difference is?
if you force our servers to retry each time we connect to your server,
then we will find other people to talk to (in short, we'll BL you)
unless you ask the IETF to modify SMTP by adding a "knocking"
requirement.
Re: Bogus MX -> blacklist service viable?
Posted by mouss <mo...@netoyen.net>.
McDonald, Dan wrote:
> On Thu, 2008-02-21 at 21:58 +0100, Raymond Dijkxhoorn wrote:
>
>> Hi!
>>
>>
>>> provide this hosted (i.e. I'm thinking of offering), but instead of ONLY
>>> log it somehow feed / create a blacklist based on this?
>>>
>>> I'm not as familiar with blacklists as many of you, but the network /
>>> smtp / logging side of this is easy for me to implement.
>>>
>>> I'm thinking make this a very public (free) service to gather data for
>>> the blacklist, anyone could list the mx.
>>>
>> Whats wrong with :
>>
>> http://www.rfc-ignorant.org/tools/submit_form.php?table=bogusmx
>>
>>
>
> wrong direction. That lists domains that don't have their MX records
> set up properly, not ip addresses that attempt to send mail to sites
> that are not MX records.
>
and the difference is?
if you force our servers to retry each time we connect to your server,
then we will find other people to talk to (in short, we'll BL you)
unless you ask the IETF to modify SMTP by adding a "knocking" requirement.
Re: Bogus MX -> blacklist service viable?
Posted by "McDonald, Dan" <Da...@austinenergy.com>.
On Thu, 2008-02-21 at 21:58 +0100, Raymond Dijkxhoorn wrote:
> Hi!
>
> > provide this hosted (i.e. I'm thinking of offering), but instead of ONLY
> > log it somehow feed / create a blacklist based on this?
> >
> > I'm not as familiar with blacklists as many of you, but the network /
> > smtp / logging side of this is easy for me to implement.
> >
> > I'm thinking make this a very public (free) service to gather data for
> > the blacklist, anyone could list the mx.
>
> Whats wrong with :
>
> http://www.rfc-ignorant.org/tools/submit_form.php?table=bogusmx
>
wrong direction. That lists domains that don't have their MX records
set up properly, not ip addresses that attempt to send mail to sites
that are not MX records.
--
Daniel J McDonald, CCIE #2495, CISSP #78281, CNX
Austin Energy
http://www.austinenergy.com
Re: Bogus MX -> blacklist service viable?
Posted by Raymond Dijkxhoorn <ra...@prolocation.net>.
Hi!
> provide this hosted (i.e. I'm thinking of offering), but instead of ONLY
> log it somehow feed / create a blacklist based on this?
>
> I'm not as familiar with blacklists as many of you, but the network /
> smtp / logging side of this is easy for me to implement.
>
> I'm thinking make this a very public (free) service to gather data for
> the blacklist, anyone could list the mx.
Whats wrong with :
http://www.rfc-ignorant.org/tools/submit_form.php?table=bogusmx
Bye,
Raymond.
Re: Bogus MX -> blacklist service viable?
Posted by Raymond Dijkxhoorn <ra...@prolocation.net>.
Hi!
>> defermx.<domain>.com
>> bogusmx.<domain>.com
>>
>> provide this hosted (i.e. I'm thinking of offering), but instead of ONLY
>> log it somehow feed / create a blacklist based on this?
>>
>> I'm not as familiar with blacklists as many of you, but the network /
>> smtp / logging side of this is easy for me to implement.
>>
>> I'm thinking make this a very public (free) service to gather data for
>> the blacklist, anyone could list the mx.
>>
>> Thoughts?
> I'm confused. What are you trying to accomplish?
I thought i was lost, but even if Marc can follow you ;) eh eh ....
Bye,
Raymond.
Re: Bogus MX -> blacklist service viable?
Posted by Marc Perkel <ma...@perkel.com>.
Steve Radich wrote:
> What's everyone's opinion on something like:
>
> defermx.<domain>.com
> bogusmx.<domain>.com
>
> provide this hosted (i.e. I'm thinking of offering), but instead of ONLY
> log it somehow feed / create a blacklist based on this?
>
> I'm not as familiar with blacklists as many of you, but the network /
> smtp / logging side of this is easy for me to implement.
>
> I'm thinking make this a very public (free) service to gather data for
> the blacklist, anyone could list the mx.
>
> Thoughts?
>
> Steve Radich - http://www.aspdeveloper.net /
> http://www.virtualserverfaq.com
> BitShop, Inc. - Development, Training, Hosting, Troubleshooting -
> http://www.bitshop.com
>
>
I'm confused. What are you trying to accomplish?