[anti-abuse-wg] National PSDN "UZPAK"

Florian,

As I had stated in my earlier message, I had forwarded my Spam report to the
following address [admin at uzpak.uz], but it came back with this error
message:

-------

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  ripeadmin at uzpak.uz
    SMTP error from remote mail server after RCPT TO:<ripeadmin at uzpak.uz>:
    host mail.uzpak.uz [84.54.64.37]: 553 sorry, this recipient is not in my
validrcptto list (#5.7.1)

-------

As you may know, many networks show and use invalid, or even fake contact
e-mail addresses in order to frustrate everyone, and the National PSDN
"UZPAK" is no exception.

On a daily basis, I report such abuse violations to Spamcop.net,
http://www.spamcop.net/, and in many instances, the IP address either does
not have an Abuse Reporting e-mail, or the e-mail addresses listed in the
Whois directory is bogus.

So, having a street address, a phone number, and even an invalid email
address, does not change anything; it creates frustration and despair.

One way to hold all networks accountable perhaps would be for the RIPE NCC
to send an e-mail [once a year] to addresses in their Whois listing, thereby
confirming and verifying their correctness and validity.

Thank you,


Reza Farzan 
rezaf at mindspring.com

===========

> -----Original Message-----
> From: anti-abuse-wg-bounces at ripe.net 
> [mailto:anti-abuse-wg-bounces at ripe.net] On Behalf Of Florian Weimer
> Sent: Wednesday, March 28, 2012 2:35 PM
> To: Suresh Ramasubramanian
> Cc: Laura Cobley; Michele Neylon :: Blacknight; 
> <rezaf at mindspring.com>; <anti-abuse-wg at ripe.net>
> Subject: Re: [anti-abuse-wg] National PSDN "UZPAK"
> 
> * Suresh Ramasubramanian:
> 
> > There is clearly a fiduciary duty as the custodians of a scarce, 
> > depleting, common good.
> >
> > So, why would an analogy about due diligence not score points?
> 
> Because we do not value accountability in our financial institutions.
> 
> Back to the original topic.  I agree that we face various 
> issues with service provider accountability, but one of the 
> major problems with this and similar discussions is that 
> those who demand some form of action make claims which are 
> quite obviously not factually correct.
> 
> The allocated resource covering 213.230.122.0 is the inetnum 
> object 213.230.64.0 - 213.230.127.255, allocated to this LIR:
> 
> organisation:    ORG-UNCN1-RIPE
> org-name:        Uzpak Net (Country Net of Independence 
> Republic of Uzbekistan)
> org-type:        LIR
> address:         National Data Network Company
>                  8th floor, 8, Druzhba Narodov str.,
>                  700043, Tashkent,
>                  Uzbekistan
> phone:           +998 71 114 6314
> phone:           +998 71 144 4804
> fax-no:          +998 71 114 6322
> e-mail:          admin at uzpak.uz
> admin-c:         BM2509-RIPE
> admin-c:         MBA-RIPE
> mnt-ref:         AS8193-MNT
> mnt-ref:         RIPE-NCC-HM-MNT
> mnt-by:          RIPE-NCC-HM-MNT
> changed:         [...] 20120308
> source:          RIPE
> 
> There you have a street address, a phone number, and even an 
> email address.  Does this change anything about 
> accountability?  Not sure.
> 
> For PA resources, such information is relatively easy to find.
> However, RIPE NCC is not able to provide this as a service, 
> and restricts access to the database in a way that makes it 
> impossible to offer such a service to the general public.  
> But these obstacles are created by RIPE NCC and the RIPE 
> community, and not the resource holders.
> 
> Again, let me stress that this case is far from unique.  We 
> often see claims that some network is "bad".  I'm slightly 
> out of touch with regards to current network-wide events, but 
> I still feel that I should be able to recognize proof of 
> badness as such.  But what happens far too often is that 
> folks who I know are knowledgeable about these things cannot 
> express their rationale in terms I can understand or accept 
> as proof.  This is a problem.
>