My point is that if ARIN has a listing service and ARIN "certifies" that a block can be listed either we have to have a big disclaimer that the block may be blacklisted and it's their problem or maybe we want to mention that it is black listed.  If we do nothing and don't at least tell them that we're not certifying that the block is not blacklisted then they could come back and sue us.  This is like we currently tell them that we don't guarantee routability.

On Jan 16, 2008 11:33 AM, heather skanks <heather.skanks@gmail.com> wrote:

In most cases, a note from the new holder of the address space, to the Blacklist - pointing out that the SWIP record has been updated and requesting the entry to be removed is sufficient.  Where it isn't sufficient, the holder of the space should contact the organization that they are trying to send mail to and ask to be whitelisted.

This is not an RIR problem.  The RIR's make no guarantee that the address space will be globally routable.  They can't force ISP's to accept routes, and they can't force ISP's or their customers to accept traffic from those addresses.

It's not an ISP problem, because it is not a problem of the route being rejected by ISP's.  It's a problem of people substituting their own judgment about who to accept mail from, for someone else's opinion.

From the POV of providers, it is our job to deliver the packets from point a to point b.  When we give you IP space (or you provide your own) we allow you to source traffic from those IP's, and we deliver packets back to you destined for those IP's.  If the folks you want to reach, have decided to implement a 3rd parties blacklist (or even make their own) and deny traffic, that's their own business.  It's not up to the RIR's or ISP's to tell other organizations what routes or traffic to accept.

--Heather



On Jan 16, 2008 12:57 PM, David Conrad <david.conrad@icann.org> wrote:
An "interesting" (in sort of the way the Ebola virus is "interesting")
problem that is going to become much more common as we start reallocating
previously allocated or otherwise flagged blocks.  Leo Vegoda has done a
couple of presentations on this.

Just imagine the fun folks who are going to get prefixes out of 1.0.0.0/8
are going to have.

Options I can think of:

1) Get everybody to transition to IPv6 (um, yeah).
2) Get all the folks who are running RBLs/DUNs to update their lists when
address status changes (slightly more realistic than (1)).
3) Get everybody to use reputation services like
http://www.karmasphere.com/, et al. (no, I'm not affiliated with them)
4) Get RPKI deployed to reduce the need for black list services (um, yeah.)
5) Get the folks who win the draw on prefixes to go around to every black
list service themselves (as they discover them) and convince the operator of
that list (somehow) to remove them (the default).

No good answers I'm aware of...

Regards,
-drc

On 1/16/08 9:28 AM, "Max Tulyev" <president@ukraine.su> wrote:

> Hello All,
>
> I just got an assignment for my client (large PI block). But this block
> is listed in all DNS RBLs and DUN lists, as it was in use till Oct'07 as
> dynamic DHCP pool of other big ISP.
>
> So my client says they can't use this network, because mail service is
> blocked.
>
> RIPE rejected my request to change this network to another one: "As we
> do understand how unfortunate this is for **********, there is nothing
> we can do about prefixes that appear on so called black lists."
>
> How can I solve this?