Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Elvis Daniel Velea]

ot;,
"all.s5h.net",
"public.sarbl.org",
"rhsbl.scientificspam.net",
"bl.scientificspam.net",
"reputation-domain.rbl.scrolloutf1.com",
"reputation-ip.rbl.scrolloutf1.com",
"reputation-ns.rbl.scrolloutf1.com",
"tor.dnsbl.sectoor.de",
"exitnodes.tor.dnsbl.sectoor.de",
"rf.senderbase.org",
"query.senderbase.org",
"sa.senderbase.org",
"bl.score.senderscore.com",
"score.senderscore.com",
"singular.ttk.pte.hu",
"dnsbl.sorbs.net",
"problems.dnsbl.sorbs.net",
"proxies.dnsbl.sorbs.net",
"relays.dnsbl.sorbs.net",
"safe.dnsbl.sorbs.net",
"nomail.rhsbl.sorbs.net",
"badconf.rhsbl.sorbs.net",
"dul.dnsbl.sorbs.net",
"zombie.dnsbl.sorbs.net",
"block.dnsbl.sorbs.net",
"escalations.dnsbl.sorbs.net",
"http.dnsbl.sorbs.net",
"misc.dnsbl.sorbs.net",
"smtp.dnsbl.sorbs.net",
"socks.dnsbl.sorbs.net",
"rhsbl.sorbs.net",
"spam.dnsbl.sorbs.net",
"recent.spam.dnsbl.sorbs.net",
"new.spam.dnsbl.sorbs.net",
"old.spam.dnsbl.sorbs.net",
"web.dnsbl.sorbs.net",
"korea.services.net",
"geobl.spameatingmonkey.net",
"backscatter.spameatingmonkey.net",
"badnets.spameatingmonkey.net",
"bl.spameatingmonkey.net",
"fresh.spameatingmonkey.net",
"fresh10.spameatingmonkey.net",
"fresh15.spameatingmonkey.net",
"bl.ipv6.spameatingmonkey.net",
"netbl.spameatingmonkey.net",
"uribl.spameatingmonkey.net",
"urired.spameatingmonkey.net",
"netblockbl.spamgrouper.to",
"bl.spamcannibal.org",
"bl.spamcop.net",
"_vouch.dwl.spamhaus.org",
"pbl.spamhaus.org",
"sbl.spamhaus.org",
"sbl-xbl.spamhaus.org",
"swl.spamhaus.org",
"xbl.spamhaus.org",
"feb.spamlab.com",
"rbl.spamlab.com",
"all.spamrats.com",
"dyna.spamrats.com",
"noptr.spamrats.com",
"spam.spamrats.com",
"spamsources.fabel.dk",
"bl.spamstinks.com",
"dul.pacifier.net",
"bl.suomispam.net",
"dbl.suomispam.net",
"gl.suomispam.net",
"multi.surbl.org",
"srn.surgate.net",
"dnsrbl.swinog.ch",
"uribl.swinog.ch",
"rbl.tdk.net",
"st.technovision.dk",
"dob.sibl.support-intelligence.net",
"dbl.tiopan.com",
"bl.tiopan.com",
"dnsbl.tornevall.org",
"r.mail-abuse.com",
"q.mail-abuse.com",
"rbl2.triumf.ca",
"wbl.triumf.ca",
"truncate.gbudb.net",
"dunk.dnsbl.tuxad.de",
"hartkore.dnsbl.tuxad.de",
"dnsbl-0.uceprotect.net",
"dnsbl-1.uceprotect.net",
"dnsbl-2.uceprotect.net",
"dnsbl-3.uceprotect.net",
"ubl.unsubscore.com",
"virbl.dnsbl.bit.nl",
"all.rbl.webiron.net",
"babl.rbl.webiron.net",
"cabl.rbl.webiron.net",
"crawler.rbl.webiron.net",
"stabl.rbl.webiron.net",
"ips.whitelisted.org",
"blacklist.woody.ch",
"ipv6.blacklist.woody.ch",
"uri.blacklist.woody.ch",
"db.wpbl.info",
"bl.blocklist.de",
"dnsbl.zapbl.net",
"rhsbl.zapbl.net",

Out of all these, in the past couple of years we have stopped using some 
(see the following list, and more) as we were getting bogus data/responses:


bl.emailbasura.org
rbl.megarbl.net
bl.spamcannibal.org
hartkore.dnsbl.tuxad.de
dunk.dnsbl.tuxad.de
v6.fullbogons.cymru.com
query.senderbase.org
sa.senderbase.org

Hope this can help.

Kind regards,
Elvis Velea
V4Escrow CEO
www.v4escrow.com

On 3/12/21 12:51 AM, Christian Teuschel wrote:

Dear colleagues,

I can see a few suggestions for additional blocklists to include. It
would be helpful if we could get any other

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Elvis Daniel Velea]

Hi Christian,

while it may be useful to have their data source, it only shows the RIPE 
NCC favors one or two operators and I think that is damaging to the 
whole idea of being impartial.


You either include a good list of blacklist operators and their data or 
none. Including only a couple will lead to the impression that only 
those are important enough to be considered by the RIPE NCC.


my 2 cents,
Elvis

On 3/3/21 8:27 AM, Christian Teuschel wrote:

Dear colleagues,

RIPEstat is a neutral source of information and we aim to provide users
with access to as many data sources as possible to provide insights.

UCEProtect was added as a data source prior to 2010 and is still used by
several network operators to filter traffic into their networks.
Including it as a data source in RIPEstat allows users to see whether
resources are included in their lists.

RIPE NCC does not pay for, support or endorse their practices, although
we understand that continuing to include UCEProtect as a data source
could be misunderstood as such. We also do not use their lists to filter
traffic on our services.

Our goal remains to provide the best visibility and tools for network
operators to diagnose their networks. We have also heard your feedback
regarding including more RBLs. It is something that we have considered
in the past, and we are open to revisiting this.

RIPEstat is driven by the community. We would like to hear from you
about whether including UCEProtect as a data source is useful.

Regards,
Christian

On 02/03/2021 00:08, Kristijonas Lukas Bukauskas via anti-abuse-wg wrote:

Hello,

I noticed that RIPE NCC uses uceprotect-level1, uceprotect-level2 and
uceprotect-level3 in RIPEStat Anti Abuse Blacklist Entries widget.

There have been controversial positions about this blacklist recently:

1)
https://success.trendmicro.com/solution/000236583-Emails-being-rejected-by-RBL-UCEPROTECL-in-Hosted-Email-Security-and-Email-Security

2) https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html

  


UCEPROTECT blacklists the whole range of IP addresses, including the
full IP range of some autonomous systems:
  
UCEPROTECT states, '/Who is responsible for this listing? YOU ARE NOT!

Your IP was NOT directly involved in abuse but has a bad neighborhood.
Other customers within this range did not care about their security and
got hacked, started spamming, or were even attacking others, while your
provider has possibly not even noticed that there is a serious problem.
We are sorry for you, but you have chosen a provider not acting fast
enough on abusers'/) [http://www.uceprotect.net/en/rblcheck.php
].
  
It asks for a fee if some individual IP address wants to be whitelisted

(http://www.whitelisted.org/ ),
  
It abuses people who decide to challenge their blacklist by publishing

conversations in their so-called /Cart00ney/
(http://www.uceprotect.net/en/index.php?m=8&s=0
;
http://www.uceprotect.org/cart00neys/index.html
).
  
And the other type of threatening: http://www.uceprotect.org/


  
Does RIPE NCC have any position on this specific blacklist?


Thank you!

Re: [anti-abuse-wg] @EXT: RE: working in new version of 2019-04 (Validation of "abuse-mailbox")

[Elvis Daniel Velea]

Hi,

On 1/16/20 09:14, Volker Greimann wrote:
Clearly you have never looked at what normal end users put in the Org 
fields. In our experience, they put anything in there, not just org 
names. There simply is no good way to identify which org field shows 
personal information which must be protected and which does not. 
You could make a bit of an effort and override that field with the data 
from the registration documents used to register the domain (if the data 
inserted by the end user is not right).
As I said, we'd be happy to publish non-personal information, if we 
can be sure it is that. 


Ask RIPE NCC how they are doing it... as far as I know, all (*) 
organisation org-name: attributes are maintained by the RIPE NCC


*all those that have any kind or resource assigned or allocated by the 
RIPE NCC


/elvis

Re: [anti-abuse-wg] [routing-wg] An arrest in Russia

[Elvis Daniel Velea]

Hi Nikolas,

where in the policies are annulments possible?

Elvis

On Thu, Jan 2, 2020 at 06:30 Nikolas Pediaditis  wrote:

> Dear Sergey,
>
> In this case, the transfer was ‘reverted’, meaning that the registration
> details prior to the transfer were restored. We see this action as an
> annulment of the original transfer and not a second transfer requiring
> implementation of the 24-month rule.
>
> With regards to implementing policies and procedures, we apply them as
> equally and neutrally as possible, but we also consider it reasonable and
> sensible to take extraordinary circumstances into account. On this
> occasion, RIPE NCC Management reviewed a case in which new information had
> come to light and it decided to act as it saw necessary and appropriate.
>
>
> Kind regards,
>
> Nikolas Pediaditis
> Registration Services and Policy Development Manager
> RIPE NCC
>
>
> > On 31 Dec 2019, at 21:13, Sergey Myasoedov via anti-abuse-wg <
> anti-abuse-wg@ripe.net> wrote:
> >
> > Hi Marco,
> >
> >> Later, we received new information from both organisations about this
> transfer. It was then followed by an official request in which both parties
> asked us to revert the changes made to our registry and return the IP
> addresses back to their previous holders. After an internal review, we
> reverted the registration of the addresses.
> >
> > Can you give some more details on the fact that policy requirements for
> holding the resources for 24 months after the transfer was suspended?
> >
> >> While we cannot disclose more details publicly, we would like to
> emphasise that we took this action within our mandate to maintain an
> up-to-date and correct Internet number resource registry, and as a neutral
> and impartial organisation.
> >
> > The last sentence proves that there are rules and there are rules. How
> the NCC can be a neutral organisation while policy isn't applied to all
> members in an equal manner?
> >
> > Thank you and have a happy holidays.
> >
> >
> > --
> > Kind regards,
> > Sergey Myasoedov
> >
> >> On 31 Dec 2019, at 09:28, Marco Schmidt  wrote:
> >>
> >> Dear colleagues,
> >>
> >> We would like to provide some clarification on this case.
> >>
> >> Earlier this year, we transferred a large number of IP addresses from
> the autonomous nonprofit organisation "Russian Scientific-Research
> Institute for Public Networks” in the Russian Federation to the Reliable
> Communications s.r.o in the Czech Republic.
> >> This change was processed by the RIPE NCC in full compliance with RIPE
> Policies and the RIPE NCC’s published procedures.
> >>
> >> Later, we received new information from both organisations about this
> transfer. It was then followed by an official request in which both parties
> asked us to revert the changes made to our registry and return the IP
> addresses back to their previous holders. After an internal review, we
> reverted the registration of the addresses.
> >>
> >> While we cannot disclose more details publicly, we would like to
> emphasise that we took this action within our mandate to maintain an
> up-to-date and correct Internet number resource registry, and as a neutral
> and impartial organisation.
> >>
> >> Kind regards and Happy New Year,
> >>
> >> Marco Schmidt
> >> Registration Services and Policy Development Assistant Manager
> >> RIPE NCC
> >>
> >>
> >> On 29/12/2019 06:45, Randy Bush wrote:
>  It would be nice if RIPE NCC could provide as part of its annual
>  report a list of incidents of this nature so we have an idea of how
>  wide-spread this is - or not.
> >>> as i try not to indulge in schadenfreude, i don't have much use for
> this
> >>> information.
> >>>
> >>> we spent some time in this space in rotterdam.  the presos were well
> >>> done, but not my cup of coffee.  i am sure there were others who found
> >>> it fascinating.  i guess that's what makes the world go 'round.
> >>>
> >>> randy
> >>>
> >>
> >>
> >
> >
>
>
> --
This message was sent from a mobile device. Some typos may be possible.

Re: [anti-abuse-wg] Speaking of routing funny business... what's up with AS65021?

[Elvis Daniel Velea]

Hi,

On 4/5/19 20:53, Ronald F. Guilmette wrote:

Are new AS numbers really all that expensive
in the RIPE region, so that some businesses might be motivated to save some
money by just grabbing onto one of the reserved ones?


the ASNs in the RIPE Region are *free* for both the LIR and the end-user.

cheers,

elvis

Re: [anti-abuse-wg] Solving the issue of rogue ROUTE objects in the RIPE Database

[Elvis Daniel Velea]

Hi,

I like the idea. I would have preffered a cross registry/RIR solution but
as you said, it has been many months (I actually raised the issue 2 RIPE
meetings ago - in London) but nothing visible has been done to fix this
problem.

+1 from me.

cheers,
elvis

Excuse the briefness of this mail, it was sent from a mobile device.

On Nov 5, 2015, at 11:47, "ripede...@yahoo.co.uk" 
wrote:

HI all

I am going to have one last go at solving this problem. I challenge
anyone/everyone to tell me why this is such a stupid idea, technically
impossible to do, won't solve any of the issues partially or fully. Then I
can shut up about it and go away. If you can't condemn the idea then
support it. Lets fix this issue once and for all, stop this endless
discussion about rogue ROUTE objects and get on with life.

So here is my 4 step proposal that I believe could be implemented within a
month. If we implemented this you can be sure that all ROUTE objects in the
RIPE Database were created with the knowledge and approval of the related
resource holders. I believe that is the desired goal.

STEP 1

Any ROUTE object submitted for creation in the RIPE Database involving an
out of region resource (address space and/or ASN) where that out of region
resource does not exist in the authoritative RIR database (has not been
allocated or assigned), reject the creation.

The RIPE NCC mirrors the operational data from all the other 4 RIRs. These
mirrors are updated daily as well as the RIRs daily stats. It is easy to
determine if a resource is registered in the authoritative database.

STEP 2

For those ROUTE objects from STEP 1 where the out of region resource does
exist, hold the object creation as pending. The mechanism for doing this
already exists in the RIPE Database software as it is used for multiple
authentications.

Lookup the out of region resource(s) in the authoritative database(s) and
find the contacts for that resource. Send a notification to those contacts
informing them of the pending ROUTE object creation in the RIPE Database.
The notification mechanism already exists in the RIPE Database software. If
they don't approve, do nothing and the creation request will time out after
a week and the object will not be created. If they do approve, respond in
some way (many technical options for doing this that the RIPE NCC can
choose from). If appropriate approval(s) are received within a week, create
the ROUTE object.

STEP 3

On a daily basis, for each ROUTE object in the RIPE Database that relates
to an out of region resource, check for the continued existence of that
resource in the appropriate RIR database. If it no longer exists, delete
the ROUTE object from the RIPE Database.

STEP 4

This is a one off cleanup of existing ROUTE objects. For all ROUTE objects
currently in the RIPE Database that relate to an out of region, existing
resource, send the appropriate notifications. For any that no response is
received within a week, delete the ROUTE object from the RIPE Database.

cheers
denis

Re: [anti-abuse-wg] SPAM from other LIRs to db-contacts regarding resource sale

[Elvis Daniel Velea]

Hi,

On 26/04/15 23:36, Sebastian Wiesinger wrote:

[snip]

Hello,

I received the same SPAM today, from the same person.

I got it as well :)

Ironically this
person is currently arguing to stop a proposal over in the
address-policy WG that is trying to impede exactly this behaviour.

I actually made him an offer :)) A very low one, but still, an offer.


As that person is a LIR/RIPE NCC member I think that this could be a
breach of the RIPE NCC LIR terms and I would like the RIPE NCC to
investigate this.

For the RIPE NCC to even start anything, a proper report must be filled in:

https://www.ripe.net/report-form

I'd say you could report a violation of the RIPE DB Terms and 
Conditions. Although.. it is very difficult to prove it.


regards,
Elvis


Regards

Sebastian

- -- 
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)

'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
 -- Terry Pratchett, The Fifth Elephant
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQF6BAEBCgBkBQJVPdjlMxSAABUAFXBrYS1hZGRyZXNzQGdudXBnLm9yZ3Nl
YmFzdGlhbkBrYXJvdHRlLm9yZykaaHR0cHM6Ly93d3cua2Fyb3R0ZS5vcmcvcGdw
LXBvbGljeS5zaHRtbAAKCRBYotlKk6C5zkcHCADT/aEvmwd8xChfu2QUkK8FDnIG
aKR51y89HPu08YgUgVEqE6xs+ew0jVOQb4/vXzjMiVr9lD38QiQ2XG+jlGzML8E3
SsNJ8dlntseqeRm85GVh5guo1ADmQaEUjHJ1oC+CpWJyNUBarUodcg3UxuzYkyIM
JNkYGFO5su6s8pJyhzkIcsOfGo5uZYgDpW4tHgrX2Re40wjFu9BP8eYQENhr1qpt
1ZsKJojmvdVNFC5NXZUQWuoWpb/lFmnBM9l+rScMabN2R70xS+JO6a//Qq34zS+w
dxr4Y3uPRmJpUVN7diV2lPfRjpKkW1MofgbJ8e1FLm4+Ap6w905BlOMJ4CCF
=X5bk
-END PGP SIGNATURE-

Re: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002

[Elvis Daniel Velea]

the policies are RIPE policies, NCC only has procedures.

if you would be interested in the RIPE policies (and not only noise on this
mailing list), you would have followed the discussions happening during the
RIPE Meeting today; there was a lenghty discussion at the routing wg about
this particular case and similar cases in general.

regards,
elvis

Excuse the briefness of this mail, it was sent from a mobile device.

On 07 Nov 2014, at 03:05, Suresh Ramasubramanian 
wrote:

This one is, yes.

No shortage of previous incidents though as you're probably aware.

Anyway the question before the house here is NCC policies, not which
country a specific incident took place in.
 On Nov 7, 2014 8:23 AM, "Elvis Daniel Velea"  wrote:

> Nex time, before sending an e-mail learn how to use whois.
>
> the AS is assigned and used in Bulgaria and the Sponsoring LIR is also
> from Bulgaria (Nettera Ltd)
>
> Btw, how are the laws against spam in India?  I see it's still in top 10
> countries sending spam...
>
> Excuse the briefness of this mail, it was sent from a mobile device.
>
> On 07 Nov 2014, at 01:23, Suresh Ramasubramanian 
> wrote:
>
> There are two or three things here.
>
> RIPE is under dutch law and the Netherlands does have a law against spam,
> and other cybercrime legislation as well that has historically been
> actively enforced.
>
> The LIR is under romanian law and that does appear to have some laws
> against spam on their books but none of it appears to have been tested in
> court.
>
> As a LE organization, Europol, like Interpol, deals with coordination and
> clearinghouse work between national LE and neither is an international
> police force.
>
> This simply means that LE or the appropriate regulator in either country
> where the different parts of this contract exist (the Netherlands - opta or
> dutch high tech crime police, and whoever are their peers in Romania)
> should be able to act on this information.
>
> U.S. LE as well given that the actual perpetrators are there.
>
> Whether dutch, romanian or US law are able to take cognizance of publicly
> available information to open an investigation, or they need a local victim
> of IP hijacking (or an international victim through the normal LE channels)
> remains to be seen.
>
> In either case we do need to see how much RIPE NCC can do to exercise its
> fiduciary duty over v4 space.
>
> A bank manager who loaned money on the same slapdash implementation of
> criteria that NCC allocates IP space on (due diligence being interpreted as
> 'internet policing' might explain that) would be fired and/or prosecuted in
> very short order indeed.
> On Fri, 7 Nov 2014 at 02:21 Reza Mahmoudi  wrote:
>
>> I was wondering if this kind of hijacking falls into the category of
>> Cybercrime and authorities like Europol (https://www.europol.europa.eu/
>> ) can help?
>>
>> Reza Mahmoudi
>> 
>> From: anti-abuse-wg-boun...@ripe.net [anti-abuse-wg-boun...@ripe.net] on
>> behalf of Ronald F. Guilmette [r...@tristatelogic.com]
>> Sent: Friday, November 07, 2014 12:02 AM
>> To: anti-abuse-wg@ripe.net
>> Subject: Re: [anti-abuse-wg] Hijack Factory: AS201640 / AS22
>>
>> In message <20141106150814.gx31...@space.net>,
>> Gert Doering  wrote:
>>
>> >In this particular case, I wonder why nobody is yelling at the upstream
>> >who is happily forward packets for that AS...  due dilligence at
>> >accepting customer prefixes would have easily caught the announcements.
>>
>> I personally would be ``yelling at the upstream'' right now, but someone
>> made a comment on the NANOG mailing list which sort-of hinted that this
>> would be entirely futile in the case of AS22.  I don't know, but I
>> suspect that he already knows something that I don't know, so I'm not
>> wasting my time on sending comlaints to an entity that, it seems, may
>> perhaps not give a damn.
>>
>> >(Yes, I understand that I'm now officially part of the problem, as
>> >I'm obviously not willing to do everything technically possible to
>> >stop particular sorts of badness)
>>
>> To the extent that you might be able to avoid forwarding route
>> announcements which originate from AS201640, allow me to express
>> my personal opinion that doing so would be admirable.
>>
>>
>> Regards,
>> rfg
>>
>>
>> --
>> This email was Virus checked by Juniper Security Gateway.
>>
>

Re: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002

[Elvis Daniel Velea]

Nex time, before sending an e-mail learn how to use whois.

the AS is assigned and used in Bulgaria and the Sponsoring LIR is also from
Bulgaria (Nettera Ltd)

Btw, how are the laws against spam in India?  I see it's still in top 10
countries sending spam...

Excuse the briefness of this mail, it was sent from a mobile device.

On 07 Nov 2014, at 01:23, Suresh Ramasubramanian 
wrote:

There are two or three things here.

RIPE is under dutch law and the Netherlands does have a law against spam,
and other cybercrime legislation as well that has historically been
actively enforced.

The LIR is under romanian law and that does appear to have some laws
against spam on their books but none of it appears to have been tested in
court.

As a LE organization, Europol, like Interpol, deals with coordination and
clearinghouse work between national LE and neither is an international
police force.

This simply means that LE or the appropriate regulator in either country
where the different parts of this contract exist (the Netherlands - opta or
dutch high tech crime police, and whoever are their peers in Romania)
should be able to act on this information.

U.S. LE as well given that the actual perpetrators are there.

Whether dutch, romanian or US law are able to take cognizance of publicly
available information to open an investigation, or they need a local victim
of IP hijacking (or an international victim through the normal LE channels)
remains to be seen.

In either case we do need to see how much RIPE NCC can do to exercise its
fiduciary duty over v4 space.

A bank manager who loaned money on the same slapdash implementation of
criteria that NCC allocates IP space on (due diligence being interpreted as
'internet policing' might explain that) would be fired and/or prosecuted in
very short order indeed.
On Fri, 7 Nov 2014 at 02:21 Reza Mahmoudi  wrote:

> I was wondering if this kind of hijacking falls into the category of
> Cybercrime and authorities like Europol (https://www.europol.europa.eu/ )
> can help?
>
> Reza Mahmoudi
> 
> From: anti-abuse-wg-boun...@ripe.net [anti-abuse-wg-boun...@ripe.net] on
> behalf of Ronald F. Guilmette [r...@tristatelogic.com]
> Sent: Friday, November 07, 2014 12:02 AM
> To: anti-abuse-wg@ripe.net
> Subject: Re: [anti-abuse-wg] Hijack Factory: AS201640 / AS22
>
> In message <20141106150814.gx31...@space.net>,
> Gert Doering  wrote:
>
> >In this particular case, I wonder why nobody is yelling at the upstream
> >who is happily forward packets for that AS...  due dilligence at
> >accepting customer prefixes would have easily caught the announcements.
>
> I personally would be ``yelling at the upstream'' right now, but someone
> made a comment on the NANOG mailing list which sort-of hinted that this
> would be entirely futile in the case of AS22.  I don't know, but I
> suspect that he already knows something that I don't know, so I'm not
> wasting my time on sending comlaints to an entity that, it seems, may
> perhaps not give a damn.
>
> >(Yes, I understand that I'm now officially part of the problem, as
> >I'm obviously not willing to do everything technically possible to
> >stop particular sorts of badness)
>
> To the extent that you might be able to avoid forwarding route
> announcements which originate from AS201640, allow me to express
> my personal opinion that doing so would be admirable.
>
>
> Regards,
> rfg
>
>
> --
> This email was Virus checked by Juniper Security Gateway.
>