[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