Réf. : From Address Forged
Actually, the address was "forged" but only partially by Trevor, and Hostmaster was in copy of the mail, More over it was an attempt to repair the original error and to avoid the work necessary to rebuild all the links that have destroyed. Please apologize again for all these perturbations. Thierry GALL
Hi, apologize is cheap, the work we had until now is more than 5 person-days. Is Thierry Gall address: TRANSPAC France address: DSR/CSI address: 12 bis, rue Campagne Premiere address: 75014 Paris, France a valid billing-address? GALL Thierry TPC-SRD wrote:
Actually, the address was "forged" but only partially by Trevor, and Hostmaster was in copy of the mail, More over it was an attempt to repair the original error and to avoid the work necessary to rebuild all the links that have destroyed.
And destroyed other links!!! We do not create person-objects for fun. we do not protect person-objects for fun. If you have any further questions, please do not hesitate to contact us. Kind regards, Wilhelm Hostmaster @ Xlink - Network Information Centre -- [X] Xlink Internet Consulting GmbH | | Wilhelm Buehler, Xlink Network Information Centre | hostmaster@xlink.net | | Vincenz-Priessnitz-Strasse 3 [X] D-76131 Karlsruhe | Tel: +49 721/6635-410 [X] Fax: +49 721/6635-349 | | Geschaeftsfuehrer: Michael Rotert. Amtsgericht Koeln, HRB 3526. | Auftraege erledigen wir zu unseren Allgemeinen Geschaeftsbedingungen. ---------------------------------------------------------------------[ ]
Wilhelm and other colleagues, it appears that the header forging did only occur in an effort to correct mistakes made earlier. Repeat: the updates that caused the problems originally were not done using forged headers. This does not mean header forging was not very bad judgement, but at least it occurred only in an effort to correct earlier mistakes. The RIPE NCC will work with Transpac on a post-mortem analysis. More news as it develops. Daniel
On 5 Nov 98, at 17:45, Daniel Karrenberg wrote:
Wilhelm and other colleagues,
it appears that the header forging did only occur in an effort to correct mistakes made earlier. Repeat: the updates that caused the problems originally were not done using forged headers. This does not mean header forging was not very bad judgement, but at least it occurred only in an effort to correct earlier mistakes. The RIPE NCC will work with Transpac on a post-mortem analysis. More news as it develops.
Hmm, if it was needed to forge a header to correct a mistake, how then the mistake could be done without forging the header? siegfried
Daniel
First of all, please dont quote complete mails for just 2 lines from you..
Hmm, if it was needed to forge a header to correct a mistake, how then the mistake could be done without forging the header?
if you have attended at this topic you should have noticed that most handles had no protection (just a notify) but were not mounted. So there was no problem to delete these records... Thats it.. Winfried
On Thu, Nov 05, 1998 at 06:01:23PM +0100, Siegfried Langenbach wrote:
On 5 Nov 98, at 17:45, Daniel Karrenberg wrote:
Wilhelm and other colleagues,
it appears that the header forging did only occur in an effort to correct mistakes made earlier. Repeat: the updates that caused the problems originally were not done using forged headers. This does not mean header forging was not very bad judgement, but at least it occurred only in an effort to correct earlier mistakes. The RIPE NCC will work with Transpac on a post-mortem analysis. More news as it develops.
Hmm, if it was needed to forge a header to correct a mistake, how then the mistake could be done without forging the header?
siegfried
I get tired discussing this. Yes, the original 'mistake' didn't involve forged headers. Yes, old records have been deleted this way. No, these records were not protected by their maintainers (auth: NONE). Yes, the handles were reallocated to other records. Yes, some of these new records were protected by their maintainers. Yes, these new records were deleted using forged mail headers. No, the old records were not restored because the restoring update was sent too early (usually in the same mail which inherently fails). Yes, the yet-again free handles have been reallocated to even more new records again. Yes, deleting the new records caused more inconsistencies and more data loss. No, deleting the new records didn't correct the original 'mistake' at all. Yes, deleting the new records produced more errors outside the RIPE-DB realm (for example, registrations of domains that reference the new-but-then-deleted person records in the RIPE-DB failed). Yes, deleting the new records sabotaged other people's attempt to recover from original 'mistake'. We have thus switched from MAIL-FROM to CRYPT-PW authorization. If I see any unauthorized update in the future, the responsible person gets shot. -- i.A. Michael van Elst / phone: +49 721 6635 330 Xlink - Network Information Centre \/ fax: +49 721 6635 349 Vincenz-Priessnitz-Str. 3 /\ link http://nic.xlink.net/ D-76131 Karlsruhe, Germany /_______ email: hostmaster@xlink.net [ Xlink Internet Consulting GmbH, Sitz Koeln ] [ Amtsgericht Koeln HRB 3526, Geschaeftsfuehrer: Michael Rotert ]
On 5 Nov 98, at 20:41, Michael van Elst wrote:
On Thu, Nov 05, 1998 at 06:01:23PM +0100, Siegfried Langenbach wrote:
On 5 Nov 98, at 17:45, Daniel Karrenberg wrote:
Wilhelm and other colleagues,
it appears that the header forging did only occur in an effort to correct mistakes made earlier. Repeat: the updates that caused the problems originally were not done using forged headers. This does not mean header forging was not very bad judgement, but at least it occurred only in an effort to correct earlier mistakes. The RIPE NCC will work with Transpac on a post-mortem analysis. More news as it develops.
Hmm, if it was needed to forge a header to correct a mistake, how then the mistake could be done without forging the header?
siegfried
I get tired discussing this.
Yes, the original 'mistake' didn't involve forged headers. Yes, old records have been deleted this way.
Dear Michael, I dont think that reaction is appropriate. I see a valid need of RIPE NCC members to know what was going on. As chair of CORE-SRS-WG I am personally envolved in that kind of problems and would like to learn. You may have more infos than others, thats fine with you, but please let us share them. Your listing of "affirmatives" is not really the report I am expecting (as promised by Daniel). siegfried [...]
-- i.A. Michael van Elst / phone: +49 721 6635 330 Xlink - Network Information Centre \/ fax: +49 721 6635 349 Vincenz-Priessnitz-Str. 3 /\ link http://nic.xlink.net/ D-76131 Karlsruhe, Germany /_______ email: hostmaster@xlink.net [ Xlink Internet Consulting GmbH, Sitz Koeln ] [ Amtsgericht Koeln HRB 3526, Geschaeftsfuehrer: Michael Rotert ]
On Fri, Nov 06, 1998 at 09:16:36AM +0100, Siegfried Langenbach wrote:
On 5 Nov 98, at 20:41, Michael van Elst wrote:
I get tired discussing this.
Dear Michael,
Dear Siegfried,
I dont think that reaction is appropriate.
I guess then you didn't waste days and weeks fixing the 'mistake' only to see that your work has been subverted using forged authorizations. I don't think that an emotional reaction is inappropriate.
I see a valid need of RIPE NCC members to know what was going on.
I am sure that the RIPE NCC members do know what was going on and have been providing real help. Thanks to them. [...]
Your listing of "affirmatives" is not really the report I am expecting (as promised by Daniel).
Who am I to give Daniel's report ? ;-) I merely answered your question and shared a sad little bit of information. Michael van Elst -- i.A. Michael van Elst / phone: +49 721 6635 330 Xlink - Network Information Centre \/ fax: +49 721 6635 349 Vincenz-Priessnitz-Str. 3 /\ link http://nic.xlink.net/ D-76131 Karlsruhe, Germany /_______ email: hostmaster@xlink.net [ Xlink Internet Consulting GmbH, Sitz Koeln ] [ Amtsgericht Koeln HRB 3526, Geschaeftsfuehrer: Michael Rotert ]
participants (6)
-
Daniel Karrenberg -
GALL Thierry TPC-SRD -
Michael van Elst -
Siegfried Langenbach -
Winfried Haug -
Xlink Hostmaster W . Buehler