New function added to UCEPROTECT-Website
Claus v. Wolfhausen
We have installed the option to see time and date of the last impact for
Level 1 listings as suggested by many of you in our Lookup-Tool at:
http://www.uceprotect.net/en/rblcheck.php
Time and date of last impacts can also be seen for all listed IP's when doing
lookups for ASN's.
To get that information just do an request for your ASN as usual, and scroll
down the page completley.
You will find a link which is called:
"Details about IP's involved and dates of impacts can be found here."
If clicked it will open a new browser window with all IP's seen + time/date
of last impact and additional expected expirationtime.
Providers now have no longer the excusion that they couldn't find out which
of their dynamic customers had a spammy IP because they didn't have the time
and date of the last impact.
--
Claus von Wolfhausen
UCEPROTECT-Projektleitung
http://www.uceprotect.net
--
Comments posted to news.admin.net-abuse.blocklisting
are solely the responsibility of their author. Please
read the news.admin.net-abuse.blocklisting FAQ at
http://www.blocklisting.com/faq.html before posting.
axlq
Claus v. Wolfhausen <c.v.wol...@spamkiller.uceprotect.net> wrote:
>We have installed the option to see time and date of the last impact for
>Level 1 listings as suggested by many of you in our Lookup-Tool at:
>http://www.uceprotect.net/en/rblcheck.php
>Providers now have no longer the excusion that they couldn't find out which
>of their dynamic customers had a spammy IP because they didn't have the time
>and date of the last impact.
But wouldn't that also potentially reveal the spamtrap addresses
that triggered the impact?
Once a spamtrap is known to spammers, it's useless. And not all
ISPs are honest. Even the honest ones may inform their spamming
customer that they were blocked because they sent email to your
spamtrap, and name the spamtrap.
-A
D. Stussy
news:gagtti$48p$2...@blue.rahul.net...
> In article <gacgcl$5oh$1...@ulm.shuttle.de>,
> Claus v. Wolfhausen <c.v.wol...@spamkiller.uceprotect.net> wrote:
> >We have installed the option to see time and date of the last impact for
> >Level 1 listings as suggested by many of you in our Lookup-Tool at:
> >http://www.uceprotect.net/en/rblcheck.php
> >...
> >Providers now have no longer the excusion that they couldn't find out
which
> >of their dynamic customers had a spammy IP because they didn't have the
time
> >and date of the last impact.
>
> But wouldn't that also potentially reveal the spamtrap addresses
> that triggered the impact?
>
> Once a spamtrap is known to spammers, it's useless. And not all
> ISPs are honest. Even the honest ones may inform their spamming
> customer that they were blocked because they sent email to your
> spamtrap, and name the spamtrap.
Perhaps this should be rounded to the nearest 5 minutes? That should still
be sufficient for dynamic allocations to be linked to a user, yet unspecific
enough so as not to reveal the actual trap address (unless it was the only
one sent to in that 5 minute window - an unlikely event for a true spammer).
Claus v. Wolfhausen
>
>In article <gacgcl$5oh$1...@ulm.shuttle.de>,
>Claus v. Wolfhausen <c.v.wol...@spamkiller.uceprotect.net> wrote:
>>We have installed the option to see time and date of the last impact for
>>Level 1 listings as suggested by many of you in our Lookup-Tool at:
>>http://www.uceprotect.net/en/rblcheck.php
>>...
>>Providers now have no longer the excusion that they couldn't find out which
>>of their dynamic customers had a spammy IP because they didn't have the time
>>and date of the last impact.
>
>But wouldn't that also potentially reveal the spamtrap addresses
>that triggered the impact?
>Once a spamtrap is known to spammers, it's useless. And not all
>ISPs are honest. Even the honest ones may inform their spamming
>customer that they were blocked because they sent email to your
>spamtrap, and name the spamtrap.
One should think so, and that was the reason we didn't publish that
informations in the past.
While most spammers really don't care about spamtraps and continue to send
emails to such easy identifiable traps as list-...@uceprotect.net, there
are also some spammers that seem to have a list of IP-Ranges never to contact.
Our ISP (DFN AS680) told us that also other customers in the same subnet got
significant less spams since it is know that we might have more than just one
IP in that range.
While our actual release and earlier ones made it very easy to find out what
are spamtraps by searching the smtp-dialog for words as "spamtrap" it will no
longer be possible in the next official release will come up within the next
14 days.
So for spammers in fact it will be harder to detect our traps in the future.
1. Our Website doesnt show the exact date it is just as exact as a minute.
If you have ever run a busy server you will find it is hard to say which of
the connections within 60 seconds was the guilty one.
But it is exact enough to give the ISP clue about which of their
customers using their dynamic IP's have a spamtrojan installed.
2. Most traps get multiple hits and we only display the newest one earliest.
3. Different to most other blocklists UCEPROTECT-Network is *VERY* fast.
Sometimes it takes less than 5 minutes between an impact and the record showing
up in the DNSBL and at our website.
The Date and Time of last impact is only visible for IP's that were last seen
spamming more than 1 hour ago.
Systems currently involved in a spamrun show up as "pink meat" and optional
expressdelisting is not possible then.
--
Claus von Wolfhausen
UCEPROTECT-Projektleitung
http://www.uceprotect.net
--
Christoph Weber-Fahr
Claus v. Wolfhausen wrote:
> We have installed the option to see time and date of the last impact for
> Level 1 listings as suggested by many of you in our Lookup-Tool at:
> http://www.uceprotect.net/en/rblcheck.php
>
> Time and date of last impacts can also be seen for all listed IP's when doing
> lookups for ASN's.
That sounds interesting.
What's the usage policy?` Could we poll it at reasonable intervals
(like, say, 5 minutes) ?
> If clicked it will open a new browser window with all IP's seen + time/date
> of last impact and additional expected expirationtime.
I'll have a look into the format. Parsability by scripts might
be helpful.
> Providers now have no longer the excusion that they couldn't find out which
> of their dynamic customers had a spammy IP because they didn't have the time
> and date of the last impact.
Well, that depends. But overall, it's a nice improvement.
ObNitPick: the thing is called "excuse" :-)
Regards
Christoph Weber-Fahr
Christoph Weber-Fahr
Claus v. Wolfhausen wrote:
> The Date and Time of last impact is only visible for IP's that were last seen
> spamming more than 1 hour ago.
Hmm. *sigh*
> Systems currently involved in a spamrun show up as "pink meat" and optional
> expressdelisting is not possible then.
So, basically they are listed as "less than 1 hour ago".
Hmmmm.
That limits the usefullness, but might still help.
Regards
Christoph Weber-Fahr
MrD
> Hello,
>
> Claus v. Wolfhausen wrote:
>> The Date and Time of last impact is only visible for IP's that were
>> last seen spamming more than 1 hour ago.
>
> Hmm. *sigh*
>
>> Systems currently involved in a spamrun show up as "pink meat" and
>> optional expressdelisting is not possible then.
>
> So, basically they are listed as "less than 1 hour ago".
>
> Hmmmm.
>
> That limits the usefullness, but might still help.
Suspend all outbound mail traffic (for example by suppressing your
outbound port 25) for one hour; then check. There should be no loss of
outbound mail, however spammy - it'll get queued up. Anyway, suspending
your outbound mail while a live spamrun is underway seems to me to be a
perfectly sensible thing to do - it's the least I'd expect, in fact.
So I can't see that "limits the usefulness" is a reasonable response.
--
Jack.
Manfred...@googlemail.com
>
> What's the usage policy?` Could we poll it at reasonable intervals
> (like, say, 5 minutes) ?
Currently we are working on an api for that.
The webpage isn't made for scripting.
We could provide a csv file for that.
Best
Manfred
Christoph Weber-Fahr
MrD wrote:
> Christoph Weber-Fahr wrote:
>> Hmmmm.
>>
>> That limits the usefullness, but might still help.
>
> Suspend all outbound mail traffic (for example by suppressing your
> outbound port 25) for one hour; then check.
[...]
> Anyway, suspending
> your outbound mail while a live spamrun is underway seems to me to be a
> perfectly sensible thing to do - it's the least I'd expect, in fact.
:-)
I guess that depends on the size of your network and your customer base.
> it's the least I'd expect, in fact.
Let me put it politely - that's not an option. Not even remotely.
> So I can't see that "limits the usefulness" is a reasonable response.
That's probably because you don't see applications for Claus' data
beyond your own realm of experience. My intent is not so much stopping
actual spam runs (I can't do that anyway) than identifying those
nvolved to prevent logtime repeat occurrences.
Regards
Christoph Weber-Fahr