HDTenEightyP/NetNews huggingface dataset:
Newsgroups: vmsnet.mail.pmdf
Subject: PMDF API beta kit available
From: "Daniel C. Newman" <dan@innosoft.com>
Date: 07 Oct 1992 00:30:27 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 07 Oct 1992 00:30:27 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPNC2S834I8WWQKX@YMIR.CLAREMONT.EDU>
X-Vms-To: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

     A beta version of the PMDF API kit is available via anonymous FTP from
ymir.claremont.edu; look in the [.API] subdiretory.  The kit is the file
API.BKP.  The file PROGRAMMING.PS is also included in API.BKP so don't bother
retrieving both it and API.BKP; it's there for people who want to look over
the documentation without FTPing the whole kit (4,500 blocks).

     The kit includes the PMDF Programmer's Reference Manual in PostScript and
Bookreader form, the API, and a directory of example programs.  (There's even
an example which you can use to rot13 all of your user's mail -- the rot13
channel!)

     The kit, a BACKUP saveset, should be restored to the directory
PMDF_ROOT:[API] with the command

     $ backup/log api.bkp/save pmdf_root:[*...]*.*/truncate

The manual PMDF_ROOT:[API]PROGRAMMING.PS may be printed on a PostScript printer.
The *.DECW$* files may be copied to PMDF_ROOT:[DOC] to install the online
documentation.

     The API is provided for two primary reasons.  First, to make PMDF
programming more accessible to the PMDF community through a documented
interface which insulates programmers from PMDF's internal data structures.
(What's a vstring?)  And second, to provide a stable interface which will
insulate programmers from changes made to PMDF internals.

     At present, the API has all of the basic functionality which we ourselves
use in existing PMDF enqueuing and dequeuing programs.  Programmer's who have
previously written code using PMDF (e.g., channels), should take a look at the
API If you notice any functionality missing, let us know.  By missing
functionality, I mean functionality which you use currently but that we did not
provide access to through the API.  It'll be missing for one of three reasons:
it didn't occur to us; we'd rather that you not be doing that; or we plan to
add it in V4.2.  (Instances of "we plan to add it in V4.2" includes access to
channel options, access to a header lines in header structures, and address
parsing.)

     Any suggestions, comments, criticims, proof reading, etc. is, as usual,
appreciated.  (And yes, we know about all of the lousy page breaks in the
manual -- we won't fix those until we produce the final version.)

Dan

P.S. The command required to link against the API will become simpler in
     PMDF V4.2.  At present this kit, which was developed under V4.2, is
     a retro-fit onto PMDF V4.1.
From: pern%uordbv.bitnet@ymir.claremont.edu (Jack Pernice)
Newsgroups: vmsnet.mail.pmdf
Subject: MAILSERV and SEND/ENCODING
Date: 9 Oct 92 19:18:00 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 09 Oct 1992 15:18 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPQULN8Q5E8WX44M@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"info-pmdf@YMIR.BITNET"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

VMS V5.5-2HW on a VS400 model 90
PMDF V4.1-7

We're having a problem with the MAILSERV channel with regard to encoding.

A user sends a request for a file with encoding specified.  MAILSERV responds
with an error:

Remote user sends:

        SEND/ENCODING=UUENCODE [TEST]VMSU2055.RELEASE_NOTES


MAILSERV replies:

        Illegal encoding specified in command: SEND/ENCODING=UUENCODE
        [TEST]VMSU2055.RELEASE_NOTES
        Use the HELP command to get a list of legal MAILSERV commands.

You get a similar MAILSERV response with:

        ENCODING UUENCODE
        SEND [TEST]VMSU2055.RELEASE_NOTES


Here's the relevent portion of a MAILSERV_MASTER.LOG w/ master_debug:

$ run pmdf_root:[exe]mailserv.exe
Debugging enabled.
  Command limit set to 2147483647
  Maximum blocks per message set to 2147483647
  Maximum lines per message set to 2147483647
  MAILSERV reply address is: mailserv-reply@ehsct7.biophysics.rochester.edu

Starting processing of PMDF_ROOT:[QUEUE.mailserv]ZZ01GPQVRKR0HG984IVM.00
  Message is from: PERN@db1.cc.rochester.edu
  Command: ENCODING UUENCODE
  CLI$DCL_PARSE returned status of 196609
Processing ENCODING command.
  CLI$DISPATCH returned status of 0
  Error in command. Ignoring remainder of message.
  Making response header.
  Closing the output message.
  Finished with this message.
$ goto out1


I went poking through the sources and found references to X-UUENCODE so I tried
that.

I got:
        Unrecognized keyword - check validity and spelling
         \X-UUENCODE\
        Use the HELP command to get a list of legal MAILSERV commands.


It seems as if the CLI is parsing the string correctly since it recognizes the
proper keyword ("Illegal encoding specified" vs "Unrecognized keyword").
Are all encodings implemented?

Thanks,
Jack Pernice                             BitNet:    PERN@UORDBV
VMS Systems                              InterNet:  pern@db1.cc.rochester.edu
University of Rochester                  Voice:     (716) 275-7160
Rochester, NY  14620
From: ned@sigurd.innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Tracking Messages
Date: 8 Oct 92 22:27:30 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 08 Oct 1992 15:27:30 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPPLNA2WDE8WX0L6@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"GREENBJB%SNYONEVA.BITNET@ymir.claremont.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> Can you point me to a section in the 4.1 manual that might discuss how, why and
> when you get messages back from each node (hop) when you send mail.

This is described in passing throughout the chapter on BITNET.

>  You know what messages I mean, the ones that say things like:

> (SNYONEVA) - Sent file 6718 on link SNYBUFVA to SNYBUFVA BROWNRN
> (SNYBUFVA) - File (6718) spooled to BROWNRN -- origin SNYONEVA(GREENBJB) 10/08/9 2 10:17:15 EDT

You will get these messages when the message orginates from your username on
the local host and the messages can make it back to you. It is as simple as
that. The question then is when are messages marked this way. This brings the
full complexity of address rewriting and handling into the picture.

PMDF tries to make this happen as much as possible but cannot guarantee it.
There are many cases where it isn't possible. Here are a few of them:

(0) The bit_ channel you use is, for some reason, marked nolocaluser, blocking
    the use of local user names in the BITNET message envelope.
(1) You aren't a local user sending mail directly from VMS MAIL or some other
    user agent on the local machine/cluster.
(2) Your configuration is failing to map all local host aliases to the
    local channel.
(3) You choose to identify the message as coming from someone else.
(4) The message is produced by expansion of a mailing list which specifies
    an override envelope From: address.
(5) Your BITNET gateway machine cannot get the message back to you to print
    them.
(6) Your terminal is /NOBROADCAST.
(7) Your username is too long (>8 characters).

> I need to understand the details of these messages better so I know why we
> sometimes get them and sometimes don't.

The above list is far from inclusive.. The situation is so complex and
convoluted it simply isn't feasible to answer this question precisely and in
one place.

					Ned
Newsgroups: vmsnet.mail.pmdf
Subject: RE: "MESSAGE DAMAGED IN TRANSIT" messages
From: Ned Freed <ned@innosoft.com>
Date: 08 Oct 1992 21:10:23 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 08 Oct 1992 21:10:23 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPPXMFTRQA8WX08R@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"TERRY@spcvxa.spc.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

These occur when a message is partially written to the PMDF queue. This
is usually attributable to a system failure during the writing process.
In this particular case a system failure is very likely the culprit; there
have been a bunch of power failures at the Claremont Colleges
lately.


We'll look into having a more elaborate message in the future. No promises;
this is detected in a heavily used inner loop and it is extremely difficult
to add much functionality there.

			Ned
From: mac@gvg47.gvg.tek.com (Bill MacAllister)
Newsgroups: vmsnet.mail.pmdf
Subject: ccMail-Mac file attributes
Date: 8 Oct 92 21:45:19 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 08 Oct 1992 14:45:19 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPPOSMCOL28WX0SY@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"Ipmdf@ymir.bitnet"
X-Vms-Cc: MAC
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

We are using Pathworks and ccMail.  The ccMail-DOS to PMDF-ccMail is pretty
straight forward and as described in the PMDF documentation.  But, get the
stuff into the MAC environment is another issue.


Using ccMail suggestions for getting ccMail-Mac to gateway to other systems
requires a PC running Phonenet Talk.  The Phonenet talk mounts the Mac
volume with the postoffice on it and the import file (in bound to ccMail).
This import file is create by PMDF and does not have any of the resource
information that Mac's like.  This information is provided by the VAX
Pathworks-Mac server. Unfortunatly the default values for the resource
information for the files that we decided to create did not work.  We ended
up adding entries to the MSA$ROOT:[MSA]MSAF$FILES_TYPES.DAT file to resolve
the problem.  This is a little of a black art for me so I thought that our
implementation might be interesting to others.  Here are the entries that
we added.

!
!       Make a file that PhoneNet Talk will like
!
!Format	Attr	Semantics   ".EXT"	Creator	Type    Translation
*       *       *           EXP         mdos    TEXT    none
*       *       *           IMP         mdos    TEXT    none
*       *       *           UND         mdos    TEXT    none

Thus, and file that has a file type of EXP, IMP, or UND will get marked
with a creator of mdos, a type of TEXT, and no translation will be
performed.  What to set this to was gleaned of looking at a file that was
created by ccMail-Mac with ResEdit.

Hope this is useful.  Comments greatly appreciated.

Bill

!-----------------------------------------------------------------------!
! Bill MacAllister    MS 8L         !  EMail:     Mac@GVG47.GVG.TEK.COM !
! The Grass Valley Group, Inc.      !                                   !
! P.O. Box 1114                     !  Telephone: 916-478-3201          !
! 13024 Bitney Springs Road         !  FAXphone:  916-478-3187          !
! Grass Valley, California 95945    !                                   !
!-----------------------------------------------------------------------!
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Tracking Messages
From: John C Klensin <klensin@infoods.mit.edu>
Date: 09 Oct 1992 07:25:28 -0400 (EDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 09 Oct 1992 07:25:28 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: ipmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPQDODDBTE8WX2C3@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"NED@INNOSOFT.COM"
X-Vms-Cc: IN%"ipmdf@YMIR.CLAREMONT.EDU"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Mail-System-Version: <VAX-MM(312)+TOPSLIB(155)+PMDF(4.1)@INFOODS.MIT.EDU>

>I loathe the silly messages
>myself and news that modern NJE implementations feel this way is most
>welcome personally. Speaking as a developer, it has proved quite difficult
>to provide an environment that maximizes the likelihood that these messages
>will be produced and directed properly.

Just to add one more comment to this to put things in perspective...  On
VM/CMS, mail has traditionally been kept a bit more separated from file
transfers than it has been with JNET (with or without PMDF).  If I send
a file, I get back the little progress messages to the extent that
intermediate hosts send them.  But, if I send mail, it goes to a mailer
machine, which does the actual transferring.  The progress messages then
go to the mailer, which discards them (it makes no attempt to forward
them to the user).  I can tell the mail user agent to send the message
"direct" (i.e., without the mailers intervening) but, in doing so, I
lose whatever services mailers might provide, including the ability to
specify addresses that consist of more than an 8-character user id and
an 8-character user id.

PMDF may have suffered from an excess of zeal in trying to support this
in the first place. :-)
     john
Newsgroups: vmsnet.mail.pmdf
Subject: RE: MAILSERV and SEND/ENCODING
From: Ned Freed <ned@sigurd.innosoft.com>
Date: 09 Oct 1992 15:27:26 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 09 Oct 1992 15:27:26 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPQZXET5HU8WWNQF@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"PERN%UORDBV.BITNET@ymir.claremont.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

This was fixed in PMDF V4.1-10. Contact iii@innosoft.com to arrange for
a new distribution if you want one.

				Ned
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Stuck BITNET Mail
From: c.chaundy@its.unimelb.edu.au
Date: 08 Oct 1992 12:41:46 +1000
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 08 Oct 1992 12:41:46 +1000
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: ipmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPOGA4ZOWY8WWW31@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"NED@SIGURD.INNOSOFT.COM"
X-Vms-Cc: IN%"ipmdf@ymir.claremont.edu"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

>Date: 07 Oct 1992 17:25:44 -0700 (PDT)
>From: Ned Freed <NED@SIGURD.INNOSOFT.COM>
>Subject: RE: Stuck BITNET Mail
>
>You can try deleting the QUEUE_CACHE.DAT file and rebuilding it from
>scratch. That's the only thing I know of you have not done.
>
>Two other sites have reported that this has happened to them. We have never
>seen it here, and our experience includes a machine that processes 3000-4000
>messages per days.

Not directly related (maybe) but a useful piece of information:

One situation where I *have* found it necessary to delete the QUEUE_CACHE.DAT
file and rebuild it from scratch is when I have manually moved files from one
channel directory to another and I want to get them picked up for delivery.
The SYNCH_CACHE.EXE program seems to note that the message is already in the
file and does not updated the channel the message is associated with, and so
when the master program goes to look for the message, it looks in the 'wrong'
directory, cannot open the message file and just goes on...

Regards, Chris Chaundy (Technical Manager, Networks)

Information Technology Services, Thomas Cherry Building,
The University of Melbourne, Parkville, Victoria 3052 Australia
Phone:    +61 3 344 7045                Fax:   +61 3 347 4803
Internet: C.Chaundy@its.unimelb.EDU.AU 	(X.121 505233430003)
Newsgroups: vmsnet.mail.pmdf
Subject: Problem with cc:Mail channel.
From: andrewr@itd.adelaide.edu.au
Date: 13 Oct 1992 12:03:56 +1000
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 13 Oct 1992 12:03:56 +1000
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPVFFA6TCI8WXCGZ@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"info-pmdf@YMIR.CLAREMONT.EDU"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
X-Mts: smtp

Hi all,
	I was testing out the cc:Mail channel of PMDF with files, etc,
and everything seemed to be fine until I rolled it into production. At
this stage, mail from SMTP to cc:Mail that used to say it was from

andrewr@itd.adelaide.edu.au at AARNet

	in the cc:Mail export file, where AARNet is the name of the
post office as defined in cc_local_option, now says

andrewr at itd.adelaide.edu.au

	Which is a bit of a hassle as when someone tries to reply to
it, the post office gateway (we have around 12 post offices) spits it
back as an invalid post office. It's not what the manual states should
be happening, either.

	At the same time, mail going out from cc:Mail used to work if
someone selected the AARNet post office and typed
"andrewr@itd.adelaide.edu.au", now they get back the following (this
is the file before it gets imported back into cc:Mail)

------
Message:
From: postmaster at AARNet
Date: 13-Oct-1992 10:29:43
To: Peter Payne at ITD
Subject: Undeliverable mail: Processing failure
Contents:
Text item:
These addresses were rejected:

  andrewr@itd.adelaide.edu.au at AARNet: Invalid embedded RFC822 address
Text item:
Will you get this????

Peter P.
------

The answer being no. I assume it's trying to map this to
andrewr@itd.adelaide.edu.au@AARNet or something similar.

Here's the relevant sections of PMDF.CNF:

------
...
ccmail                          $U%ccmail.adelaide.edu.au
ccmail.adelaide.edu.au          $U@ccmail.adelaide.edu.au
ITD                             $U%itd.ccmail.adelaide.edu.au
itd.ccmail.adelaide.edu.au      $U%ITD@ccmail.adelaide.edu.au$E$F
itd.ccmail.adelaide.edu.au      $U%itd.ccmail.adelaide.edu.au@ccmail.adelaide.ed
u.au$Ccc_local
itd.ccmail.adelaide.edu.au      $U%ITD@ccmail.adelaide.edu.au
...
cc_local master reverse period 1
ccmail.adelaide.edu.au
------

And CC_LOCAL_OPTION.:

CC_GATEWAY_NAME=AARNet
CC_OUTPUT_FILE_NAME=DKA400:[POST_OFFICE]CCMAIL.IMP
CC_INPUT_FILE_NAME=DKA400:[POST_OFFICE]CCMAIL.EXP


	So my question is - why is it doing this, and what can I do to
make it do it the way it used to? I've tried a different bunch of
options on the cc_local line, but it doesn't seem to make any
difference.

Thanks in advance,
		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 !
 */
Newsgroups: vmsnet.mail.pmdf
Subject: PMDF under T6.0
From: Bob Tinkelman <bob@camb.com>
Date: 12 Oct 1992 20:05:27 -0400 (EDT)
Organization: Cambridge Computer Associates, Inc.
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 12 Oct 1992 20:05:27 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPVA9FRI5U8WVZYG@INNOSOFT.COM>
X-Vms-To: IN%"info-pmdf@innosoft.com"
X-Vms-Cc: TINKELMAN
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

If anyone is running PMDF under a field test of VMS 6.0 and would be
willing to chat with me off line, either via e-mail or analog phone, I
would appreciate it.
--
Bob Tinkelman <bob@camb.com> 1-718-776-6811
Newsgroups: vmsnet.mail.pmdf
Subject: RE: "MESSAGE DAMAGED IN TRANSIT" messages
From: smith%nyumed.bitnet@ymir.claremont.edu
Date: 10 Oct 1992 08:40:58 -0400 (EDT)
Organization: NYU Medical Center, 550 First Ave., New York, 10016
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 10 Oct 1992 08:40:58 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPRTROSHJ68WX7CD@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"'Terry Kennedy, Operations Mgr'
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT


We have been getting these too.  Does this mean that the message may be missing
a comma somewhere? or does it mean that the entire thing got trashed?  In the
first case, it may be quite helpful to get whatevermessage is available
rather than just the warning.
From: seth@speech.mit.edu
Newsgroups: vmsnet.mail.pmdf
Subject: File create errors.
Date: 15 Oct 92 19:00:00 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 15 Oct 1992 14:00 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPZ4O28GJM8WXQUZ@YMIR.CLAREMONT.EDU>
X-Vms-To: NETMAIL"INFO-PMDF@YMIR.CLAREMONT.EDU"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Hi,

	We have just started experiencing occasional errors when sending
mail using PMDF. These errors started several weeks after switching from
CMU's TCP/IP to Multinet (a change we are EXTREMELY happy with!) although
there may be no correlation. The outgoing mail all eventually gets delivered.
Any idea as to the cause of the failure? I have checked what I think are
the obvious things, and did not see anything in the PMDF V4.0 docs to guide
me... (the error messages are included below.)

	I would make the following observation though. Many times,
especially when using the CMU name resolver, users would get 'bounce'
messages from PMDF indicating that there was a delivery failure. We
still get ocassional messages like the one mentioned above, only to
find that the mail was later delivered without incident. These messages
frequently cause the sender some understandable disquiet, and also
stimulate a resend (by the user) of the (appparently) offending mail
message. Is there a way to suppress these messages, perhaps at least
until n delivery attempts have been made? This seems like it would be
a handy feature. The PostMaster could (optionally) continue to receive
ALL the messages, to alert her to a potential problem.

	I would like to add that we are VERY pleased, long time users of
PMDF on the several VAXclusters I manage and having made Internet address
resolution reliable through the use of Multinet, we have NO complaints.

				Thanks in advance,

						Seth Hall
						Systems Manager
						Speech and Sensory
						  Communications Groups
						MIT, Cambridge
PMDF send errors:
------------------------------------------------------------------------------

%MAIL-E-SENDERR, error sending to user audiodev@cbgrle.mit.edu at
-PMDF-E-FCRT, File create error, Pascal status = 2, VMS statuses = 99684 and 0
-PMDF-I-TEXT, cannot create channel queue entry