- db-wg - mailman.ripe.net

E-mail address masquerading for archived mail messages
by RIPE NCC WebMaster 16 Aug '02

16 Aug '02

Dear Colleagues, [Apologies for duplicate mails] Beginning today, 16 August, the RIPE NCC will implement "e-mail address masquerading" for messages displayed on the web site in the RIPE and the RIPE NCC mailing list archives. E-mail masquerading makes it more difficult for spammers to harvest e-mail addresses from the mailing list archives. When masquerading is applied, the e-mail address of the sender will be hidden in the mail archived messages. Those reading archived mail will see a return e-mail address that appears as "<somebody@localhost>". When clicking on this e-mail address, the address of the original sender will be loaded in your mail program, enabling you to send a message to the author. The RIPE NCC has chosen to implement this security measure as there have been various complaints from members of the RIPE community that e-mail addresses were being abused by spammers for Unsolicited Bulk E-mail (UBE). By implementing this security measure we anticipate there will be a sharp reduction to address harvesting of archived e-mail addresses. We will be checking for harvesters who manage to overcome this measure and will take further steps if necessary. E-mail masquerading will be applied to all mailing lists found in the following directories: http://www.ripe.net/ripencc/mail-archives/ http://www.ripe.net/ripe/mail-archives/ We appreciate your understanding on this matter. Regards Jeroen Bet RIPE NCC WEBMASTER ==================

1 0

Phase 4 of the MAIL-FROM deprecation
by Andrei Robachevsky 16 Aug '02

16 Aug '02

Dear Colleagues, As you may know the third phase of phasing out the MAIL-FROM authentication scheme from the RIPE Database resulted in a very high rate of requests to update mntner objects coming to the Database Administration, ripe-dbm (please see my message on this subject http://www.ripe.net/ripe/mail-archives/db-wg/20020701-20021001/msg00021.html). The requests are coming from the owners of the mntner objects that still use only MAIL-FROM authentication scheme and therefore are locked. We still have about 1500 such mntner object whose owners didn't use the opportunity to update their objects during previous phases and now have to apply to ripe-dbm to fix this situation. Taking into account that this puts extra load on ripe-dbm and takes resources from serving the usual types of requests I'd like to propose a change for the phase 4 of the process of phasing out the MAIL-FROM authentication scheme. According to the agreed procedure (http://www.ripe.net/db/MD5-HOWTO.html#b._Migration_timeline) during the phase 4 maintainers with "auth:" attributes using "MAIL-FROM" will have those attributes removed. This is a clean-up step. In addition we would like to do the following: 1. mntners with MAIL-FROM authentication _only_ will be updated in the following way: - a password will be auto generated and all MAIL-FROM "auth:" attributes will be replaced with one auth: MD5-PW $1$<generated_string>; - a mnt-by: attribute will be added referencing a protected mntner RIPE-MAIL-FROM-MNT. This will serve as a tag. 2. A clear text password can be requested by sending an e-mail to ripe-dbm(a)ripe.net with the following in the subject line: MAIL-FROM:<mntner_name> without any spaces. The reply with the passphrase will be sent to contacts listed in "upd-to:" and admin-c's "e-mail:" of the mntner. 3. After that the mntner should be updated to remove the mnt-by: RIPE-MAIL-FROM-MNT attribute and to possibly change the password. 4. After a certain period of time (2 months) the service will be discontinued and decision will be made about the mntners that still haven't been modified (still bear the RIPE-MAIL-FROM-MNT tag). We will extend the deadline of the phase 4 till 15 August to have time to come to an agreement. I kindly ask you to consider this proposal and comment before that day. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 1

New Document available: RIPE-252
by RIPE NCC Document Announcement Service 15 Aug '02

15 Aug '02

Revised RIPE Document Announcement -------------------------------------- A revised document is available from the RIPE document store. Ref: ripe-252 Title: RIPE Database Reference Manual Author: Joao Luis Silva Damas, Andrei Robachevsky Date: 15 August 2002 Format: PS=283252 TXT=134071 Obsoletes: ripe-251 Obsoleted by: Updates: Updated by: Short content description ------------------------- This document describes the functionality of version 3.0 of the RIPE Database that uses the Routing Policy Specification Language (RPSL) to represent all Database objects. It also implements the Routing Policy System Security (RPSS) to provide authorisation mechanisms to enable a higher level of security for Internet Routing Registries (IRR). Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via WWW. The Database Reference Manual is available from the WWW at the following URL: http://www.ripe.net/docs/databaseref-manual.html The RIPE document store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-252.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-252.txt plain text version

1 0

Updating inet6num objects with a legacy status attribute
by leo vegoda 06 Aug '02

06 Aug '02

Dear Colleagues, The RIPE Database server, whois.ripe.net, has been updated to allow the new status attributes specified in the document: "New Values of the 'status:' Attribute for inet6num Objects" <http://www.ripe.net/docs/new-value-status.html> The status values of all inet6num objects maintained by the RIPE NCC have been updated as appropriate. We would be grateful if everyone maintaining inet6num objects would update them to use the new status attribute values. The RIPE NCC will use the "ASSIGNED" status value to determine the HD ratio when it receives a request for an additional IPv6 allocation. A request form for additional IPv6 allocations will be published in the near future. Best regards, -- leo vegoda RIPE NCC Registration Services

1 0

Some updates were not processed today
by Andrei Robachevsky 05 Aug '02

05 Aug '02

Dear Colleagues, Unfortunately several (136) update messages were not processed by the RIPE Database today, 5 August 2002. We are reluctant to re-process them as this may override the changes that might have been made afterwards. If you haven't received an acknowledgement to the update you sent to the RIPE Database today, please re-submit it again. We sincerely apologise for the inconvenience this caused. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC

2 1

New Document available: RIPE-243
by RIPE NCC Document Announcement Service 05 Aug '02

05 Aug '02

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store: "New Values of the "status:" Attribute for inet6num Objects". Short content description ------------------------- This document describes the new values of the "status:" attribute for inet6num objects and their impact on database operation. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via WWW. "New Values of the "status:" Attribute for inet6num Objects" is available from the WWW at the following URL: http://www.ripe.net/docs/new-value-status.html The RIPE document store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-243.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-243.txt plain text version Kind Regards, Jeroen Bet Webmaster RIPE NCC

1 0

Actions web page
by Nigel Titley 30 Jul '02

30 Jul '02

Folks, Please note that there is now a separate actions page on the DB WG web site. http://www.ripe.net/ripe/wg/db/db-actions.html Check now and avoid embarrassment at the next WG meeting :-) All the best NIgel

1 0

fwd: Re: New draft: "New Values of the 'status:' attribute for inet6num Objects"
by Wilfried Woeber, UniVie/ACOnet 26 Jul '02

26 Jul '02

Sorry, I forgot to cc: the DB-WG list :-( I guess we should keep this thread in the LIR-WG list for the moment. Apologies for the mix-up, Wilfried. ______________________________________________________________________ From: ACCESS::WOEBER "Wilfried Woeber, UniVie/ACOnet" 26-JUL-2002 11:39:50.52 To: MX%"leo(a)ripe.net" CC: MX%"lir-wg(a)ripe.net",WOEBER Subj: Re: New draft: "New Values of the 'status:' attribute for inet6num Objects" Dear Leo and "Team", >The new draft is available from our web site at: > ><http://www.ripe.net/ripe/draft-documents/new-value-status.html> Looks good! >We would welcome comments on this new draft until Thursday, 1 August >2002. All comments and suggestions should be sent to <lir-wg(a)ripe.net>. Procedural question: How are we going to modify existing objects to conform to this proposal? Right now the template query returns: bash-2.05a$ wripe -t inet6num [ ... ] inet6num: [mandatory] [single] [primary/look-up key] [ ... ] status: [generated] [single] [ ] [ ... ] and it seems to be "optional" for the (new) ALLOCATED-BY-RIR case: bash-2.05a$ wripe -r 2001:0628::/35 [ ... ] inet6num: 2001:0628::/35 netname: AT-ACONET-19990920 descr: ACOnet Sub-TLA block country: AT admin-c: WW144 tech-c: WW144 tech-c: WK42 tech-c: CP8-RIPE notify: Domain-Admin(a)UniVie.ac.at mnt-by: RIPE-NCC-HM-MNT mnt-lower: ACONET-LIR-MNT changed: hostmaster(a)ripe.net 19990920 changed: hostmaster(a)ripe.net 20011019 source: RIPE Is this going to change? E.g. to: status: [mandatory] [single] [ ] The wording used in the draft seems to indicate [optional] [single] [ ]. I think some clarification would be helpful. Thanks, cheers, Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

New draft: "New Values of the 'status:' attribute for inet6num Objects"
by leo vegoda 25 Jul '02

25 Jul '02

Dear Colleagues, Thank you for the comments we have received on the draft document "New Values of the 'status:' attribute for inet6num Objects". We have revised it to incorporate the suggestions you have made. The meaning of the labels has been made clearer, in line with the comments received. ALLOCATED-BY-RIR - For allocations made by an RIR to an LIR. ALLOCATED-BY-LIR - For allocations made by an LIR or an LIR's downstream customer to another downstream organisation. ASSIGNED - For assignments made to End User sites The new draft is available from our web site at: <http://www.ripe.net/ripe/draft-documents/new-value-status.html> We would welcome comments on this new draft until Thursday, 1 August 2002. All comments and suggestions should be sent to <lir-wg(a)ripe.net>. Regards, -- leo vegoda RIPE NCC, Registration Services Assistant Manager

1 0

Mntners with only MAIL-FROM auth
by Andrei Robachevsky 25 Jul '02

25 Jul '02

Attention owners of mntner objects using _only_ MAIL-FROM authentication method. Dear Colleagues, We recently sent out a message to all contacts for maintainers that still used MAIL-FROM as the ONLY means of authentication. This method is no longer valid and no updates can be authorised if any of the maintainers checked are in this situation. The message pointed to the proposed procedure on how to fix such situation (http://www.ripe.net/db/mailfrom.html). The RIPE-DBM support team has been overwhelmed with fax requests to update these maintainers. At the moment we are not able to respond to these requests as quickly as we would like to do. We have found it necessary to give a higher priority to other support requests. Therefore the response time for updates to maintainer authentication may be 5 to 10 working days. Please do not send repeat faxes unless we ask for them and do not send e-mails asking for a status update on the changes. This only slows the whole process down. We will reply to each request as soon as we make the change or find that we need additional information. This message will also be sent to all contacts for maintainers that still use MAIL-FROM as the ONLY means of authentication. Please bear with us on this and we apologise for the delay. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0