Support of, and comments on, proposal 2010-08
Dear list, On behalf of the Team Internetsafety of the Dutch Telecommunications Authority OPTA, I would like to comment on the draft proposal 2010-08. The Team Internetsafety conducts spam- and malware investigations related to the Netherlands. Almost all of these investigations have components which require us to use RIPE (or other RIRs) for several pieces of information, most commonly valid abuse contacts for a netblock or ASN. We strongly support the mandatory addition of an abuse-mailbox: field in the irt object. However, we see several loopholes in the current contents of the proposal. 1. There is no mention in the policy about the validity of an abuse-mailbox: entry 2. There is no mention in the policy about the responsiveness of an abuse-mailbox: entry 3. There is (logically) no mention in the policy about a periodic check on (1) and (2) 4. There is no mitigating procedure in case of false/missing/invalid/... abuse-mailbox: information Ad 1: What will stop a RIPE member from entering an invalid e-mail address? If the purpose of the policy is to 'solve the problem of finding the right abuse contact', some additional procedure should be in place to make sure mail to the mentioned abuse-mailbox: does actually arrive somewhere and does not bounce. Ad 2: A valid e-mail address is no guarantee that abuse mail is being handled or even looked at. Although we recognize it might not be the responsibility of RIPE to ensure a maintainer has a proper abuse policy mechanism in place, we'd encourage some additional reflection on this issue. Ad 3: Requiring a field update with each object update is a good idea, however with largely static objects it might be a good idea to periodically check at least (1) and preferably (2). Ad 4: If a member (systematically) does not adhere to the mandatory policy, some kind of procedure should be in place to motivate the member to follow procedure. Without 'repercussions', a 'mandatory' policy becomes just mandatory in name, not in function. Kind regards, Pepijn Vissers Team Internetsafety OPTA - +++++++++++++++++++++++++++++++++++++++++++++ Disclaimer Dit e-mailbericht kan vertrouwelijke informatie bevatten of informatie die is beschermd door een beroepsgeheim. Indien dit bericht niet voor u is bestemd, wijzen wij u erop dat elke vorm van verspreiding, vermenigvuldiging of ander gebruik ervan niet is toegestaan. Indien dit bericht blijkbaar bij vergissing bij u terecht is gekomen, verzoeken wij u ons daarvan direct op de hoogte te stellen via tel.nr 070 315 3500 of e-mail mailto:mail@opta.nl en het bericht te vernietigen. Dit e-mailbericht is uitsluitend gecontroleerd op virussen. OPTA aanvaardt geen enkele aansprakelijkheid voor de feitelijke inhoud en juistheid van dit bericht en er kunnen geen rechten aan worden ontleend. This e-mail message may contain confidential information or information protected by professional privilege. If it is not intended for you, you should be aware that any distribution, copying or other form of use of this message is not permitted. If it has apparently reached you by mistake, we urge you to notify us by phone +31 70 315 3500 or e-mail mailto:mail@opta.nl and destroy the message immediately. This e-mail message has only been checked for viruses. The accuracy, relevance, timeliness or completeness of the information provided cannot be guaranteed. OPTA expressly disclaims any responsibility in relation to the information in this e-mail message. No rights can be derived from this message.
I originally had the same queries, but not anymore. If an abuse contact becomes standardized and mandatory then it will be easier to consistently contact the correct contact in organizations that take abuse seriously. Unfortunately not all operators take abuse seriously, but that us not going to change anytime soon ( the presentation on reputation at RIPE 61 makes for an interesting read and possible way forward) While it would be wonderful if ALL operators took abuse seriously it is futile for the purposes of this proposal. Maybe there is an opportunity for this WG to work on operator education, though I am unsure as to the correct protocols and procedures for same Regards Michele Mr. Michele Neylon Blacknight http://Blacknight.tel Via iPhone so excuse typos and brevity On 17 Nov 2010, at 13:59, "Vissers, Pepijn" <P.Vissers@opta.nl<mailto:P.Vissers@opta.nl>> wrote: Dear list, On behalf of the Team Internetsafety of the Dutch Telecommunications Authority OPTA, I would like to comment on the draft proposal 2010-08. The Team Internetsafety conducts spam- and malware investigations related to the Netherlands. Almost all of these investigations have components which require us to use RIPE (or other RIRs) for several pieces of information, most commonly valid abuse contacts for a netblock or ASN. We strongly support the mandatory addition of an abuse-mailbox: field in the irt object. However, we see several loopholes in the current contents of the proposal. 1. There is no mention in the policy about the validity of an abuse-mailbox: entry 2. There is no mention in the policy about the responsiveness of an abuse-mailbox: entry 3. There is (logically) no mention in the policy about a periodic check on (1) and (2) 4. There is no mitigating procedure in case of false/missing/invalid/... abuse-mailbox: information Ad 1: What will stop a RIPE member from entering an invalid e-mail address? If the purpose of the policy is to ‘solve the problem of finding the right abuse contact’, some additional procedure should be in place to make sure mail to the mentioned abuse-mailbox: does actually arrive somewhere and does not bounce. Ad 2: A valid e-mail address is no guarantee that abuse mail is being handled or even looked at. Although we recognize it might not be the responsibility of RIPE to ensure a maintainer has a proper abuse policy mechanism in place, we’d encourage some additional reflection on this issue. Ad 3: Requiring a field update with each object update is a good idea, however with largely static objects it might be a good idea to periodically check at least (1) and preferably (2). Ad 4: If a member (systematically) does not adhere to the mandatory policy, some kind of procedure should be in place to motivate the member to follow procedure. Without 'repercussions', a 'mandatory' policy becomes just mandatory in name, not in function. Kind regards, Pepijn Vissers Team Internetsafety OPTA - +++++++++++++++++++++++++++++++++++++++++++++ Disclaimer Dit e-mailbericht kan vertrouwelijke informatie bevatten of informatie die is beschermd door een beroepsgeheim. Indien dit bericht niet voor u is bestemd, wijzen wij u erop dat elke vorm van verspreiding, vermenigvuldiging of ander gebruik ervan niet is toegestaan. Indien dit bericht blijkbaar bij vergissing bij u terecht is gekomen, verzoeken wij u ons daarvan direct op de hoogte te stellen via tel.nr 070 315 3500 of e-mail mailto:mail@opta.nl en het bericht te vernietigen. Dit e-mailbericht is uitsluitend gecontroleerd op virussen. OPTA aanvaardt geen enkele aansprakelijkheid voor de feitelijke inhoud en juistheid van dit bericht en er kunnen geen rechten aan worden ontleend. This e-mail message may contain confidential information or information protected by professional privilege. If it is not intended for you, you should be aware that any distribution, copying or other form of use of this message is not permitted. If it has apparently reached you by mistake, we urge you to notify us by phone +31 70 315 3500 or e-mail mailto:mail@opta.nl and destroy the message immediately. This e-mail message has only been checked for viruses. The accuracy, relevance, timeliness or completeness of the information provided cannot be guaranteed. OPTA expressly disclaims any responsibility in relation to the information in this e-mail message. No rights can be derived from this message.
On 17/Nov/10 14:45, Michele Neylon :: Blacknight wrote:
Maybe there is an opportunity for this WG to work on operator education, though I am unsure as to the correct protocols and procedures for same
IMHO it may be very useful, as RIPE has enough moral impact. Setting up a procedure for coordinating periodic testing of abuse-mailboxes, involving ISPs as well as some of their users (mail server admins), might be a good starting point...
Alessandro I think you misunderstood what I was getting at. While testing abuse mailboxes would have merit I was referring more to the general importance of handling abuse complaints and the overall impact that abuse could have for a business. Regards Michele On 17 Nov 2010, at 15:31, Alessandro Vesely wrote:
On 17/Nov/10 14:45, Michele Neylon :: Blacknight wrote:
Maybe there is an opportunity for this WG to work on operator education, though I am unsure as to the correct protocols and procedures for same
IMHO it may be very useful, as RIPE has enough moral impact. Setting up a procedure for coordinating periodic testing of abuse-mailboxes, involving ISPs as well as some of their users (mail server admins), might be a good starting point...
Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.mobi/ http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845
On 17/Nov/10 16:11, Michele Neylon :: Blacknight wrote:
[toppostfix] On 17 Nov 2010, at 15:31, Alessandro Vesely wrote:
On 17/Nov/10 14:45, Michele Neylon :: Blacknight wrote:
Maybe there is an opportunity for this WG to work on operator education, though I am unsure as to the correct protocols and procedures for same
IMHO it may be very useful, as RIPE has enough moral impact. Setting up a procedure for coordinating periodic testing of abuse-mailboxes, involving ISPs as well as some of their users (mail server admins), might be a good starting point...
I think you misunderstood what I was getting at.
I don't think so. "Testing" implies that something actually works.
While testing abuse mailboxes would have merit I was referring more to the general importance of handling abuse complaints and the overall impact that abuse could have for a business.
Tobia's proposal (2010-09) doesn't quite address testing, as it only concerns update notifications and corresponding corrections. How does RIPE NCC become aware that a database object contains invalid information? By "testing an abuse-mailbox" I mean actually sending a message to it, and verify the outcome. Sending is the most effective way to determine an address' validity. Thus, RIPE might define a "test" message-type. It should work much like any other complaint, except it does not affect reputation. To acknowledge the test, the recipient should send a response of some kind; it should be designed so as to also allow testing feedback loops. So much for the merit of testing. For the overall impact, building such a testing infrastructure implies that operators learn to run automated scripts upon receiving messages at their abuse-mailboxes, recognizing a few kinds of message formats (arf, x-arf, and iodef extension; one or more of these should provide for test messages.) The possibility to serve feedback loops for interested end users may also be aired, and postmasters may then want to send test messages to their own ISPs to check they work as expected.
Am 17.11.2010 17:40, schrieb Alessandro Vesely:
Tobia's proposal (2010-09) doesn't quite address testing, as it only concerns update notifications and corresponding corrections. How does RIPE NCC become aware that a database object contains invalid information? By "testing an abuse-mailbox" I mean actually sending a message to it, and verify the outcome.
The reason for splitting this up was, that the whois database has accuracy problems at other places as well. So the intend was to find a way to solve the accuracy problem in the hole whois database. And it was mentioned by Brian Nisbet before at the RIPE Service Group meeting, that there should be collaboration on this with different groups and this found more or less consensus. So at least it would be enough to setup a policy proposal, that requests from RIPE NCC to fix all accuracy problems in the database.
Sending is the most effective way to determine an address' validity. Thus, RIPE might define a "test" message-type. It should work much like any other complaint, except it does not affect reputation. To acknowledge the test, the recipient should send a response of some kind; it should be designed so as to also allow testing feedback loops. So much for the merit of testing.
Accepting mails from one system in a standardized format will tell you, that this system is accepting standardized mails from exactly this system. Not more. It does not show you if there is a spamfilter implemented (which is might be one good measurement), it does not tell you if the account is accepting mails from other IP addresses and not in other formats. I'm would more like a spreaded approach. People who are using the data for reporting, should be able to easily give feedback to RIPE. API, Webform, whatever. Putting these things together would help much more and would give RIPE NCC more power. "Oh damn I have overseen this message!" would not work anymore. The other part is, that in my opinion it is not RIPEs part to judge the work others are doing. I think the market is big enough that there will be self regulatory mechanism that show exactly who is doing a good job and who is not. Important for that is, that the information is freely available.
For the overall impact, building such a testing infrastructure implies that operators learn to run automated scripts upon receiving messages at their abuse-mailboxes, recognizing a few kinds of message formats (arf, x-arf, and iodef extension; one or more of these should provide for test messages.) The possibility to serve feedback loops for interested end users may also be aired, and postmasters may then want to send test messages to their own ISPs to check they work as expected.
I think the idea of a test message is a good idea, but I would not like to use this measurement only. Thanks, Tobias
participants (4)
-
Alessandro Vesely -
Michele Neylon :: Blacknight -
Tobias Knecht -
Vissers, Pepijn