Should the "e-mail" attribute be mandatory for the "person" object?
Folks, Email is the preferred communication medium when troubleshooting internetworking problems. Time and time again, "inetnum" objects with no valid email address cause grief. In the absence of relevant "e-mail" attributes, desperate administrators sometimes send mail to addresses found in "changed" and "notify" attributes. Sometimes the only option left is resorting to telephone calls, regardless of the expenses, time differences and language barriers often involved. I would therefore like to suggest making the "e-mail" attribute mandatory for the "person" object. If this isn't acceptable, then maybe at least one of the "person" or "role" objects referred to by an "inetnum" object should carry an "e-mail" attribute. Additionally, in order to enhance address validity, I would like to suggest performing some kind of validation on these "e-mail" attribute values - perhaps simple syntax checking, or maybe even full round-trip SMTP testing, or something in between. Your comments, please. Thor -- http://thorweb.anta.net/
On Thu, 30 Oct 2003, Thor Kottelin wrote: I would like to see mandatory email and maybe even a once yearly auto-check to see that the email is still valid. -Hank
Folks,
Email is the preferred communication medium when troubleshooting internetworking problems. Time and time again, "inetnum" objects with no valid email address cause grief. In the absence of relevant "e-mail" attributes, desperate administrators sometimes send mail to addresses found in "changed" and "notify" attributes. Sometimes the only option left is resorting to telephone calls, regardless of the expenses, time differences and language barriers often involved.
I would therefore liketo suggest making the "e-mail" attribute mandatory for the "person" object. If this isn't acceptable, then maybe at least one of the "person" or "role" objects referred to by an "inetnum" object should carry an "e-mail" attribute. Additionally, in order to enhance address validity, I would like to suggest performing some kind of validation on these "e-mail" attribute values - perhaps simple syntax checking, or maybe even full round-trip SMTP testing, or something in between.
Your comments, please.
Thor
Hank Nussbacher
I would like to see mandatory email and maybe even a once yearly auto-check to see that the email is still valid. -Hank
While such checks could improve the data quality they'd also be an improvement on the side of data protection. But then, how would the change management be organised and who is carrying the cost when $someone_else sees the benefit? -Peter
[...] "inetnum" objects with no valid email address cause grief. [...]
I would therefore like to suggest making the "e-mail" attribute mandatory for the "person" object. If this isn't acceptable, then maybe at least one of the "person" or "role" objects referred to by an "inetnum" object should carry an "e-mail" attribute.
Your comments, please.
For person objects, I see no particular reason to have email addresses. (While I see little use for a person object without one, I don't know what uses about which I know nothing person objects may be put to.) But I strongly believe that every inetnum _needs_ an email address, one which reaches a human with authority to deal with abuse issues relating to that netblock. Unfortunately, this is unlikely to happen. RIPE's own blocks fail the test; in the few cases where I've had to escalate all the way to them, (usually because a directly-allocated block has contact email addresses that bounce), RIPE has flatly refused to do any of - Take the abuse report and see to it that the abuse stops - Ensure that the netblock's contact address(es) is(are) corrected - Deallocate the address space With RIPE itself refusing to take ultimate responsibility for what's done with its address space, why should anyone else? /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
On 2003-11-05 15:54:32 -0500, der Mouse wrote:
[...] "inetnum" objects with no valid email address cause grief. [...]
I would therefore like to suggest making the "e-mail" attribute mandatory for the "person" object. If this isn't acceptable, then maybe at least one of the "person" or "role" objects referred to by an "inetnum" object should carry an "e-mail" attribute.
For person objects, I see no particular reason to have email addresses. (While I see little use for a person object without one, I don't know what uses about which I know nothing person objects may be put to.)
But I strongly believe that every inetnum _needs_ an email address, one which reaches a human with authority to deal with abuse issues relating to that netblock.
Please be aware that there is an object that is available for documenting Computer Security Incident Response Team (CSIRT). This is the irt object, described in ripe-254: http://www.ripe.net/ripe/docs/irt-object.html These are specifically designed for handling abuse issues. It is possible to make these mandatory in inetnum objects, but that would have to be part of an effort taken in cooperation with the address policy working group. It is not currently a requirement to have a way to deal with abuse issues to be allocated or assigned IP space in the RIPE NCC service region.
Unfortunately, this is unlikely to happen. RIPE's own blocks fail the test; in the few cases where I've had to escalate all the way to them, (usually because a directly-allocated block has contact email addresses that bounce), RIPE has flatly refused to do any of
- Take the abuse report and see to it that the abuse stops - Ensure that the netblock's contact address(es) is(are) corrected - Deallocate the address space
The RIPE DBM mailbox does receive abuse complaints, and we direct the inviduals to the appropriate contacts as best that we are able. But AFAIK, there has not been a consensus in the RIPE community for the RIPE NCC to take any of the actions specified above. This is a reasonable forum for this discussion, although other RIPE working groups may also be useful. I thank you for raising the issue, and look forward to watching the thread progress. -- Shane Kerr RIPE NCC
But I strongly believe that every inetnum _needs_ an email address, one which reaches a human with authority to deal with abuse issues relating to that netblock. Please be aware that there is an object that is available for documenting Computer Security Incident Response Team (CSIRT). This is the irt object, [...]
Well, I-the-abuse-victim (usually but not necessarily spam recipient) don't much care whether it's done with an irt object or with a person object, as long as I can locate somewhere useful to write to. :-)
It is not currently a requirement to have a way to deal with abuse issues to be allocated or assigned IP space in the RIPE NCC service region.
That needs to be fixed, then. (Actually, I believe that the RIPE should have all its address space taken away from it by the IANA until it gets fixed; nobody should have address space without being contactable about abuse issues. And yes, I recognize that this isn't going to happen.) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Thor, On 2003-10-30 21:41:54 +0200, Thor Kottelin wrote:
I would therefore like to suggest making the "e-mail" attribute mandatory for the "person" object.
This is a straightforward change. One issue is what to do with existing person objects that doe not have an "e-mail:" attribute. The most straightforward solution is to make no change to the objects, but to prevent new or modified person objects without "e-mail:".
If this isn't acceptable, then maybe at least one of the "person" or "role" objects referred to by an "inetnum" object should carry an "e-mail" attribute.
Additionally, in order to enhance address validity, I would like to suggest performing some kind of validation on these "e-mail" attribute values - perhaps simple syntax checking, or maybe even full round-trip SMTP testing, or something in between.
The Database software does do some syntax checking, but only to verify that the address looks something like an RFC 2822 address. We can do varying degrees of checking, based on the same ideas presented here: http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-db-contact-da... Personally, I would prefer that when an error is detected in a contact address during an update that a clear warning be put in the acknowledgement message. This allows for update with e-mail that is experiencing transient delivery problems. However, if this group feels strongly it will be possible to reject the update. -- Shane Kerr RIPE NCC
On Fri, 7 Nov 2003, Shane Kerr wrote:
Thor,
On 2003-10-30 21:41:54 +0200, Thor Kottelin wrote:
I would therefore like to suggest making the "e-mail" attribute mandatory for the "person" object.
This is a straightforward change.
One issue is what to do with existing personobjects that doe not have an "e-mail:" attribute.The most straightforward solution is to make no change to the objects, but to prevent new or modified person objects without "e-mail:".
Sounds reasonable.
If this isn't acceptable, then maybe at least one of the "person" or "role" objects referred to by an "inetnum" object should carry an "e-mail" attribute.
Additionally, in order to enhance address validity, I would like to suggest performing some kind of validation on these "e-mail" attribute values - perhaps simple syntax checking, or maybe even full round-trip SMTP testing, or something in between.
The Database software does do some syntax checking, but only to verify that the address looks something like an RFC 2822 address.We can do varying degrees of checking, based on the same ideas presented here:
http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-db-contact-da...
Personally, I would prefer that when an error is detected in a contact address during an update that a clear warning be put in the acknowledgement message.This allows for update with e-mail that is experiencing transient delivery problems.However, if this group feels strongly it will be possible to reject the update.
No strong feeling either way.
-- Shane Kerr RIPE NCC
Hank Nussbacher
participants (5)
-
der Mouse -
Hank Nussbacher -
Peter Koch -
Shane Kerr -
Thor Kottelin