January 2002 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 17 May '18

17 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

New RIPE Database features
by Andrei Robachevsky 07 Feb '02

07 Feb '02

Dear colleagues, [ Apologies for multiple messages ] The new features of the RIPE Database requested by the community are now available in "beta version" on our TEST whois server (http://www.ripe.net/ripencc/pub-services/db/testdb.html). The new features are: - the "irt" object (please see my previous announcement at http://www/ripe/mail-archives/db-wg/current/msg00012.html) - the new "status:" value of the inetnum object "LIR-PARTITIONED PA/PI" (please see the original proposal at http://www/ripe/mail-archives/db-wg/20010701-20020101/msg00090.html). You may try these features by - sending your updates to test-dbm(a)ripe.net; - querying the test-whois.ripe.net, port 43. The new version of the software is under heavy testing now and will be put into production shortly after the RIPE meeting. Your comments are appreciated. You may contact the development team directly at dbrip(a)ripe.net. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC

2 4

RE: Database development plans
by Lu, Ping 31 Jan '02

31 Jan '02

> -----Original Message----- > From: David Kessens [mailto:david@IPRG.nokia.com] > Sent: Wednesday, January 30, 2002 11:22 PM > To: Lu, Ping > Cc: 'Larry J. Blunk'; db-wg(a)ripe.net > Subject: Re: Database development plans > > > > Ping, > > On Wed, Jan 30, 2002 at 07:20:47PM -0500, Lu, Ping wrote: > > > > If the mail can be intercepted then a cookie confirmation > > won't make a difference. > > You can forge a mail header without being able to intercept the mail. > > > If the mail can be intercepted then a clear-text password scheme > > won't make a difference. > > You can guess the password without being able to intercept the mail. > > David K. > --- > And CRYPT-PW now is no better than the MAIL-FROM. Both are easy to get thru. But my point is "If the email is not secure then the new proposals (cookie, MD5 or even shadow password) won't achieve their goals". However let's focus on "If the email is secure ..." case now. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

1 0

RE: Database development plans
by Lu, Ping 31 Jan '02

31 Jan '02

> > I still feel that MAIL-FROM with cookie confirmation is > considerably > better than "no authentication". I don't see how a cookie is really > any easier to intercept than a password or secret string sent in the > clear. It also doesn't suffer from potential dictionary cracking > attacks. While it is clear that user's will find it more complicated > than the current MAIL-FROM, I could still envisage some > preferring it over passwords/PGP-KEYs. > > I checked out majordomo's cookie confirmation code and found that > the cookie generation uses a hash of a secret string, the user's > email address, and the requested command. Thus the server does not > need to keep any cookie state. One could include a timestamp in the > cookie hash generation and confirmation message to help guard against > replay's. > > Finally, I would imagine that those who are using automatic scripts > would migrate to passwords or (preferably) PGP. > > If the mail can be intercepted then a cookie confirmation won't make a difference. If the mail can be intercepted then a clear-text password scheme won't make a difference. Only if the mail is secure then a cookie or password makes sense. Also a cookie confirmation increases the chance to start a mail storm. >> In my ISI/RPSL/6bone version of the perl server (=not the >> official RIPE version of the perl software) the crypt-pw is indeed not shown upon >> query or in the downloadable database files. This is not a bad idea to shadow the crypted string (then MD5 is not really necessary ). But I think the RIPE-DB server needs some structure changes to support this. >> >> This is clearly a community decision. I would suggest that if MD5 is > > implemented as an additional method, strings bigger than 8 > characters > > are a necessity (and it is really easy to do so with MD5). > The extra > > length makes it really difficult to have dictionary attacks if > > properly used (I mean you can use a file with the complete works of > > shakespeare when generating the MD5 hash) > > If RIPE-DB are going to support different auth functions, why not using PAM to support any kind of PAM modules then ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

2 1

Database development plans
by Andrei Robachevsky 30 Jan '02

30 Jan '02

Dear colleagues, Please find below a list of the projects that we included in our development plan. We would appreciate if you could indicate importance and usefullness of specific projects so we can adjust their priorities. Several more detailed proposals will follow. Here I just included brief description of the projects not to enter premature implementation discussion. Regards, Andrei Robachevsky DB Group Manager RIPE NCC 1. Authorisation checks across multiple databases Migration to v3/RPSL made creating objects in the routing registry a much more complex process due to the introduction of the Routing Policy System Security (RFC 2725). The real problem was with so called "foreign" route objects that either announce non-RIPE address space or are originated from non-RIPE ASN. As there were no corresponding objects in the RIPE database such transactions failed. A workaround is in place now that requires duplication of objects in the RIPE RR and as a result - low security level. The proposed solution is to get this information from sources that contain authoritative information about network objects that are supposed to authorise the transaction. For example, when creating a route from APNIC's address space, but originated from a RIPE ASN, authorisation information will be requested from both RIPE and APNIC sources. 2. Real-time (interactive) updates Currently only e-mail updates are supported by the RIPE Database which complicates automation of the update process at the clients side. The facility that will allow connection oriented interactive, or real-time updates, will simplify development of the client tools and make synchronising of LIR's address management database an easier task. Once implemented this project will present a facility for other tools, such as web-based update interface, or a standalone syntax checker. 3. Automatic cleanup of unreferenced person objects You may find the initial proposals: http://www.ripe.net/ripe/mail-archives/db-wg/20010701-20020101/msg00079.html http://www.ripe.net/ripe/mail-archives/db-wg/20010701-20020101/msg00092.html The problem statement and the solution remains almost the same, with some modifications: - cleanup process is based on internal DB data, rather than object attributes or meta-attributes - "holders" of the objects to be deleted are notified n days before using standard DB notification mechanisms. 4. Further development of the database software - Improving error reporting - Improving server performance - Software portability and configuration 5. Improve database security These ideas were discussed at the RIPE-41, the detailed proposals will follow - Deprecate MAIL-FROM as a weak auth scheme that doesn't serve todays's security requirements. This will be done in several phases starting form not allowing updating mntner objects containing this scheme, and ending with not allowing updates to be authorised with MAIL-FROM. - Implement authentication scheme using MD5 as a more secure mechanism compared to crypt. Passphrases can be used instead of 8 character passwords and MD5 fingerprint will be presented in the auth value. - Implement inverse queries on auth, encryption, signature for PGP keys only (key-cert's).

4 4

Re: Database development plans
by Wilfried Woeber, UniVie/ACOnet 30 Jan '02

30 Jan '02

> In regards to the MD5 fingerprint, would this be a straight MD5 hash, or >something like the FreeBSD MD5-based password hash (which I believe supports >passwords longer than 8 chars)? I would certainly expect support for more than 8 characters, like in newer versions of Linux. >Also, would the hash continue to be openly published? I guess so. Hiding something in the response (by default) has the potential of confusing people while trying to update and/or delete objects. We've been through that already ;-) >It would seem you would still have to deal with potential dictionary attacks. Correct. >I understand the Perl-based RIPE server would use a "*" in place of >the actual crypt-pw and I've been considering adding support for this in IRRd. >Also, I would suggest reading the following paper regarding the strength >of traditional Unix crypt, FreeBSD's MD5-based crypt, and OpenBSD's Blowfish- >based bcrypt -- http://www.usenix.org/events/usenix99/provos.html Thanks for the pointer! > Regards, > Larry Blunk > Merit Regards, Wilfried.

2 1

Draft minutes RIPE41 DB WG (this time with attachment)
by Nigel Titley 17 Jan '02

17 Jan '02

This time with the minutes attached Nigel --

1 0

Draft minutes of RIPE-41 DB WG
by Nigel Titley 17 Jan '02

17 Jan '02

Folks, Please find attached the minutes of the DB WG from RIPE41. This is a first draft. If you spot mistakes or errors then please let me know and I will re-issue a corrected copy. Best regards Nigel --

1 0

draft agenda (v2), for DB-WG meeting, RIPE 41, Amsterdam
by Wilfried Woeber, UniVie/ACOnet 16 Jan '02

16 Jan '02

Dear WG list members, attached please find the 2nd draft: Proposed Agenda for the DB-WG Meeting at RIPE #41 in Amsterdam, NL. There is a new item on the draft agenda: DataBase documentation for the "average" user Looking forward to see many of you in Amsterdam a few days from now, Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting RIPE-41, Jan. 14-18 2002, Amsterdam, NL 1. Draft Thursday, Jan 17th, 2002 09:00-12:30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A. Administrative stuff (WW, chair) . volunteering a scribe . circulate list of participants . agenda bashing . status of minutes B. Actions Items . status of actions C. DB update (RIPE NCC, Andrei R.) 10 min . operations report D. DB software developments (RIPE NCC, N.N.) 30 min . bug fixes, re-writes, platform compatibility . meta-data proposal E. DB consistency and Statistics project (RIPE NCC, N.N.) 15 min F. IRT object implementation (RIPE NCC, N.N.) 15 min . implementation report, last-minute adjustments . how to use and promote the new features? G. Universal Whois Project (Andrew Newton, VeriSign App. Res.) 30 min . Needs of addressing information as it relates to domains in whois. . Overview of two technical solutions. . Unification of the addressing and domain databases into a more coherent "strategy". H. DataBase documentation for the "average" user 15 min . requested by Ruediger Volk . problem statement . how to proceed? (task-force to create requirements?) . other approaches to limit confusion at the consumers' end? I. Modification of changed: attribute (tenative) J. "organisation:" Object re-visited (tentative) Y. Input from other WGs . Z. AOB: . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 16-JAN-2002 13:44:46 _________________________________:_____________________________________ 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

MInutes of DB WG from RIPE 40
by Nigel Titley 16 Jan '02

16 Jan '02

Folks, After a short but vicious battle with the RIPE major domo, I enclose a copy of the DB wg minutes from RIPE 40. Apologies for the delay. The minutes were in fact sent to the list immediately after the RIPE 40 wg meeting but because I sent them from the wrong address, the list manager silently dropped them (I think). Anyway, read and enjoy. Nigel --

1 0

Announcement - Database Consistency and Statistics Project
by Can Bican 14 Jan '02

14 Jan '02

Dear Colleagues, [Apologies for multiple messages]. The new version of database consistency project, along with whois server usage statistics have been released on the RIPE NCC's web pages, with the following url: http://www.ripe.net/db/dbconstat/ The goal of this project is to find the objects with consistencies not enforced by the database, and provide reports and statistics to help users correct them. It also aims at checking for the necessary protection of objects and tracing the query and update statistics of the RIPE whois server to analyze the current trends of using the database. The goals of the consistency project do not include, for example, reality checks for inetnum objects, but it addresses only internal inconsistencies in the database, such as invalid references. Here are the types of inconsistencies which are addressed in this project: * Inetnum object related: * Inetnum objects without status attribute, * Assigned inetnum objects without allocations, * Overlapping inetnum objects, * Inetnum objects with suspicious boundaries to form a network, * Assigned inetnum objects from assignments, * Inetnum objects with wrong PA or PI status, * Wrongly allocated inetnum objects. * Person object related: * Person objects with multiple identical copies, * Person objects which do not have any references to them, * Person objects not having a valid nic-handle, * Objects which have references to invalid nic-handles. * Maintainer object related: * Maintainer objects which do not have any references to them. * Protection related: * Weak authentications schemes for maintainers. * Inetnum objects with no mnt-lower attribute. Reports about individual inconsistencies are sent only to the maintainers of objects. If you'd like to receive the report for your inconsistencies, send an e-mail to auto-dbcon(a)ripe.net containing the maintainer name in its body, and the appropriate authentication. * If the authentication of your maintainer is MAIL-FROM, mail should be sent from the appropriate e-mail address, and should contain the following in its body: mntner: <maintainer_name> * If the authentication of your maintainer is CRYPT-PW, mail should contain the following lines in its body: mntner: <maintainer_name> password: <password> * If the authentication of your maintainer is PGPKEY, mail should contain the following line and should be signed with the appropriate key: mntner: <maintainer_name> If you supply an existing maintainer and the proper authentication, the report of the inconsistencies related to the maintainer will be mailed back to you. For questions, comments and suggestions, please contact ripe-dbm(a)ripe.net. -- Can Bican RIPE NCC

1 1

Draft Minutes from RIPE-40
by Nigel Titley 14 Jan '02

14 Jan '02

Folks, Looking back on the mailing list, I couldn't see that the minutes had been published from the last meeting. My apologies for this, and please find them attached. Nigel --

1 0

Announcement - Database Consistency and Statistics Project
by Can Bican 14 Jan '02

14 Jan '02

Dear Colleagues, [Apologies for multiple messages]. The new version of database consistency project, along with whois server usage statistics have been released on the RIPE NCC's web pages, with the following url: http://www.ripe.net/db/dbconstat/ The goal of this project is to find the objects with consistencies not enforced by the database, and provide reports and statistics to help users correct them. It also aims at checking for the necessary protection of objects and tracing the query and update statistics of the RIPE whois server to analyze the current trends of using the database. The goals of the consistency project do not include, for example, reality checks for inetnum objects, but it addresses only internal inconsistencies in the database, such as invalid references. Here are the types of inconsistencies which are addressed in this project: * Inetnum object related: * Inetnum objects without status attribute, * Assigned inetnum objects without allocations, * Overlapping inetnum objects, * Inetnum objects with suspicious boundaries to form a network, * Assigned inetnum objects from assignments, * Inetnum objects with wrong PA or PI status, * Wrongly allocated inetnum objects. * Person object related: * Person objects with multiple identical copies, * Person objects which do not have any references to them, * Person objects not having a valid nic-handle, * Objects which have references to invalid nic-handles. * Maintainer object related: * Maintainer objects which do not have any references to them. * Protection related: * Weak authentications schemes for maintainers. * Inetnum objects with no mnt-lower attribute. Reports about individual inconsistencies are sent only to the maintainers of objects. If you'd like to receive the report for your inconsistencies, send an e-mail to auto-dbcon(a)ripe.net containing the maintainer name in its body, and the appropriate authentication. * If the authentication of your maintainer is MAIL-FROM, mail should be sent from the appropriate e-mail address, and should contain the following in its body: mntner: <maintainer_name> * If the authentication of your maintainer is CRYPT-PW, mail should contain the following lines in its body: mntner: <maintainer_name> password: <password> * If the authentication of your maintainer is PGPKEY, mail should contain the following line and should be signed with the appropriate key: mntner: <maintainer_name> If you supply an existing maintainer and the proper authentication, the report of the inconsistencies related to the maintainer will be mailed back to you. For questions, comments and suggestions, please contact ripe-dbm(a)ripe.net. -- Can Bican RIPE NCC

1 0

Some RIPE Database updates were processed twice
by Andrei Robachevsky 14 Jan '02

14 Jan '02

Dear Colleagues, Due to misconfiguration of our main whois server some 300 updates were not processed correctly. We needed to rollback the database and process them again. Those affected may receive acknowledgement and notifications from the RIPE Database twice. In such case please ignore the first message. The service now is back to normal. We are very sorry for the inconvenience. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

3 3

draft agenda (v1), for DB-WG meeting, RIPE 41, Amsterdam
by Wilfried Woeber, UniVie/ACOnet 13 Jan '02

13 Jan '02

Dear WG list members, attached please find the 1st (initial) draft: Proposed Agenda for the DB-WG Meeting at RIPE #41 in Amsterdam, NL. Please expect some minor changes/adjustments/re-sequencing closer to the meeting date. Looking forward to see many of you in Amsterdam a few days from now, Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting RIPE-41, Jan. 14-18 2002, Amsterdam, NL 1. Draft Thursday, Jan 17th, 2002 09:00-12:30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A. Administrative stuff (WW, chair) . volunteering a scribe . circulate list of participants . agenda bashing . status of minutes B. Actions Items . status of actions C. DB update (RIPE NCC, Andrei R.) 10 min . operations report D. DB software developments (RIPE NCC, N.N.) 30 min . bug fixes, re-writes, platform compatibility . meta-data proposal E. DB consistency and Statistics project (RIPE NCC, N.N.) 15 min F. IRT object implementation (RIPE NCC, N.N.) 15 min . implementation report, last-minute adjustments . how to use and promote the new features? G. Universal Whois Project (Andrew Newton, VeriSign App. Res.) 30 min . Needs of addressing information as it relates to domains in whois. . Overview of two technical solutions. . Unification of the addressing and domain databases into a more coherent "strategy". H. Modification of changed: attribute (tenative) I. "organisation:" Object re-visited (tentative) Y. Input from other WGs . Z. AOB: . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 13-JAN-2002 15:03:34 _________________________________:_____________________________________ 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

Routing Registry BOF at Miami NANOG (Feb 11)
by Larry J. Blunk 11 Jan '02

11 Jan '02

Merit will be hosting a Routing Registry BOF at the next NANOG meeting in Miami on Feb 11. Details on the meeting can be found at http://www.nanog.org/mtg-0202/. We also welcome any presentation proposals from interested parties. Regards, Larry J. Blunk Lead Engineer - Merit RADB project

1 0

IRT object
by Andrei Robachevsky 11 Jan '02

11 Jan '02

Dear Colleagues, The irt object has been implemented and we put the new software on our test whois server (please see http://www.ripe.net/ripencc/pub-services/db/testdb.html). We also took liberty to make some modifications to the original proposal (http://www.ripe.net/ripe/mail-archives/db-wg/20010701-20020101/msg00036.html). Namely: - an "irt-nfy:" attribute is now optional/multiple/inevrse key in the irt object. It specifies an e-mail address used to send notifications whenever a reference to the object is added or removed. We thought it would be very useful from security prospective. - a name of an irt object should start with "IRT-" prefix reserved for this type of object. This will eliminate possible confusion, such as mixing up with mntner. We have created some object to play with: irt: IRT-TEST inetnum: 172.18.0.0 - 172.25.255.255 So you may try: $ whois -h test-whois IRT-TEST $ whois -h test-whois -i mnt-irt IRT-TEST $ whois -h test-whois -i irt-nfy bitbucket(a)ripe.net $ whois -h test-whois 172.18.10.1 $ whois -h test-whois -c 172.18.10.1 The irt objects are not created automatically, but are forwarded to RIPE Database Administration (ripe-dbm(a)ripe.net). But this restriction does not apply to the TEST database, so you may try to create one yourself. Have a nice weekend, Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

Status of IRT object
by Gabriella Paolini 07 Jan '02

07 Jan '02

Dear all, which is the status of IRT object? Is the trial implementation available? This example shows again the need for a specific object. If someone uses whois information from cyberabuse.org, as many times people does, that information is wrong, because ciberabuse guys used Admin-c email without considering all other informations in inetnum object and in role object. Thanks and regards, Gabriella Paolini INFN-GARR [ Informations about 193.204.17.211 ] IP range : 193.204.16.0 - 193.204.23.255 Network name : UNIBAS-NET AS number : AS137 Infos : Universita' Degli Studi Di Basilicata Infos : Centro Interfacolta' Servizi Informatici E Telematici - Cisit Phone number : +39 06 49914352 Country : IT Abuse contact : enzo.valente(a)infn.it Source : RIPE right information are inetnum: 193.204.16.0 - 193.204.23.255 netname: UNIBAS-NET descr: Universita' degli Studi di Basilicata descr: Centro Interfacolta' Servizi Informatici e Telematici - CISIT country: IT admin-c: EV182-RIPE tech-c: GL965-RIPE tech-c: GM976-RIPE ... remarks: To notify abuse mailto: cert(a)garr.it remarks: Multiple lan of university departments remarks: GARR - Italian academic and research network mnt-by: GARR-LIR ... role: GARR LIR ... trouble: To notify abuse mailto: cert(a)garr.it trouble: Information at http://www.lir.garr.it/ ... person: Enzo Valente address: INFN - Dipartimento di Fisica address: Universita' La Sapienza address: Piazzale Aldo Moro,2 address: I-00185 Roma address: Italy phone: +39 06 49914352 fax-no: +39 06 4957697 e-mail: Enzo.Valente(a)infn.it ...

4 3

RIPE robot response
by Antonia López 04 Jan '02

04 Jan '02

Dear all, Every time I update or add an object to the RIPE database, the robot give back an e-mail like that (although I send my e-mail with non formatted text). <<FAILED: >> The action is made, then why this e-mail?? Thanks. Antonia Lopez Serrano

3 2

RE: RIPE robot response
by Boyan Krosnov 04 Jan '02

04 Jan '02

You sent a mime message with two parts part one is text/html the other is text/plain. The robot cannot parse html so it sees it as plain text and tries to process it. It then fails, as could be expected. Then it processes the text/plain part of your message, which succeedes. Never send html formated messages to the robot or it will spit errors at you. If you are using a MS exchange server you can make it send messages to all addresses @ripe.net in plain text format. Drop me a private e-mail for the exact configuration. Regards, CCNP Boyan Krosnov Network Administrator Lirex Net phone: +359-2-91815 -----Original Message----- From: Antonia Lopez [mailto:antonia.lopez@abrared.com] Sent: Friday, January 04, 2002 6:18 PM To: 'db-wg(a)ripe.net' Subject: RIPE robot response Dear all, Every time I update or add an object to the RIPE database, the robot give back an e-mail like that (although I send my e-mail with non formatted text). <<FAILED: >> The action is made, then why this e-mail?? Thanks. Antonia Lopez Serrano

1 0

Re: RIPE robot response
by Janos Zsako 04 Jan '02

04 Jan '02

> From owner-db-wg(a)ripe.net Fri Jan 4 16:35:03 2002 > From: =?iso-8859-1?Q?Antonia_L=F3pez?= <antonia.lopez(a)abrared.com> Dear Antonia, This is probably because your mailer is cofigured to send the message BOTH in plaintext AND HTML (see below). The plaintext is interpreted correctly by the robot, while the HTML text is flaged with errors. Also, please note that you should change your password, as you forwarded it in cleartext to the list... :(( Best regards, Janos > Content-Type: multipart/alternative; > Content-Type: text/plain; > Dear all, > > Every time I update or add an object to the RIPE database, the robot give > back an e-mail like that (although I send my e-mail with non formatted > text). > > <<FAILED: >> > > The action is made, then why this e-mail?? > Content-Type: text/html; > Dear all, > > > Every time I update or add an object = > to the RIPE database, the robot give back an e-mail like that (although = > I send my e-mail with non formatted text).

1 0