This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
[db-wg] abuse-c
- Previous message (by thread): [db-wg] abuse-c
- Next message (by thread): [db-wg] abuse-c
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Christian Rasmussen
chr at jay.net
Tue Jan 13 16:14:13 CET 2004
Hi Marco, Okay, I think I now understand better what you mean. There are different levels of check of entered abuse address: 1. Nothing 2. Syntax check 3. Address validity check (as previously described) 4. Response time check I very much disagree with you that level 3 should be worthless, I think its about as good as it can realistic be. How do you propose level 4 should be accomplished without in some way costing ressources (considerably more than level 3)? If you want audit on LIRs then abuse is probably not the only thing which should be thoroughly checked. Also, what would you do in case some LIRs choose not to respond to abuse complaints? I also still support the proposed idea with abuse address in inetnum/maintainer, but if the argument against is the lack of trust I think a level 3 check would solve the problem. Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc at jay.net Personal email: chr at corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net > -----Original Message----- > From: MarcoH [mailto:marcoh at marcoh.net] > Sent: 13. januar 2004 15:53 > To: Christian Rasmussen > Cc: Ulrich Kiermayr; Sebastian Abt; db-wg at ripe.net > Subject: Re: [db-wg] abuse-c > > > On Tue, Jan 13, 2004 at 03:38:43PM +0100, Christian Rasmussen wrote: > > > This is useless other then some verification that on the time > of creation > > > somebody replied to one mail sent to that specific address. Unless you > > > design an audit procedure to check the validity and response of the > > > address at random intervals it doesn't add anything to check it on > > > creation time except for extra time as the system waits for > your reply. > > > > Why do you say that its useless? As I understand some LIRs fear > that invalid > > email addresses might be entered, if so, the above procedure will not > > approve willnotwork at domain while a syntax check will. > > > > As I said, the email address can be checked again if its > changed - this way > > we can make sure that only valid email addresses received by the LIR are > > entered. What more do you want? > > That the database user can 'trust' the LIR to actually respond to emails > send to that address and not only when they change something and they have > to respond to the test message sent by ripe. > > Furthermore I still support the idea of abuse: being an attribute on > either inet(6)num or mntner, with inetnum taking precedence over mntner. > That means that with the verification method you propose the creation and > updates of inetnum object depends on the speed my collegeaus from the > abuse department handle their mail. So one or two customers sourcing a > spam run can prevent me from keeping the database up-to-date. > > > But this will of course not say anything about general response > time or if > > all other mails to the address is simply ignored.. But isn't that a > > completely different story? > > It is, so you propose to add extra overhead without gaining anything from > a user perspective other than that at some point in time somebody > responded to 1 email. > > > > Let's keep it at running a syntax check... > > > > Why? Whats the disadvantage of the above procedure? It might > require some > > ressources from Ripe NCC but I would say thats reasonable > considering you > > will this way be sure email addresses entered are all valid. At least I > > would prefer this compared to keeping the current system > because some might > > argue that the system discussed is not trustworthy. > > You add resources without benifit. Basic economics apply, adding cost > which doesn't increase your revenue is not a smart thing to do. > > Grtx, > > MarcoH >
- Previous message (by thread): [db-wg] abuse-c
- Next message (by thread): [db-wg] abuse-c
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]