HDTenEightyP/NetNews huggingface dataset:
From: bob@camb.com (Bob Tinkelman)
Newsgroups: vmsnet.mail.pmdf
Subject: PMDF-FAX installation and [ghostscript]fontmap.
Date: 21 Aug 92 01:10:08 GMT
Organization: Cambridge Computer Associates, Inc.
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 20 Aug 1992 21:10:08 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNTB2XAAO294E2RM@INNOSOFT.COM>
X-Vms-To: IN%INFO-PMDF
X-Vms-Cc: TINKELMAN
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

I have an edited version of the fontmap file to support additional
fonts purchased from Adobe.  When I install PMDF-FAX I need to remember
to keep a renamed version of this file because PMDF-FAX replaces my
exisiting version, and purges the old one (because that's the option
I selected).  [Clearly I'm writing this mail because I've forgotten
to do that, yet another time.]

I understand that you wouldn't want to have the install just leave a
fontmap.sample file around, because it might be that the fontmap that
worked for one version of PMDF-FAX won't work for the next.  But maybe
you could rename the existing fontmap to fontmap.previous_version, or
something like that.  *And*, maybe it could output a message when it's
done so, just to remind forgetful people like me.

Does this sound like a reasonable thing to do?
From: ned@sigurd.innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: question
Date: 18 Aug 92 23:59:07 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 18 Aug 1992 16:59:07 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNRIT10BB695NOFN@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"wdw3@cunixb.cc.columbia.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Sure -- anyone on the Internet can send to .BITNET addresses. It is very
easy; you just use something like:

    user%host.bitnet@cunyvm.cuny.edu

The gateway host cunyvm.cuny.edu is just one of several possibilities.

The PMDF configuration procedure automatically generated a .BITNET rule
for hosts that aren't on BITNET directly, so you can actually type in

    user@host.bitnet


on a properly configured PMDF system that's only on the Internet and the
address will be handled properly. The rewrite rule is something like:

    .bitnet                  $U@$H.BITNET@cunyvm.cuny.edu@MTCP-DAEMON

This will vary depending on the TCP/IP implementation you use.

				Ned
From: ned@sigurd.innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: pmdf-mr
Date: 21 Aug 92 20:00:48 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 21 Aug 1992 13:00:48 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNUEYJSVU495NWHR@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"WEAVER@sheridanc.on.ca"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> One of the questions asked during the configuration of pmdf-mr
> is:  Convert WPS-PLUS to ASCII ?  I chose NO because I had already
> answered yes to a similar question from the installation of V3.0 of
> ALLIN1.  The question was "do you want outgoing WPS-PLUS docs converted
> to ASCII?

> I assumed that it is the same function, but if so why does PMDF offer
> it if ALLIN1 already does it.

The problem is that ALL-IN-1 does not always do it and cannot always do it.
Consider the following scenario -- you have a dozen systems running ALL-IN-1
connected by Message Router. These systems happily exchange messages in
WPS-Plus format. If they had chosen to convert all messages to ASCII before
sending them the general utility of the setup would be very severely
compromised.

Now you add PMDF-MR to this scheme. The ALL-IN-1 systems have no way of knowing
if they are sending to another ALL-IN-1, PMDF-MR, or (worst case) both at once.
You are now asking them to severely mangle their existing document exchange
capabilities for the sake of one added gateway.

> Is this one of those cases where it isn't getting done quite right
> and I should be letting PMDF do the converts?  :-)

See the documentation -- the converter we use is cobbled together out of the
libraries that ship with MRGATE. These libraries offer exactly the same
(very limited) functionality you get with ALL-IN-1. This is unfortunate
since I'd prefer to convert to/from richtext. The WPS-Plus format is totally
undocumented, however, so there's no way to do this.

In any case, the only reason why you might not want to have PMDF do  this
conversion is when the remote sites you're contacting via PMDF also have
PMDF-MR and ALL-IN-1. In other words, you want to exchange WPS-PLus across the
Internet. This is a rather nasty concept but it is one people use and we do
support it.

				Ned
From: dan@innosoft.com (Daniel C. Newman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Mail delivery stopped
Date: 21 Aug 92 20:19:12 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 21 Aug 1992 12:19:12 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNUEQ6BZQQ95NWHR@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"MIKE%UCDHEP.BITNET@ymir.claremont.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> I noticed yesterday that I had very few network mail messages, considering all
> the mailing lists I'm on.  Also, one of our users complained that he had not
> received Internet mail that he sent to himself from an outside site.  At that
> time the VAX had been up for about 153 days, so I figured that this was no big
> deal.  I.e., s**t happens, very large buffers eventually fill up, etc., etc.
> So I rebooted the VAX, expecting to clear up the problem.  The reboot didn't
> help.
>
> I have been receiving and sending Internet, Bitnet, and HEPnet mail on a daily
> basis from and to sites all over the world, so I had no reason to expect
> problems with PMDF.  But I noticed that PMDF_ROOT:[QUEUE.L] had over 1700 files
> in it, so I executed the command:
>
>                         $ @pmdf_root:[exe]master L
>
> This caused me to get hundreds of mail messages, some dated as long ago as May
> of this year.  Apparently a large number of messages also went out over the net.

At some point you lost the periodic and return jobs from your MAIL$BATCH queue.
You should check this from time to time.

> I continued to test, and messages did not get delivered unless I executed
> MASTER.COM by hand.

Sounds like the immediate delivery jobs for PMDF are dying for some reason.
I suggest you check the log files.  If there are no log files, then you'll
have to look at the system accounting records and see what the "final status
code" is for the batch jobs.

>  I then did:
>
>                         $ @sys$startup:pmdf_submit_jobs
>
> This caused messages to be processed, but only at the default time interval of
> four hours.  I now have this job run automatically every half hour, by setting
> the logical name PMDF_POST_INTERVAL to 00:30:00.  This is tolerable, I guess,
> but I'm pretty sure I didn't do that before.

This further confirms that something is causing the immediate delivery jobs to
fail.  Have you also checked the version numbers for the L_MASTER.LOG and
other log files?  It could be that it has reached 32,767.

Note that PMDF V4.1 is a lot more robust about dealing with version number
problems.

Dan
From: dmpm%dukemc.bitnet@ymir.claremont.edu (James Dryfoos - Postmaster)
Newsgroups: vmsnet.mail.pmdf
Subject: More on no tape label problem.
Date: 15 Aug 92 19:03:00 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 15 Aug 1992 14:03 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNLWOEG43M95N4LT@YMIR.CLAREMONT.EDU>
X-Organization: Duke University Medical Center, Durham NC, USA
X-Vms-To: IN%"ipmdf@ymir"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

By the way, I was sent a 9-track tape if that helps.
Here is some more I tried:

$ mou/ov=id mua0:
%MOUNT-F-NOTLABELMT, tape is not labeled

$ mou/nolab mua0:
%MOUNT-I-WRITELOCK, volume is write locked
%MOUNT-I-MOUNTED,  mounted on _MIVAX$MUA0:

$ copy mua0:[000000]*.* */log
%COPY-E-READERR, error reading _MIVAX$MUA0:[].;
-RMS-F-RER, file read error
-SYSTEM-F-PARITY, parity error
%COPY-W-NOTCMPLT, _MIVAX$MUA0:[].; not completely copied
%COPY-F-OPENOUT, error opening DUA3:[SAVESETS].;1 as output
-RMS-F-SYN, file specification syntax error

$ dir mua0:[000000]
%DIRECT-E-OPENIN, error opening MUA0:[000000]*.*;* as input
-SYSTEM-F-NOTFILEDEV, device is not file structured


And I was excited to instal the new version sunday :-(

-Jim
From: mitchell%uthscsa.bitnet@ymir.claremont.edu (Scott J. Mitchell)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: two minor points
Date: 12 Aug 92 16:26:00 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 12 Aug 1992 11:26 -0500 (CDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNHMFJJLWI94E14W@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"ipmdf@YMIR.CLAREMONT.EDU"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Original_To: BITNET%"ipmdf@ymir"

>>  Is this information "boundary..." important to the person, who really only
>>  needs to know that he spelled the nodename wrong?
>>  Can we suppress it?

> This information is boundary information separating different pieces of the
> message.  The message, if you examine the headers, is a multipart message
> which had two pieces: bad address list and returned content of the original
> message.  You cannot remove this information.  When we finish up our user
> agent, users using it will not see these boundary markers and whatnot (althoug
h
> they will still be there).

I hate to sound retrograde, but there are probably some sites that would
prefer non-multipart notices.  Many people here won't have MIME-speaking
UAs in the near future.  Novice users looking at these things sometimes
despair before noticing that they contain readable information!

Scott Mitchell
University of Texas Health Science Center
mitchell@uthscsa.edu
From: cheri Weaver..Information Technology...849-2850
Newsgroups: vmsnet.mail.pmdf
Subject: pmdf-mr
Date: 21 Aug 92 19:05:00 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 21 Aug 1992 14:05 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNUBGU51J695NURK@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"info-pmdf@ymir.claremont.edu"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT


One of the questions asked during the configuration of pmdf-mr
is:  Convert WPS-PLUS to ASCII ?  I chose NO because I had already
answered yes to a similar question from the installation of V3.0 of
ALLIN1.  The question was "do you want outgoing WPS-PLUS docs converted
to ASCII?

I assumed that it is the same function, but if so why does PMDF offer
it if ALLIN1 already does it.

Is this one of those cases where it isn't getting done quite right
and I should be letting PMDF do the converts?  :-)

Thanks for any help
Cheri
From: david J. Knapke 317/283-9420
Newsgroups: vmsnet.mail.pmdf
Subject: Mail User agents
Date: 13 Aug 92 04:20:56 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 12 Aug 1992 23:20:56 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNIBG12Y3M94E2S5@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"IPMDF@YMIR.CLAREMONT.EDU"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

We finally making efforts (and aparently have money too, wow) to have a
complete mail solution.  We have both Macs and IBM compatibles on people's
desk, very few VTs.  We would like a mail system that generally stores mail
on a host, getting people to backup is not fun around here.

I have looked at a couple of packages, but have not found the product that
fits the mold here just yet.  Believe it or not, talking with Digital,
MailWorks (A1 mail) seems to be most intersting to us.  A couple of questions
that the Rep couldn't answer though, what transports/protocals can you run
with the MailWorks client (both environments)??

We also looked at QuickMail, yuuuuk!

cc:Mail looked pretty good as well, but we are not sure how we are going to
serve it to close to 400 Macs.  On the DOS side, its easy, we have Novell
servers.  There has been discussion of the cc:Mail channel in PMDF and how
to push mail back and forth, that sounds good but a little ruff as far as
the particulars of pushing the files back and forth.  Ned mentions MIME
translation into cc:Mail, but said there were problems with multi-part mail
(if I recall correclty).  That confuses me since cc:Mail had the ability to
have multiple enclosures, or am I missing something??

Other considerations, Ithink Eudora is out for spoofing reasons.  I'm looking
at MicroSoft Mail, which is not impressive if you want to have good clients for
both platforms.  They are basically two different products that have a
gateway that runs betweent them, pretty klunky looking so far.

Anything else someone could suggest?  I would certainly appreciate any
info to help us out.

I wonder if this will divert peoples attention away from fueding??
(Sorry, I couldn't resist.  I think that we are lucky to have, as
someone else pointed out, a vender that is sincerely concerned about
there niche product and standards that revolve around it.)



David J. Knapke                       Knapke@ButlerU.BITNET
Computer Center                          Assistant Director
Butler University                     Information Resources
Indianapolis, IN  46208                      (317) 283-9420
USA                                     Fax: (317) 283-9740
From: tanner@cerritos.edu (Bruce Tanner)
Newsgroups: vmsnet.mail.pmdf
Subject: V4.1-10 mailserv questions
Date: 18 Aug 92 00:59:06 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 17 Aug 1992 16:59:06 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNP1PHCTPE95NGIU@YMIR.CLAREMONT.EDU>
X-Vms-To: in%"info-pmdf@ymir.claremont.edu"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

I have a few questions about the mailserv channel in V4.1-10:

* Where do I define the COMMAND_LIMIT, MAXBLOCKS and MAXLINES options?

* What is the format of the MAILSERV_ACCESS file?

* Mailserv appears to reply to the envelope From: rather than the header From:
  field.  I modified the V4.0 mailserv to use the header field and had much
  better control over processing UUCP return addresses.

* If I request a file /MODE=BLOCK/ENCODING=UUENCODE I get back (1) a foreign
  file format message and (2) a FDL message that contains:

Content-transfer-encoding: X-UUENCODE
Comments: These headers describe a message previously delivered in foreign file
 format.

  Has the file been decoded automatically from uuencode format to foreign file
  format for me, or is it not being uuencoded at all?

Thanks,
-Bruce
--
Bruce Tanner        (310) 860-2451 x 596    Tanner@Cerritos.EDU
Cerritos College    Norwalk, CA             DoD #0161  NOMAD #007
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Mail User agents
From: andrewr@itd.adelaide.edu.au
Date: 13 Aug 1992 15:57:37 +1000
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 13 Aug 1992 15:57:37 +1000
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: info-pmdf@INNOSOFT.COM
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNIFTQIHS294DUAV@INNOSOFT.COM>
X-Vms-To: IN%"KNAPKE%BUTLERU.BITNET@ymir.claremont.edu" "David J. Knapke
X-Vms-Cc: IN%"info-pmdf@INNOSOFT.COM"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
X-Mts: smtp

In message <01GNIEH45BAA8ZDWGA@BUTLERU.BITNET> you write:

+ cc:Mail looked pretty good as well, but we are not sure how we are going to
+ serve it to close to 400 Macs.  On the DOS side, its easy, we have Novell

	We use Novell servers, as they appear as AppleShare File
Servers, so you have both Mac's and PC's accessing the same post
office sitting on the Novell server.

+ servers.  There has been discussion of the cc:Mail channel in PMDF and how
+ to push mail back and forth, that sounds good but a little ruff as far as
+ the particulars of pushing the files back and forth.  Ned mentions MIME
+ translation into cc:Mail, but said there were problems with multi-part mail
+ (if I recall correclty).  That confuses me since cc:Mail had the ability to
+ have multiple enclosures, or am I missing something??

	We are now in the process of configuring up a PC which will
run PC-NFS to access the VAX running PMDF and IPX to access to Novell
server concurrently, and using that to push messages backwards and
forwards automatically. Although we don't actually have it running as
yet (trying to get a modern PC-NFS) we've faked the rest out and it
looks like it should all work.

+ I wonder if this will divert peoples attention away from fueding??
+ (Sorry, I couldn't resist.  I think that we are lucky to have, as
+ someone else pointed out, a vender that is sincerely concerned about
+ there niche product and standards that revolve around it.)

	Agreed. Innosoft have done a lot, and their product is miles
ahead of anything else I've seen, IMHO. Keep up the good work, guys.

	Andrew.

/*
 * Andrew Rutherford                 andrewr@itd.adelaide.edu.au
 * +61 8 228 5669            Real Programmers always confuse Christmas and
 * Room 1060, Adelaide Uni      Halloween because OCT 31 == DEC 25 !
 */
From: dan@innosoft.com (Daniel C. Newman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Problem with printer channel?
Date: 20 Aug 92 20:11:00 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 20 Aug 1992 12:11:00 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNSYN4BWR695NQTC@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"coleve@cc.uvcc.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> Hmmmm. Good point.
>      How about:
>      HARDCOPY.UVCC.EDU        /AT=$U@PRINTER.UVCC.EDU
>      PRINTER.UVCC.EDU             $U@PRINTER.UVCC.EDU
>
> That way you can do it both ways, correct?

No, instead you now have double the trouble.  This whole discussion centered
around people using incorrect printer channel addresses. Regardless of what you
do, people will occassionally enter an incorrect address.  Now you've merely
introduced a new variable they can get wrong -- two different printer channel
"domain" names each with a different addressing format.

Dan
From: dan@innosoft.com (Daniel C. Newman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Deliver and MM-32
Date: 21 Aug 92 17:04:49 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 21 Aug 1992 09:04:49 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNU6BNYEPU95NVJA@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"dsroberts@beckman.com"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> We just noticed a problem with this today.  DELIVER seems to have stopped
> working with MultiNet MM as of PMDF 4.1.  Perhaps a logical needs to be set or
> something?

If it was working before and has now stopped, then someone has probably changed
something on your system (e.g., gotten rid of the batch queue for DELIVER
processing, cut over to the PMDF Process Symbiont and not set up a queue other
than MAIL$BATCH for DELIVER processing to occur in, defined one of the MultiNet
or PMDF logicals which inhibit delivery of any mail to MM, set a PMDF switch
in the PMDF_ option file to inhibit any delivery to MultiNet MM).  The bottom
line is that if it was working before and isn't now, it probably means that
somebody changed something on your system.

Dan
From: mac@gvg34.gvg.tek.com (The PMDF Postmaster)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Mail User agents
Date: 13 Aug 92 18:14:35 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 13 Aug 1992 10:14:35 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNJ339HL6A94E5VP@YMIR.CLAREMONT.EDU>
X-Vms-To: in%"Ipmdf@ymir.bitnet"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

The guy working on ccMail here downloaded the following document from the
ccMail BBS yesterday.

Bill MacAllister

================================================
DEC updates E-Mail, Provides cc:Mail Integration
================================================

BOSTON, MASSACHUSETTS, U.S.A., 1992 JUN 10 -- Digital Equipment has
announced a new release of its local area network electronic mail
integration product, MailWorks Postmaster, that ties DEC's mail systems
in
with Lotus Development's PC-based cc:Mail.

MailWorks Postmaster version 2.0 also adds new security features,
including virus detection and the ability to protect mail messages from
being read using network analyzers that can monitor the flow of data over
a network, said Valerie White, product manager.

White told Newsbytes that cc:Mail users will now be able to communicate
with colleagues who use DEC's Mailworks e-mail. Directories will be
integrated so users will not have to worry about who is on which system.
The cc:Mail connection is a first step in providing greater integration
between DEC's e-mail offering and those of other vendors. White said a
similar link to Microsoft Mail will be next, and other e-mail products
will be tied in with Mailworks later.

Mailworks supports DEC's own Pathworks networks, as well as Novell's
NetWare, 3Com and Banyan Vines networks running on Ethernet or Token Ring
hardware.

Due to be available in September, Mailworks Postmaster version 2.0 for
local area networks will cost $1,995. The wide area network version will
sell for $4,995, and the cc:Mail connection will cost $30.
(Grant Buckler/19920610/Press Contact: Terri Slater, Digital Equipment,
603-884-0753 or 617-849-6010)