nishri@gpu.utcs.utoronto.ca (Alex Nishri) (12/06/90)
In article <F4E2A21B59FF0056F3@rulsur.LeidenUniv.nl> Fund@RELAY.PROTEON.COM writes in part: > No, Econfiging. Yes it is real SMTP. As long as you have it running on > your other platforms (VAX, SUN, IBM, etc.) you have connectivity. > > The SMTP gateway has an entry in the cc:Mail user database. You send to > that PO and specify the name and domain that you want to get to. cc:Mail > then exports and configures the message, then sends it out over the net. > It is transparent to the users. > > It is not to bad to set up either. Give yourself 4 hours, and you will have > the whole thing understood... > > Since the gateway entry is in the master listing, everyone does have the > option of selecting it. I do not know of any way of restricting access. Like most other Universities we keep trying every few months to find a vendor supported PC e-mail package with a working SMTP gateway. A few months have passed since our last attempt and we are currently evaluating any and all SMTP gateways we can get our hands on. Our decision on which Novell e-mail package we decide to standardize on hangs in the balance. Unfortunately most SMTP gateways we have heard about are either vaporware or "in alpha" or "beta". Cc:Mail's gateway is an exception. One week after we phoned to ask for an evaluation copy we had it in our hands. We have not yet sucessfully gotten it to work, but based on the documentation we already have some reservations. Among the less serious reservations are that Cc:Mail text messages can contain only up to twenty thousand characters; rfc822/rfc1123 specify that "Mailer software MUST be able to send and receive messages at least 64K in length (including headers) ...". A more serious reservation has to do with how someone on the Internet side would address someone using cc:Mail. cc:Mail's userids consist of a very reasonable and user friendly lastname/firstname combination. However, the cc:Mail SMTP gateway only supports eight character local-parts in an rfc822 address. (The local-part of an rfc822 address is the portion before the at sign; on some systems this is also called a userid.) For example, if your Cc:Mail address was "Monica Ackermann", your internet address would have to be an address of the form mackerma@domain. This is hardly user friendly; supporting Monica.Ackermann@domain or Monica_Ackermann@domain or MAckermann@domain would all have been better. As well, the gateway has its own directory, seperate from cc:Mail's, to map the eight character rfc822 addresses to cc:Mail addresses; although there is a tool to help import cc:Mail directories, this is one more directory for the administrator to worry about; having a default mapping (eg map the cc:Mail firstname/lastname to firstname.lastname@domain) for cc:Mail users not in the SMTP directory would simplify things. The most serious reservation we have found at this point is that the documentation implies that the SMTP receiver doesn't listen for connections at all times. Instead, the SMTP receiver comes up for ten (or some administrator settable) minutes and then goes away while mail is exchanged with cc:Mail and the SMTP sender is run. (Seperate programs for SMTP receiving, SMTP sending, and exchanging mail with cc:Mail are run one at a time.) Unfortunately, if an Internet SMTP mailer tries to send mail to your cc:Mail SMTP gateway during the period your SMTP receiver is not running, it won't be able to get through. Internet mailers sending to your cc:Mail SMTP gateway will assume you are down. Usually they will try again some time later; however, there is a finite chance your SMTP receiver isn't running on the next attempt. After a few tries most Internet mailers will then assume the address is unreachable. I can understand the problem of implementing an SMTP receiver that runs concurrently with an SMTP sender and concurrently with communication with the rest of cc:Mail. After all, the cc:Mail SMTP gateway runs under PC-DOS which provides no multitasking or concurrency support. However, there are many fine examples of programs running under PC-DOS that accomplish this kind of concurrency. For example, the Phil Karn's KA9Q package runs IP, TCP, Telnet(client&server) FTP(client&server), and SMTP(receiver&sender) concurrently under PC-DOS. (Anyone out there looked at writing a Novell/MHS gateway for KA9Q? :-) We are also worried about pricing. Our campus network uses TCP/IP and we have no intention of running proprietary protocols across campus. Hence each department running a Novell departmental LAN would also run its own SMTP gateway. At CDN$3000.00 per gateway times fifty or so departments this begins to add up. Not wanting to sound too negative, I applaud cc:Mail for having a real product and for the excellent support they have given us. (One company, when told we were interested in evaluating their SMTP gateway, told us they were too busy to talk to us; we are a University with over fifty thousand students.) The cc:Mail gateway does show promise and we are continuing to evaluate it. We are also interested in exchanging information with others either running or evaluating SMTP gateways to Novell e-mail packages. We have two people actively pursuing these issues here. Monica Ackermann<ackerman@utcs.utoronto.ca>, who is an expert in human-computer interfaces, is looking at the user interfaces of leading packages. And Glenn Britton<britton@utcs.utoronto.ca>, our e-mail support person, is chasing up the gateway issues. Alex Nishri University of Toronto Computing Services email: nishri@utcs.utoronto.ca