Re: Mailbox format how-to

2004-11-08 Thread Chris Ross
Mark Crispin wrote:
dmail is built as part of the IMAP toolkit, so its behavior will be 
affected by the change to CREATEPROTO.
  Right.  I knew that.  I was just looking for a way to do it without
compiling it in as the "default" format.  Tho, I'm not sure there's
a problem with doing that.
It's messier than that; there are some security issues as well.  The -I 
flag in tmail could be abused for some truly nasty purposes if it was 
allowed for non-privileged calls.
  Right.  But if there were a "format" command-line arg that doesn't
also specify the filename, that issue goes away.  That was my point
for having a format arg that wasn't -I.
"mailutil create #driver.mbx/foo" will create an empty file named foo 
which you can then copy to "INBOX" in the home directory of all the 
users you want to convert to mbx.
  Cool.  Thanks...  I need to look at mailutil s'more.  I've looked
at mbx* tools, but they're confusing.  Maybe I shouldn't be looking
at those.  :-)
By the way, you do know that you can't use mbx format with NFS, don't you?
  Yup.  I'm all on local filesystems here.
- Chris


Re: Mailbox format how-to

2004-11-08 Thread Mark Crispin
On Mon, 8 Nov 2004, Chris Ross wrote:
CREATEPROTO=mbxproto
 Yeah, I knew about that method.  I was just wondering if there
was a way to make dmail (from procmailrc, for example) know to
instantiate new mail folders as mbx instead of mbox.
dmail is built as part of the IMAP toolkit, so its behavior will be 
affected by the change to CREATEPROTO.

It seems not
unreasonable to have command-line args for tmail/dmail (other than
-I) that could specify format.  But, what to do in the case that
it doesn't match existing format might be an issue.
It's messier than that; there are some security issues as well.  The -I 
flag in tmail could be abused for some truly nasty purposes if it was 
allowed for non-privileged calls.

 Okay.  How would you recommend creating this empty mbx mailbox?
"mailutil create #driver.mbx/foo" will create an empty file named foo 
which you can then copy to "INBOX" in the home directory of all the users 
you want to convert to mbx.

By the way, you do know that you can't use mbx format with NFS, don't you?
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.


Re: Mailbox format how-to

2004-11-08 Thread Mark Crispin
On Mon, 8 Nov 2004, Erik Kangas wrote:
#!/bin/bash
if [ ! -e "$HOME/$1" ] && [ $1 != ".inbox" ]; then
  /usr/local/bin/mbxcreat "#driver.mbx:$1"
fi
/usr/local/bin/dmail "+$1"
I recommend using "mailutil create" instead of "mbxcreat" since the latter 
program is no longer supported.

We didn't find any easier way to accomplish this for arbitrary folders; it 
would be nice if dmail could do this itself.
I'm not sure that I understand.  dmail never creates a non-INBOX mailbox; 
if the destination mailbox does not exist then dmail will deliver to 
INBOX.

Do you mean "convert mailbox format"?  If so, mailutil can be used to 
convert, albeit to a different name.

-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.


Re: Mailbox format how-to

2004-11-08 Thread Erik Kangas
Chris Ross wrote:
Mark Crispin wrote:
The easiest way to do this is to edit file
imap-200?/src/osdep/unix/Makefile
to set
CREATEPROTO=mbxproto
instead of the current unixproto.  Then rebuild the entire UW IMAP 
toolkit.

  Yeah, I knew about that method.  I was just wondering if there
was a way to make dmail (from procmailrc, for example) know to
instantiate new mail folders as mbx instead of mbox.  It seems not
unreasonable to have command-line args for tmail/dmail (other than
-I) that could specify format.  But, what to do in the case that
it doesn't match existing format might be an issue.
You could do this with a little shell script, something like 
"dmail-create.sh" we use:

#!/bin/bash
if [ ! -e "$HOME/$1" ] && [ $1 != ".inbox" ]; then
   /usr/local/bin/mbxcreat "#driver.mbx:$1"
fi
/usr/local/bin/dmail "+$1"
Where this script takes 1 command line argument - the path of the folder in 
which you want to save the message, relative to the user's home directory. 
".inbox" is supposed to be in unix format so sendmail can deliver to it 
directly "if all else fails", hence the exception.

Then, in your .procmailrc scripts, instead of delivering to dmail, you 
deliver to dmail-create.sh.  I.e.

LOCK=.lock.user.id
:0 :${LOCK}
| /usr/local/bin/dmail-create.sh INBOX
This way, the folder will be created in MBX format if it doesn't exist before 
dmail tries to save the message.

We didn't find any easier way to accomplish this for arbitrary folders; it 
would be nice if dmail could do this itself.

-Erik Kangas
--
Erik Kangas, Ph.D. --- President of Lux Scientiae, Incorporated
[EMAIL PROTECTED]  --- http://luxsci.com
Office Phone:1-617-507-2162
Cell Phone:  1-617-596-9558P.O. Box 326
Luxsci Toll Free:1-800-441-6612Westwood, Massachusetts
LuxSci FAX:  1-413-332-059802090, USA


Re: Mailbox format how-to

2004-11-08 Thread Tim Mooney
In regard to: Re: Mailbox format how-to, Chris Ross said (at 5:49pm on Nov...:
Mark Crispin wrote:
The easiest way to do this is to edit file
imap-200?/src/osdep/unix/Makefile
to set
CREATEPROTO=mbxproto
instead of the current unixproto.  Then rebuild the entire UW IMAP toolkit.
 Yeah, I knew about that method.  I was just wondering if there
was a way to make dmail (from procmailrc, for example) know to
instantiate new mail folders as mbx instead of mbox.  It seems not
unreasonable to have command-line args for tmail/dmail (other than
-I) that could specify format.  But, what to do in the case that
it doesn't match existing format might be an issue.
Are you planning on doing home directory mail delivery, or delivery to
a spool directory for INBOX and other folders live under ~ or ~/mail?
However, once created, an mbx-format mailbox shouldn't vanish.  So, it 
should work just to create empty mbx-format mailboxes for everybody who 
doesn't have it.  It works to create one, and then copy it to each user 
(there isn't any user-specific in an empty mbx-format mailbox).  That way, 
you don't have to do any rebuilding.
 Okay.  How would you recommend creating this empty mbx mailbox?
mailutil create '#driver.mbx/foo' creates folder `foo' in MBX format.
Tim
--
Tim Mooney  [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building  (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


Re: Mailbox format how-to

2004-11-08 Thread Chris Ross
Mark Crispin wrote:
The easiest way to do this is to edit file
imap-200?/src/osdep/unix/Makefile
to set
CREATEPROTO=mbxproto
instead of the current unixproto.  Then rebuild the entire UW IMAP toolkit.
  Yeah, I knew about that method.  I was just wondering if there
was a way to make dmail (from procmailrc, for example) know to
instantiate new mail folders as mbx instead of mbox.  It seems not
unreasonable to have command-line args for tmail/dmail (other than
-I) that could specify format.  But, what to do in the case that
it doesn't match existing format might be an issue.
However, once created, an mbx-format mailbox shouldn't vanish.  So, it 
should work just to create empty mbx-format mailboxes for everybody who 
doesn't have it.  It works to create one, and then copy it to each user 
(there isn't any user-specific in an empty mbx-format mailbox).  That 
way, you don't have to do any rebuilding.
  Okay.  How would you recommend creating this empty mbx mailbox?
It would be a bit of a pain to make sure to create a spool mbx file
for any new user I want to receive mail from, but not the worst
problem.  Most other folder creations will be done through IMAPd,
tho, so may still require the above.  So...
 - Chris


Re: Mailbox format how-to

2004-11-08 Thread Mark Crispin
On Mon, 8 Nov 2004, Chris Ross wrote:
 - modify sendmail.cf (and friends: submit.cf?) to call tmail instead
of mail.local.  The tmail man page has a little info on this.
 - Modify by calls in my procmailrc to use dmail instead of just
specifying the mailbox name (i thing.  this right?)
So far, so good.
 So, is there any way to tell tmail to deliver to an mbx format
"main mail spool" if the file doesn't already exist?  I know if
it exists, it'll deliver in the correct format, but what if it
vanishes?
The easiest way to do this is to edit file
	imap-200?/src/osdep/unix/Makefile
to set
	CREATEPROTO=mbxproto
instead of the current unixproto.  Then rebuild the entire UW IMAP 
toolkit.

However, once created, an mbx-format mailbox shouldn't vanish.  So, it 
should work just to create empty mbx-format mailboxes for everybody who 
doesn't have it.  It works to create one, and then copy it to each user 
(there isn't any user-specific in an empty mbx-format mailbox).  That way, 
you don't have to do any rebuilding.

-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.


Mailbox format how-to

2004-11-08 Thread Chris Ross
  Hello there.  I am investigating converting my mail server to using
MBX format (vs. mbox) for everything.  Using tmail for delivery (via
sendmail 8.12), and uw-imap 2004 for access to INBOX and personal folders.
  So, my question is this.  Is there some sort of how-to for building
a system?  I know I need to:
  - modify sendmail.cf (and friends: submit.cf?) to call tmail instead
of mail.local.  The tmail man page has a little info on this.
  - Modify by calls in my procmailrc to use dmail instead of just
specifying the mailbox name (i thing.  this right?)
  So, is there any way to tell tmail to deliver to an mbx format
"main mail spool" if the file doesn't already exist?  I know if
it exists, it'll deliver in the correct format, but what if it
vanishes?
  How hard is it to modify procmailrc's to use dmail?
  A single source of information would be nice, if there was one.
Right now there seem to be a small number of sources of info
for different parts of it, so I thought I'd ask.
  Thanks!
  - Chris
--
--
For information about this mailing list, and its archives, see: 
http://www.washington.edu/imap/c-client-list.html
--


Re: mailbox format

2004-11-06 Thread Mark Crispin
On Sun, 7 Nov 2004, Akmal Khodjanov wrote:
I was wondering if there is any c-client driver to treat mail messages
as separate files. I would like to fetch mail messages from a mail
server and save them in separate files each.
The closest would be either mx or mh format.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.


mailbox format

2004-11-06 Thread Akmal Khodjanov
Hello list,

I was wondering if there is any c-client driver to treat mail messages
as separate files. I would like to fetch mail messages from a mail
server and save them in separate files each.

Thanks.

-akmal.

-- 
Best regards,
 Akmal  mailto:[EMAIL PROTECTED]
---
"Classical physics has been superseded by quantum theory: quantum
theory is verified by experiments. Experiments must be
described in terms of classical physics."
— C. F. von Weizsa"cker (1912- ), German physicist and philosopher.

-- 
--
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
--


Re: mailbox format problems

2003-12-10 Thread Mark Crispin
The only thing that you need to do to avoid creating files in traditional
UNIX format is to change CREATEPROTO.

By setting EMPTYPROTO to mbx, you introduce a bug into imapd.  Empty files
can not be in mbx format, so what will happen is that you'll get an
obscure error message (such as "indeterminate mailbox format").

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.


Re: mailbox format problems

2003-12-10 Thread Nick Hodulik
I do this not because it actually _does_ anything but because I don't want
any trace of mbox anywhere on my system. I also delete all traces of "mbox"
from the driver list. Just because it is meaningless does not mean it's
wrong, AFAIK. What would be wrong for me would be creating an mbox mailbox.
We had so many problems with mbox at my last large installation of UW-IMAP
that I want it nowhere near my servers.

>From what I can tell setting EMPTYPROTO to mbx is in fact meaningless but
won't hurt anything and will achieve my goal of removing mbox. I've run it
for four years or so with no ill effects. Someone care to comment?

n
- Original Message - 
From: "David B Funk" <[EMAIL PROTECTED]>
To: "Nick Hodulik" <[EMAIL PROTECTED]>
Cc: "Sebastian Hagedorn" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Tuesday, December 09, 2003 10:36 PM
Subject: Re: mailbox format problems


> On Tue, 9 Dec 2003, Nick Hodulik wrote:
>
> > There is a way. You have to dig down into the code and change
"CREATEPROTO"
> > and "EMPTYPROTO" from mbox to mbx. Assuming your in *nix you'll have to
go
> > to src/osdep/unix/env_unix.c or something similar to do this. If you
want
> > mail to live in a subdirectory called "mail" in each users home dir then
you
> > must change src/osdep/unix/Makefile to reflect this as well.
>
> Before you tell people to do this, you might want to go read the
> documentation to find out why setting EMPTYPROTO to "mbx" is meaningless
> and wrong.
>
> Dave
>
> -- 
> Dave Funk  University of Iowa
> College of Engineering
> 319/335-5751   FAX: 319/384-0549   1256 Seamans Center
> Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
> #include 
> Better is not better, 'standard' is better. B{
>
>




Re: mailbox format problems

2003-12-09 Thread David B Funk
On Tue, 9 Dec 2003, Nick Hodulik wrote:

> There is a way. You have to dig down into the code and change "CREATEPROTO"
> and "EMPTYPROTO" from mbox to mbx. Assuming your in *nix you'll have to go
> to src/osdep/unix/env_unix.c or something similar to do this. If you want
> mail to live in a subdirectory called "mail" in each users home dir then you
> must change src/osdep/unix/Makefile to reflect this as well.

Before you tell people to do this, you might want to go read the
documentation to find out why setting EMPTYPROTO to "mbx" is meaningless
and wrong.

Dave

-- 
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{



Re: mailbox format problems

2003-12-09 Thread Mark Crispin
On Tue, 9 Dec 2003, Nick Hodulik wrote:
> There is a way. You have to dig down into the code and change "CREATEPROTO"
> and "EMPTYPROTO" from mbox to mbx. Assuming your in *nix you'll have to go
> to src/osdep/unix/env_unix.c or something similar to do this.

The CREATEPROTO and EMPTYPROTO definitions are in the
src/osdep/unix/Makefile.

It is meaningless to set EMPTYPROTO to mbx.  You can do it, but it won't
accomplish anything.  It will make empty files unusable.

> If you want
> mail to live in a subdirectory called "mail" in each users home dir then you
> must change src/osdep/unix/Makefile to reflect this as well.

Now, that is in env_unix.c.

> Which brings me to a question: why can't these options be passed in to
> UW-IMAP as compile-time switches?

You most certainly can set CREATEPROTO and EMPTYPROTO as compile-time
switches.

> Every single time there's a new release I
> have to delve into the code and change these flags, and I'm sure I'm not the
> only one. It would be one thing if they were really esoteric things, but
> they aren't: they're very basic, important changes that make UW-IMAP usable
> on production servers.

How?

If you have a shell access system, then by setting the subdirectory you
are dictating to your shell users where they store their mail for use by
IMAP.  If the user runs a client that uses some other name, you've screwed
him; you've unilaterally made the decision for *all* users that one, and
only one, subdirectory name must be used.

If you don't allow shell access to the IMAP server, then may be no real
need to put mail in a subdirectory.  The whole point of a subdirectory is
to separate mail from other files that a user may have.  But if it's a
dedicated IMAP server, there shouldn't be any files.

Of course there are systems which don't neatly fit into either of the
above categories.  However -- and this point bears emphasizing -- the cost
of miscategorizing such a system is merely that the client has to have a
"prefix"  configured.  The cost of making the opposite mistake is a denial
of access to mail.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.


Re: mailbox format problems

2003-12-09 Thread Mark Crispin
On Tue, 9 Dec 2003, Imre Gergely wrote:
> and it works only _this_ way, no other way? i mean i have to create home
> dirs for each and every user whom i want to use this mbx format?

Correct.

> there's
> no way to tell imap/pop3/sendmail to use mbx directly in /var/spool/mail?

Correct.

You could hack the source, but the design of mbx format is *NOT* to use a
mail spool directory.

> another q: if i have .procmailrc, and i'm sorting my mail to ~/mail/* with
> it, how can i use dmail/tmail to put those mailboxes in mbx format? and
> will i be able to open them with imap? (ie in outlook, after subscribing
> to those folders)

procmail has a feature to pipe to a program.  The program you would use
for this purpose is dmail, not tmail.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.


Re: mailbox format problems

2003-12-09 Thread Christian Kratzer
Hi,

On Tue, 9 Dec 2003, Nick Hodulik wrote:

> There is a way. You have to dig down into the code and change "CREATEPROTO"
> and "EMPTYPROTO" from mbox to mbx. Assuming your in *nix you'll have to go
> to src/osdep/unix/env_unix.c or something similar to do this. If you want
> mail to live in a subdirectory called "mail" in each users home dir then you
> must change src/osdep/unix/Makefile to reflect this as well.
>
> Which brings me to a question: why can't these options be passed in to
> UW-IMAP as compile-time switches? Every single time there's a new release I
[snipp]

you might want to read ./docs/imaprc.txt in the uw-imap tarball.
If you are prepared to "accept the risk" :) you might find the runtime
configuration options quite helpfull.

Greetings
Christian

-- 
CK Software GmbH
Christian Kratzer, Schwarzwaldstr. 31, 71131 Jettingen
Email: [EMAIL PROTECTED]
Phone: +49 7452 889-135Open Software Solutions, Network Security
Fax:   +49 7452 889-136FreeBSD spoken here!


Re: mailbox format problems

2003-12-09 Thread Nick Hodulik
There is a way. You have to dig down into the code and change "CREATEPROTO"
and "EMPTYPROTO" from mbox to mbx. Assuming your in *nix you'll have to go
to src/osdep/unix/env_unix.c or something similar to do this. If you want
mail to live in a subdirectory called "mail" in each users home dir then you
must change src/osdep/unix/Makefile to reflect this as well.

Which brings me to a question: why can't these options be passed in to
UW-IMAP as compile-time switches? Every single time there's a new release I
have to delve into the code and change these flags, and I'm sure I'm not the
only one. It would be one thing if they were really esoteric things, but
they aren't: they're very basic, important changes that make UW-IMAP usable
on production servers.

What can be done to change this so that these things can be made much easier
to setup? I understand the goal of wanting out-of-the-box functionality but
that really shouldn't come at the expense of ease-of-use and intuitive
design. I find this frustrating, as UW-IMAP is literally the only mature
software package I use with an antiquated build system.

Mark, you tend to answer these sort of requests/constructive criticisms
tersely; I respectfully ask that you consider making these kinds of changes,
as they would benefit the entire community of users who depend on your
otherwise excellent software.

n

- Original Message - 
From: "Imre Gergely" <[EMAIL PROTECTED]>
To: "Sebastian Hagedorn" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, December 09, 2003 1:02 AM
Subject: Re: mailbox format problems


>
> On Mon, 8 Dec 2003, Sebastian Hagedorn wrote:
>
> > The mailbox in /var/spool/mail has to be in mbox format. If you want to
> > have an mbx INBOX, you need to create an mbx file named
/home/cemc/INBOX.
> > Mail will be slurped into that file from /var/spool/mail each time the
> > INBOX is accessed.
>
> ok, it works this way. thanks.
>
> and it works only _this_ way, no other way? i mean i have to create home
> dirs for each and every user whom i want to use this mbx format? there's
> no way to tell imap/pop3/sendmail to use mbx directly in /var/spool/mail?
>
> another q: if i have .procmailrc, and i'm sorting my mail to ~/mail/* with
> it, how can i use dmail/tmail to put those mailboxes in mbx format? and
> will i be able to open them with imap? (ie in outlook, after subscribing
> to those folders)
>
> -- 
> Gergely Imre   email: [EMAIL PROTECTED]
> sysadmin   mobile: +40-745-105592, office: +40-266-317500
> Nextra Tele Com SRL   str. Florilor 28/1, 4100 M-Ciuc, RO
> http://www.nextra.ro/gimre ICQ# 101510959
>
>




Re: mailbox format problems

2003-12-09 Thread Imre Gergely

On Mon, 8 Dec 2003, Sebastian Hagedorn wrote:

> The mailbox in /var/spool/mail has to be in mbox format. If you want to 
> have an mbx INBOX, you need to create an mbx file named /home/cemc/INBOX. 
> Mail will be slurped into that file from /var/spool/mail each time the 
> INBOX is accessed.

ok, it works this way. thanks.

and it works only _this_ way, no other way? i mean i have to create home 
dirs for each and every user whom i want to use this mbx format? there's 
no way to tell imap/pop3/sendmail to use mbx directly in /var/spool/mail?

another q: if i have .procmailrc, and i'm sorting my mail to ~/mail/* with 
it, how can i use dmail/tmail to put those mailboxes in mbx format? and 
will i be able to open them with imap? (ie in outlook, after subscribing 
to those folders)

-- 
Gergely Imre   email: [EMAIL PROTECTED]
sysadmin   mobile: +40-745-105592, office: +40-266-317500
Nextra Tele Com SRL   str. Florilor 28/1, 4100 M-Ciuc, RO
http://www.nextra.ro/gimre ICQ# 101510959



Re: mailbox format problems

2003-12-08 Thread Sebastian Hagedorn
--On Montag, 8. Dezember 2003 15:25 Uhr +0200 Imre Gergely 
<[EMAIL PROTECTED]> wrote:

i downloaded the imap.tar.Z, and compiled the source. then, i converted
my  unix mailbox to mbx format. there was no problem, pine could open it.
then i tried to open it through pop3:
-ERR Unable to open user's INBOX
Connection closed by foreign host.
in syslog i get the following error:
Dec  8 15:21:53 imi ipop3d[14112]: pop3 service init from 127.0.0.1
Dec  8 15:21:58 imi ipop3d[14112]: Can't open INBOX (file
/var/spool/mail/cemc): not in valid mailbox format
Dec  8 15:21:58 imi ipop3d[14112]: Error opening or locking INBOX
user=cemc host=localhost.localdomain [127.0.0.1]
when i try through imap, it says no messages. what did i do wrong?
The mailbox in /var/spool/mail has to be in mbox format. If you want to 
have an mbx INBOX, you need to create an mbx file named /home/cemc/INBOX. 
Mail will be slurped into that file from /var/spool/mail each time the 
INBOX is accessed.

Greetings, Sebastian
--
Sebastian Hagedorn  PGP key ID: 0x4D105B45
Ehrenfeldgürtel 156
50823 Köln
http://www.spinfo.uni-koeln.de/~hgd/


mailbox format problems

2003-12-08 Thread Imre Gergely

hi

i downloaded the imap.tar.Z, and compiled the source. then, i converted my 
unix mailbox to mbx format. there was no problem, pine could open it.
then i tried to open it through pop3:

-ERR Unable to open user's INBOX
Connection closed by foreign host.

in syslog i get the following error:
Dec  8 15:21:53 imi ipop3d[14112]: pop3 service init from 127.0.0.1
Dec  8 15:21:58 imi ipop3d[14112]: Can't open INBOX (file 
/var/spool/mail/cemc): not in valid mailbox format
Dec  8 15:21:58 imi ipop3d[14112]: Error opening or locking INBOX 
user=cemc host=localhost.localdomain [127.0.0.1]

when i try through imap, it says no messages. what did i do wrong?

[EMAIL PROTECTED] root]# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 2731 (Red Hat Linux 7.3 2.96-113)

imap and pop3 runs through xinetd.
thx.

-- 
Gergely Imre   email: [EMAIL PROTECTED]
sysadmin   mobile: +40-745-105592, office: +40-266-317500
Nextra Tele Com SRL   str. Florilor 28/1, 4100 M-Ciuc, RO
http://www.nextra.ro/gimre ICQ# 101510959

-- 
--
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
--