[SpamCop-List] Re: forwarded spams to SC not acknowledged today - SC queue resumed with LACNIC problems

[Philippe Verdy (n.o-s.p.a.m+abuse)]

"Canopus" <BNRAGMAOKKXT at spammotel.com> a écrit dans le message de news: 
dnnbju$rv2$1 at news.spamcop.net...
> Philippe Verdy on 13/12/2005 wrote:
>
>>I've sent since this morning about 20 forwarding emails to my SC account 
>>report address, and none of them are acknowledged. I have checked that the 
>>emails I wassending to third party mail providers (to email accounts that 
>>I own) are working, somy ISP can't be the cause.
>>
>>Is SC incoming report queue halted?
>
> I thought Yahoo Mail was running slow so I changed my returns address from 
> SpamCop to my Googlemail account which I know is almost instantaneous. 
> Now I'm not even getting the confirmation mail from SpamCop to activate my 
> account on my new address so I'm doubly knackered (UK term 8¬))

Spamcop seems to have recovered most of its delays. It is however still very 
slow to reply.
In addition, most resolutions of IPs in the LACNIC area are producing 
timeouts (and the local cache in SpamCop does not help, because LACNIC 
records have expired, and SpamCop's limitation on query rate means that it 
will take timeto recover).

This just creates devnull'ed listings in SCBL for spam sources identified by 
IP, but no report.

SpamCop needs some accesses to third-party DNS caches regarding LACNIC, and 
the IP-to-ASN resolution (and whois data) for the LACNIC address space needs 
to be solved. Shouldn't Spamcop sollicitate help from major US ISPs to get 
an access to those alternate caches, notably those with large connectivity 
such as AT&T and MCI/UUNet, when the local cache fails? If LACNIC is fialing 
in last ressort, shouldn't Spamcop try with alternate large RIRs (notably 
ARIN and RIPE NCC) ?

I do think that all RIRs should provide excellent and unbreakable 
connectivity from caches run but all the other RIRs, simply to help serve 
more efficiently their effective area. I don't think that SpamCop actually 
requires authoritative data from the original RIR only.

Recently I helped solving inconsistencies found in AfriNIC database (they 
came from preexisting entries that existed in ARIN before the ERX transfer 
to AfriNIC). I think that those secured links that allowed switching nearly 
instantly the authority from the origin RIR to the slave cache of ghe target 
RIR should still exist today to help managing the traffic in a scalable and 
geographically andtopologically efficient way (if SpamCop gives some trust 
to any RIR for resolving addresses or getting whoisdata, it should give 
similar trust to all of them for their regional caches; it's the natural way 
Internet works and scales: "authoritative" records are not needed 
constantlyunless the level of trust between anauthority and cache is 
different).