Frank ,
Hi,
How do you propose to do this Ip to mail Address translation ?
Im sure, that RIPE NCC knows what IP address belongs to wich allocation (like they know when answering whois queries) and that they then know wich member owns this allocation. That should be not more than two database lookups for RIPE NCC. And a third one to find his abuse address the LIR entered into the system ... Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank@powerweb.de
BR Balaji
On Thu, Apr 8, 2010 at 11:27 PM, Frank Gadegast <phade@www.powerweb.de>wrote:
Not getting it.
I apologise. Allow me to rephrase:
Any organisation to which net space is allocated or assigned may own
zero, one or several Internet domains. It may be difficult to know exactly what to type on the domain side of an abuse@ address. Your proposal avoids this issue. This is an advantage of your proposal as compared with RFC 2142.
No, because the system generates email addresses only related to the IP address that causes the abuse.
The monitoring system at RIPE NCC than "translates" this IP like email addresses to either the abuse address, that the member was putting into RIPEs system or the main member address, the member has to setup, when becoming a member.
RIPE NCC knows best how to "translate" the IP like abuse email address to the members address, because RIPE NCC has best knowlegde about the allocation all member ownes.
BTW: thats the main advantage of my draft ... nobody has to know the actual abuse address for a IP range or has to look it up via whois. Anybody that gets attacked knows the right address just by sending his report to
1.2.3.4@abuse.ripe.net
when the IP 1.2.3.4 caused the abuse.
Kind regards, Frank
-- Thor Kottelin http://www.anta.net/
--0016e648cf9ac832e20483be8f1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Frank , <br><br>How do you propose to do this Ip to mail Address translatio= n ? <br><br>BR <br>Balaji <br><br><div class=3D"gmail_quote">On Thu, Apr 8,= 2010 at 11:27 PM, Frank Gadegast <span dir=3D"ltr"><<a href=3D"mailto:p= hade@www.powerweb.de">phade@www.powerweb.de</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">><br> > ><br> > > Not getting it.<br> ><br> > I apologise. Allow me to rephrase:<br> ><br> > Any organisation to which net space is allocated or assigned may own z= ero, one or several Internet domains. It may be difficult to know exactly w= hat to type on the domain side of an abuse@ address. Your proposal avoids t= his issue. This is an advantage of your proposal as compared with RFC 2142.= <br>
<br> No, because the system generates email addresses only related to the IP add= ress<br> that causes the abuse.<br> <br> The monitoring system at RIPE NCC than "translates" this IP like = email addresses<br> to either the abuse address, that the member was putting into RIPEs system<= br> or the main member address, the member has to setup, when becoming a<br> member.<br> <br> RIPE NCC knows best how to "translate" the IP like abuse email ad= dress<br> to the members address, because RIPE NCC has best knowlegde about<br> the allocation all member ownes.<br> <br> BTW: thats the main advantage of my draft ... nobody has to know<br> the actual abuse address for a IP range or has to look it up<br> via whois. Anybody that gets attacked knows the right address<br> just by sending his report to<br> <br> <a href=3D"mailto:1.2.3.4@abuse.ripe.net">1.2.3.4@abuse.ripe.net</a><br> <br> when the IP 1.2.3.4 caused the abuse.<br> <br> <br> Kind regards, Frank<br> <br> ><br> > --<br> > Thor Kottelin<br> > <a href=3D"http://www.anta.net/" target=3D"_blank">http://www.anta.net= /</a><br> ><br> ><br> ><br> <br> </blockquote></div><br>
--0016e648cf9ac832e20483be8f1c--