HDTenEightyP/NetNews huggingface dataset:
From: ned@innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Mail lists and large queues
Date: 27 Jul 92 20:54:03 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 27 Jul 1992 12:54:03 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GMVHPX1F1U9GVS47@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"TIHOR@ACFcluster.NYU.EDU"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

One additional point. While it is true that list traffic can flood the
queues in some cases, it is also true that in most cases regular mail
will get jobs queued just to process it. As such, the list expansion already
tends to happen in a somewhat independent fashion. For example, we expand
several very large lists on ymir.claremont.edu, several of which see heavy
traffic, and in most cases this has virtually no effect on the initial
delivery attempt for regular mail.

Immediate delivery jobs for messages only "see" messages that they were
queued to process -- specifically, messages that appeared after some
time. This means that if mail from a list is already expanding in the
background the immediate job does not see it.

There is only one limitation with this approach. If your queues are so
narrow that there are always jobs pending you may not get additional
immediate jobs queued in some cases. The simple solution in this case is
to use a wider queue that supports more simultaneous delivery jobs at
once. I recommend at least six and possibly even eight job slots if you're
serious about expanding large lists to many channels. Note that
prioritization helps but cannot solve this problem -- if you use up all
your job slots on expansion of lists there is simply no place for
immediate message operations to go. Once prioritization of list messages is
available you can set things up so that these messages don't create
immediate jobs, but that's about all you can do. A job, once created,
is not the sort of thing that can change its mind about what it is
doing. The VMS batch system is not flexible enough to suspend a running
job to let a later job start running.

The big problem comes with periodic delivery. Although periodic jobs try
to process messages with the fewest number of delivery attempts first, it
is far from certain that this simple criteria suffices to correctlyu
prioritize list traffic. This is the place where handling of jobs in
priority order is a real benefit. If a list expands but sees lots of
temporary delivery failures it can really wedge up periodic delivery.
This is the case that prioritization really fixes.

				Ned
From: dan@hmcvax.claremont.edu (Daniel C. Newman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Request for minor changes to installation procedure
Date: 26 Jul 92 17:01:00 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 26 Jul 1992 09:01 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GMTULNDGWY9GVOT5@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"JEREMY@vsm.com.au"
X-Vms-Cc: IPMDF
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> I do not gree with this.  Plenty of DEC products support a SYSTARTUP.COM as part
> of the regular startup procedure.  Sure, it can't cater for all sites, but I'll
> bet that if you say "PMDF_SYSTARTUP.COM is run at such-and-such a point in the
> startup process" people will set up their systems appropriately.

And when should we invoke a site-supplied system startup?  Before PMDF_STARTUP
runs or after (but before the networks begin running), or before
PMDF_SUBMIT_JOBS runs (and after the networks are started) or after
PMDF_SUBMIT_JOBS runs.  I know of legitimate examples, in use at sites today
for all four cases.

Dan
From: bob@camb.com (Bob Tinkelman)
Newsgroups: vmsnet.mail.pmdf
Subject: V4.1-9 still has problem with mr_local_master and forwarded messages
Date: 21 Jul 92 04:33:32 GMT
Organization: Cambridge Computer Associates, Inc.
Resent-Date: 20 Jul 1992 23:33:32 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Cc: TINKELMAN@decus.org
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-Id: <01GMM51K8BUQ8WVYKV@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

$ 	on control_y then goto trap
$ 	if f$mode() .eqs. "BATCH" then set noverify
Connecting to local Message Router.
Identifying as mailbox PMDF.
Dequeuing message, file - "PMDF_ROOT:[QUEUE.mr_local]ZV01GM4YKH2XF894E2D7.00".
Initializing MR for submission.
Converting return address to AVPL.
Creating message body temporary file.
Processing address list.
Good addresses found. Continuing...
  Multiple bodypart header detected.
  MR_WEND_ENVELOPE finishing envelope.
  MR_WEND_ENVELOPE finished envelope.
  Converting Message-id: header.
  Converting Subject: header.
  Converting Date: header.
mr_wend_bodypart called.
mr_wend_bodypart returning successfully.
mr_wend_bodypart called.
mr_wend_bodypart returning successfully.
  Message bodypart header detected.
  Multiple bodypart header detected.
  Converting Message-id: header.
  Converting Subject: header.
  Converting Importance: header.
  Converting Date: header.
  Converting A1-type: header.
mr_wend_bodypart called.
mr_wend_bodypart returning successfully.
mr_wend_bodypart called.
mr_wend_bodypart returning successfully.
  Message bodypart header detected.
  Converting Subject: header.
  Converting Importance: header.
  Converting Date: header.
  Converting A1-type: header.
mr_wend_bodypart called.
mr_wend_bodypart returning successfully.
mr_wend_bodypart called.
mr_wend_bodypart returning successfully.
Error - cannot end put of forwarded bodypart - routine is invalid in this state

20-JUL-92  23:21:51: Unexpected error in message submission.
%PAS-F-HALT, HALT procedure called
%TRACE-F-TRACEBACK, symbolic stack dump follows
module name     routine name                     line       rel PC    abs PC

                                                           0007786F  0007786F
                                                           000E58C3  000E58C3
MR_MASTER       TRY_SOMETHING                    3967      0000005B  0000D9BB
MR_MASTER       DOSUBMIT                         4038      00000534  0000D1AC
MR_MASTER       MR_MASTER                        4056      0000000C  0000D938
 -- end of message found
  SYSTEM       job terminated at 20-JUL-1992 23:23:02.05

  Accounting information:
  Buffered I/O count:             273         Peak working set size:    2270
  Direct I/O count:               316         Peak page file size:      8299
  Page faults:                   2654         Mounted volumes:             0
  Charged CPU time:           0 00:00:05.86   Elapsed time:     0 00:01:25.08
From: ned@sigurd.innosoft.com (Ned Freed (Postmaster))
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Request for minor changes to installation procedure
Date: 25 Jul 92 17:54:14 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 25 Jul 1992 10:54:14 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GMSNQ62ZF69GVMU4@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"JEREMY@vsm.com.au"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Again, this assumes knowledge of local environments that we simply do
not have. How do we know that such a local procedure should always be
run? How do we know that it should be run at a particular point?

Sure, providing a hook to run a site-supplied procedure is probably
good enough for a lot of sites. But it fails to address the entire problem,
which can only be addressed by having the site-supplied procedure run
PMDF_STARTUP only when it is good and ready, and then by having it
do whatever needs doing once PMDF_STARTUP is complete (most importantly
it can handle errors that PMDF_STARTUP returns in whatever fashion is
appropriate).

In other words, your proposal is considerably less flexible than providing
no hook at all. Why should we provide a mechanism with narrow flexibility
when no mechanism at all is considerably better?

				Ned
From: gcprtck@state.systems.sa.gov.au
Newsgroups: vmsnet.mail.pmdf
Subject: WP Office to Internet via X400/PMDF
Date: 28 Jul 92 06:45:23 GMT
Organization: State Systems, South Australia

We are running WordPerfect Office 3.0 and Mail on a Novell 3.11 Lan connected
via a Hub to an Ethernet backbone on which we also have a VAX 
running All-in-1 v2.4 under VMS 5.5 and with PMDF v4.0.

We will soon have installed a PC with an x400 gateway to allow sending X400
mail from the WordPerfect Office mail environment via the Ethernet to All-in-1
accounts on the VAX.

We also have an Internet connection.  We can send mail from All-in-1 accounts
to the Internet community and receive replies to All-in-1 accounts.

We would like to send mail from WordPerfect Office using the X400 connection
to and from Internet using PMDF directly. IS THERE A WAY TO DO THIS?
We have looked in the PMDF manual and are not sure if it can do this.
Otherwise we have to force the WP Office users to logon to All-in-1 in order to 
send and receive Internet mail which is not our preferred direction for 
our large Novell/WP Office networks where we want all mail to be seamless.

Alternatively, is there ANY OTHER WAY we can use X400 to talk to and from 
Internet to allow our users to remain in the safe haven of their WordPerfect
Office Mail screens while sending and receiving messages over Internet. 

I would appreciate any comments on this quickly (even the "God, I hate
WP Office and Novell LANs" variety) as I have managers breathing down my 
neck (with flames, fire and brimstone....).

Tim Kitching
State Systems
South Australia
Australia

(Sorry, there aren't any pretty ending graphics.....)
From: bob@camb.com (Bob Tinkelman)
Newsgroups: vmsnet.mail.pmdf
Subject: Postmaster notification for held msgs
Date: 28 Jul 92 20:41:16 GMT
Organization: Cambridge Computer Associates, Inc.
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 28 Jul 1992 16:41:16 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GMWWZAWQOY94DSIN@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 had situation where pmdf held some msgs after detecting a probable mail
loop.  I don't think I'd received any notification from pmdf (e.g., via
a mail msg to postmaster) when this occurred.  Did I miss it?  Should the
daily RETURN job report on held files if they stick around for too many
days?

Thanks
--
Bob Tinkelman <bob@camb.com>
From: ned@sigurd.innosoft.com (Ned Freed (Postmaster))
Newsgroups: vmsnet.mail.pmdf
Subject: RE: stuck message in bit_gateway channel
Date: 22 Jul 92 16:24:59 GMT
Organization: The Internet
Resent-Date: 22 Jul 1992 08:24:59 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-Id: <01GMO86HZ5YQ9GV8N8@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"RICK@qucdnee.ee.queensu.ca"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

First of all, while the log is helpful, it is not sufficient to determine
if this is a known problem or not. A log with master_debug and slave_debug
enabled on the channel would allow for a much more precise determination.

With this much information and no more I'm reduce to making guesses. This
looks like a known problem with PMDF V4.0 and bit_gateway channels that
are marked nosendpost. One workaround is to mark the channel errsendpost
or sendpost. errsendpost is actually the right thing to mark this channel,
since nosendpost results in situations where nobody at all gets copies
of some failed messages.

This problem is fixed in PMDF V4.1.

Now, it is possible that there is something else wrong. I have made a
bunch of assumptions here. If this is not what happening I'll need (1)
a more detailed log, (2) a copy of your PMDF.CNF, (3) precise information
about what version you're running, and (4) a copy of the message that's
causing the problem.

Finally, you might want to continue this discussion with service@innosoft.com
rather than info-pmdf, especially if large logs and configurations are
involved.

				Ned
From: ned@innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: stuck message in bit_gateway channel
Date: 21 Jul 92 00:09:45 GMT
Organization: The Internet
Resent-Date: 20 Jul 1992 17:09:45 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-Id: <01GMLXWOF0F6985D5G@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"RICK%QUCDNEE.BITNET@ymir.claremont.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

I cannot even guess what the problem is without some sort of log showing
what happens when delivery is attempted.

				Ned
From: dan@hmcvax.claremont.edu (Daniel C. Newman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Problem with vmsnet.mail.pmdf gateway?
Date: 21 Jul 92 00:14:00 GMT
Organization: The Internet
Resent-Date: 20 Jul 1992 16:14 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-Id: <01GMLVYKCYUQ985GAN@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"IMHW400@INDYVAX.IUPUI.EDU"
X-Vms-Cc: IPMDF
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> Is there some sort of problem with the gateway between IPMDF and the
> vmsnet.mail.pmdf newsgroup?  Or has this list really been silent since
> 6-Jul-1992?

info-pmdf itself has not been silent.  We do not know where the info-pmdf
to vmsnet.mail.pmdf feed is and thus cannot comment or rectify any problem
related to that feed.

Dan
From: copeland_rp@corning.com (Richard P. Copeland)
Newsgroups: vmsnet.mail.pmdf
Subject: Re: VMS MAIL_SERVER and undeleted temp files
Date: 21 Jul 92 13:50:05 -0500
Organization: Corning Incorporated

In article <01GMLRT10XTY9FM73V@YMIR.CLAREMONT.EDU>, mitchell%uthscsa.bitnet@ymir.claremont.edu (Scott J. Mitchell) writes:
> We recently discovered a large number (10,000s) of uncataloged MAIL.TXT
> files on the system disk of one of our Vaxes.  DEC acknowledges that
> MAIL_SERVER.EXE is creating these temp files and failing to delete them
> properly, but at the same time they're pointing an ambiguous finger at
> "non-DEC protocols," suggesting that the problem is more likely to occur
> when the delivering system is something other than VMSmail.  A timestamp
> comparison suggests that the problem is indeed associated with deliveries
> relayed by our primary mail host using PMDF.
>  
> I'm absolutely not suggesting that PMDF has any relationship to this problem,
> particularly in a causal sense.  Just wondering if anyone can shed additional
> light on the subject.  We were caught asleep at the switch and had some
> difficulty recovering the disk because of a hosed INDEXF.SYS.
>  
> Scott Mitchell
> University of Texas Health Science Center at San Antonio
> mitchell@uthscsa.edu
> mitchell@uthscsa.bitnet
>  

We saw the same behavior on one of our systems ... we got about 6,600 MAIL.TXT
files before rectifying the problem.  We used ANAL/DISK/REPAIR to place them
all in [SYSLOST], and I took a look at several of them.  Occasionally, some
mail messages sent via PMDF will generate hundreds of duplicate partial copies
as uncatalogued MAIL.TXT files.  The other weird thing is that the files were
on DIA0 (the system disk), while the recipient was on DIA2.  Another weird
thing is that other systems exhibit no problems whatsoever.

DEC indicates that this is a VMS bug that will be fixed in VMS V5.5-2.  Until
then, we're just going to ANAL/DISK/REPAIR on that system more frequently.

Richard Copeland
Corning Incorporated, Corning NY
copeland_rp@corning.com
From: jeremy@vsm.com.au (Jeremy Begg)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Request for minor changes to installation procedure
Date: 26 Jul 92 23:54:38 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 26 Jul 1992 17:54:38 -0600 (CST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GMTEPHTHS29GVO26@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

>Again, this assumes knowledge of local environments that we simply do
>not have. How do we know that such a local procedure should always be
>run? How do we know that it should be run at a particular point?
> ...
>In other words, your proposal is considerably less flexible than providing
>no hook at all. Why should we provide a mechanism with narrow flexibility
>when no mechanism at all is considerably better?

I do not gree with this.  Plenty of DEC products support a SYSTARTUP.COM as part
of the regular startup procedure.  Sure, it can't cater for all sites, but I'll
bet that if you say "PMDF_SYSTARTUP.COM is run at such-and-such a point in the
startup process" people will set up their systems appropriately.

        Jeremy Begg

  +----------------------------------------------------------+
  | VSM Software Services,  |  E-Mail:  jeremy@vsm.com.au    |
  | P.O.Box 801, Unley,     |   Phone:  +61 8 4145074 (pager)|
  | South Australia 5061    |     FAX:  +61 8 3734911        |
  +----------------------------------------------------------+
From: ned@innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: VMS MAIL_SERVER and undeleted temp files
Date: 20 Jul 92 22:43:06 GMT
Organization: The Internet
Resent-Date: 20 Jul 1992 15:43:06 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-Id: <01GMLUW5M2WY985FZB@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"MITCHELL%UTHSCSA.BITNET@ymir.claremont.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

There are two cases where MAIL_SERVER is used. One is with PMDF's incoming
message processing. The other is with incoming DECnet mail. I suspect that
the latter is more of an issue; if experience is any indication the use of
MAIL_SERVER in this way can lead to lots of these files left lying about.

PMDF has no direct involvement; these files are created (and deleted) entirely
on the whim of MAIL_SERVER. It would seem that a decent exit handler would
eliminate them unconditionally, but unfortunately this approach is not used
as far as I know.

In short, this is a problem which, even if some abnormal condition in PMDF
was the cause (this is totally hypothetical mind you), is totally the
responsibility of VMS MAIL to clean up properly. Given the fact that these
are pure scratch files not entered into any directory there is no way for
PMDF to get a handle on the file even if it wanted to.

				Ned
From: schellbach@rz.rwth-aachen.de
Newsgroups: vmsnet.mail.pmdf
Subject: UA for PCs on aysync lines to PMDF?
Date: 23 Jul 92 16:16:00 GMT
Organization: The Internet
Resent-Date: 23 Jul 1992 17:16 +0100
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-Id: <01GMPM6SF0LU94DP7O@INNOSOFT.COM>
X-Vms-To: IN%"ipmdf@innosoft.com"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

We have several users on our vax (running PMDF) connected whith
their PCs via async dial-up or dedicated lines. What can I do
to provide them a better mail service than using VMS mail as
a terminal?
Which of the pc mail clients are able to run over async lines?
Which server software is to be installed on the vax?
Any suggestions are welcome.

Thanks
Gert Schellbach-Mattay
Network Operations and Services
Computing Center
Aachen University of Technology
Aachen, Germany
From: jlw%psulias.bitnet@ymir.claremont.edu (J.Lance Wilkinson, 814-865-1818)
Newsgroups: vmsnet.mail.pmdf
Subject: Need NOTES API or NOTEBOOK structure information
Date: 22 Jul 92 17:43:00 GMT
Organization: The Internet
Resent-Date: 22 Jul 1992 12:43 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-Id: <01GMOB0HXLYQ9GVASR@YMIR.CLAREMONT.EDU>
X-Organization: Penn State University / University Libraries
X-Vms-To: I_BBOARD, INFO_VAX, IPMDF
X-Vms-Cc: JLW
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

We've been using Ben Cohen's BBOARD software successfully for quite some time.
Now we are getting ready to start using it with a larger set of users -- that
is, we're going to try to wean users who are currently receiving multiple
copies of various discussion lists off of using MAIL for these lists, and using
VAX Notes (where BBoard puts its single subscriptions).
 
Given the academic (read: argumentative) nature of our users, we suspect there
will be considerable resistance from a minority of users.  Given the academic
nature of our users, we also suspect that no decrees from on high will be
forthcoming.  So we want to sugar coat things a little, and one proposal on
the board is a subscribable service which would, during the wee hours, poll the
NOTEBOOKs of selected users, and send them MAIL when a threshold of unseen
messages is detected.  This would eliminate the complaint that while MAIL tells
them when they log on if it's worth going into MAIL, NOTES doesn't tell them if
its worth it to enter it, until they've already entered it and executed an
UPDATE command.
 
Of course, we plan to implement some more heavy-handed items as well, like
enforcing disk quotas a little tougher, and general harrassment of the really
bad offenders ;-)
 
+-"Never Underestimate the bandwidth of a station wagon full of mag tapes"--+
| J.Lance Wilkinson ("Lance")            BitNet:    JLW@PSULIAS.BITNET      |
| Systems Design Specialist - Lead       InterNet:  JLW@PSULIAS.PSU.EDU     |
| Library Computing Services             AT&T:      (814) 865-1818          |
| E8 Pattee Library                      "I'd rather be dancing..."         |
| Penn State University         A host is a host from coast to coast,       |
| University Park, PA 16802     And no one will talk to a host that's close |
| <POSTMAST@PSULIAS.BITNET>     Unless the host that isn't close            |
| <POSTMAST@PSUCES.BITNET>      Is busy, hung or dead.                      |
+------"He's dead, Jim. I'll get his tricorder. You take his wallet."-------+
From: dmpm%dukemc.bitnet@ymir.claremont.edu (James Dryfoos- PostMaster)
Newsgroups: vmsnet.mail.pmdf
Subject: Return address on envelope?
Date: 29 Jul 92 17:38:00 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 29 Jul 1992 13:38 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GMYPPI23ZM9GVYAO@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

Can someone help?  Why does the envelope from address here not
have a domain when the rest of the header does?  Mail was sent
from a NEXT box.  Am trying help someone set it up, but do not
have a clue to unix mail config files.

Thanks, JIm

m;schwa002@bullnext
DRYFO001@DUKEMC.DEMPO

Received: from bullnext.mc.duke.edu by mc.duke.edu (PMDF #12191) id
 <01GMY2AZ08E8004J9E@mc.duke.edu>; Wed, 29 Jul 1992 09:25 EDT
Received: by bullnext.mc.duke.edu (NX5.67a/NX3.0M) id AA01084; Wed,
 29 Jul 92 09:18:32 -0400
Received: by NeXT Mailer (1.82)
Date: Wed, 29 Jul 92 09:18:32 -0400
From: Babs Schwartz <schwa002@bullnext.mc.duke.edu>
Subject: More mail from Bullnext
To: dryfoos@romeo.cs.duke.edu, dryfo001@mc.duke.edu, dmpm@mc.duke.edu
Message-id: <9207291318.AA01084@bullnext.mc.duke.edu>