HDTenEightyP/NetNews huggingface dataset:
Newsgroups: vmsnet.mail.mx
Subject: Re: test
From: "Steve Thompson, Cheme System Mangler" <olin@cheme.cornell.edu>
Date: Sat, 12 Dec 1992 08:22:38 EST
Organization: Mx-List<==>Vmsnet.Mail.Mx Gateway
X-Gateway-Source-Info: Mailing List

>I posted this update of the MAILPATCH.COM (patch to MAILSHR.EXE which allows
>MX to work without the "MX%") right after I ran into the same problem. Please
>note the section of the file which customizes for VMS version - I added the bit
>for v5.5-2.
>(Note to Hunter - Do you want to put this into the new (whenever that is)
>distribution? If so, go ahead).

For VMS 5.5-1, the appropriate locations are:

        MAIL$$ADD_ADDR  000049D2
        ADD_ADDR        000048FF

However, I note that after installing the patch, I observe the following.
I am using MX 3.1C and VMS 5.5-1. In the following, "host" is the short-
form name of a local machine, "host.full" is the fully-qualified name.

        To:     MX%"me@host"            works

        To:     MX%"me@host.full"       works

        To:     me@host.full            works

        To:     me@host                 appears to work but never delivers
                                        the message. Doesn't appear to be
                                        in the MX queue.

Anyone else seen this?

-Steve
/SIGNATURE
From: "Lars Blomberg, KTH Stockholm" <blomberg@plasma.kth.se>
Newsgroups: vmsnet.mail.mx
Subject: File server case sensitivity
Date: Tue, 15 Dec 1992 15:06:37 +0100
Organization: Mx-List<==>Vmsnet.Mail.Mx Gateway
X-Gateway-Source-Info: Mailing List

We are currently running MX V3.1C with several mailing lists and file servers.
Some of the file servers are associated with mailing lists to restrict access.
It seems that for a user to be authorized to access such a file server the
from-address must agree exactly (i.e., case-sensitively) with the address on
the mailing list even if this has been specified with the /nocase option.
Is this a bug in MX MLF or is our MX/mailing lists/file servers set up
incorrectly?

Lars Blomberg
Royal Institute of Technology, Stockholm
Newsgroups: vmsnet.mail.mx
From: eric@sejnet.sunet.se (Eric Thomas)
Subject: Turnaround time problem with MX 3.1/JNET
Reply-To: ERIC@SEARN.SUNET.SE
Organization: SUNET, Stockholm, Sweden
Date: Mon, 14 Dec 1992 18:52:33 GMT

In order to provide an 8-bit clean path for nordic users wishing to create
LISTSERV mailing lists where the official languages are scandinavian, I am
starting to make intensive use of MX and am having a turnaround time problem.

Users post to 'listname@LISTSERV.SUNET.SE', which is forwarded via a MX router
rule to 'listname@SEARN.BITNET'. LISTSERV processes the message and sends mail
with a %-hack back to the VAX, via JNET, which then takes care of the SMTP
delivery. This bypasses the SMTP translation tables on the VM system which,
unfortunately, I am not at liberty to change for 8-bitness as they are imposed
by the INTERBIT specifications. It has already been agreed that INTERBIT must
be updated to use 8-bit tables but we have not yet agreed on the table to use.

Anyway the problem is that it takes a while for the VAX to forward mail - in
either direction. The machine being mostly idle, it looks like there is a
built-in delay for polling the JNET queues, but of course I may have
misconfigured something. I am running MX V3.1. Is there anything I can do to
make MX more responsive? It gives the users the impression the machine is
heavily loaded at 3am on a sunday :-)

  Eric
From: Hunter Goatley <goathunter@WKUVX1.BITNET>
Newsgroups: vmsnet.mail.mx
Subject: RE: The case problem
Date: Fri, 18 Dec 1992 07:24:54 CST
Organization: Mx-List<==>Vmsnet.Mail.Mx Gateway
X-Gateway-Source-Info: Mailing List

Per Hogstedt <hogstedt@plab.se> writes:
>
>Matt spoke:
>>Definitely a bug in MLF.  I forgot to update the FILESERV_CHECK_ACCESS routine
>>(in module FILESERV.B32) to handle NOCASE-set mailing list users.  Thanks
>>for finding it.
>
>Since the case sensitivity problem has been a bit disturbing, I'd like to know
>if there is any chance that this could be corrected before the next release
>of MX (3.1d?). I don't know how extensive the update would be, but if there
>is anyone out there planning to hack away, I am interested to know and if
>possible help.
>
I've fixed this for the next release of MX.  I'm shooting for a
mid-to-late-January release of MX v3.1D.  It'll feature mostly little
fixes to annoying problems like this one.  I'm also alpha-testing new
FLQ routines that Matt wrote in BLISS (the old routines were written
in PL/1).  The new FLQ stuff still uses the ISAM queue file, but it
now uses subdirectories of FLQ_DIR to store messages to try to
alleviate problems with the QUEUE.DIR file getting larger than 128
blocks.  The BLISS rewrite was necessary to get MX working on Alpha,
which has been partially done.

Here's my planned schedule.  My wife has got my Christmas break all
planned out for me 8-), so I won't be able to work on MX much, if at
all, over the next three weeks.  Around 1/14/93 (can you believe
another year has gone by?), I hope to finish adding bug fixes, maybe a
new feature or two, then build an installation kit for beta-testing.
Once at least one other person successfully runs V3.1D 8-), I'll
release it.

Once v3.1D is released, I plan to spend time finishing the port of MX
to Alpha.  Matt has successfully sent a mail message from MX on an
Alpha, but it has *not* been thoroughly tested yet.  I hope to have MX
v3.1D running (and tested) on Alpha by the end of February.  After
*that*, it is my intention to replace the ISAM SYSTEM_QUEUE.FLQ_CTL
file with a more efficient method.

Naturally, the comments above state my *plans*.  I'm going to do my
best to meet the deadlines I've set, but I make no warranties,
guarantees, promises, oaths, etc., that it'll actually happen then.
8-)

Hunter
------
Hunter Goatley, VMS Systems Programmer, Western Kentucky University
goathunter@WKUVX1.BITNET, 502-745-5251
From: dave Mulvihill - Technical Support x-6993
Newsgroups: vmsnet.mail.pmdf
Subject: REPLY-TO: handling on PMDF-MR gateway
Date: 18 Dec 92 20:23:11 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 18 Dec 1992 15:23:11 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GSGLY4K2XU90N4G7@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"ipmdf@ymir.bitnet"
X-Vms-Cc: DPMSYS
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT


Does the PMDF-MR channel handle processing of the REPLY-TO:
headers so that replying in Allin1 will send to the REPLY-TO:
address?

I've set up a list in my aliases file with the reply-addr
specified as the list address.  For VMSMAIL recipients PMDF
rewrites the from address,  other recipients receive the
mail from the sender, but their mailer processes the REPLY-TO
headers and sends replys to the list.

Recipients who receive mail from this list via the PMDF-MR
channel recieve it from the sender and no processing of the
REPLY-TO address seems to occur.

Can I configure this somewhere?

Thanks,

Dave Mulvihill
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Registered mail
From: "Daniel C. Newman" <dan@innosoft.com>
Date: 14 Dec 1992 11:26:29 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 14 Dec 1992 11:26:29 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GSAYRUCS2Q8ZKQYJ@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"Shah.Khatri@ASU.Edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> We are translating non-local OfficeVision mail to RFC format through the
> PUMP software, which uses the "X-Acknowledge-To" header.  An OfficeVision
> message that is not converted through PUMP does not seem to have a
> registered mail header at all.  Unmodified OfficeVision messages are Notes
> with Format "MESSAGE."
>
> RiceMail honors the X-Acknowledge-To header.  It ignores
> "Return-Receipt-To."
>
> I was hoping that I could create a mapping in the MAPPINGS file to convert
> from one header to another.  Does this sound plausible?  Maybe there could
> be a mapping table per channel.

No this isn't terribly plausible since you cannot, in general, map between
header lines this way.  Each header line has its own syntax which must be
honored. To map from one header line to another you must know the syntax of
each header line, and you must parse the source header line and convert its
contents to the proper format in the destination header line.  In the most
general setting, this is a very non-trivial task as there are many
issues to consider.

Again, trying to fix this in PMDF seems like the wrong approach to me: I would
think you'd get a lot more mileage handling this problem on the IBM system
since PMDF is not the only mailer which will present the IBM with
Delivery-receipt-to header lines.

> When a delivery receipt is requested, PMDF uses the "Return-Receipt-To"
> header, correct?  What about the ad hoc standard (as you said),
> "Delivery-Receipt-To"?

I was confused, the ad-hoc standard is Return-receipt-to: which is what
PMDF uses out SMTP.  (Internally, PMDF will use Delivery-receipt-to: and
Read-receipt-to:.)

Dan
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Addressing confusion
From: Ned Freed <ned@sigurd.innosoft.com>
Date: 17 Dec 1992 13:25:08 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 17 Dec 1992 13:25:08 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GSF9S45RCI90MYQX@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"BYRD@mscf.med.upenn.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

This behavior is entirely expected and consistent. In general, PMDF only
know about the addresses VMS MAIL passes directly to it. Other addresses
on the VMS MAIL To: and Cc: lines that are passed to other agents are not
part of the information that's passed to PMDF. While PMDF can and does get
copies of the actual To: and Cc: headers from VMS MAIL, there's no way for
PMDF to convert the information it sees on those lines into usable RFC822
addresses. The problem is fundamental; there's too much hidden logic both
in VMS MAIL and in whatever other foreign protocols you happen to use for
PMDF to duplicate it all accurately.

PMDF does scan and reexpand the To: and Cc: lines so it can attempt to match
the RFC822 addresses it has in hand with the headers. This is done so that
there's a chance the addresses will end up on the right header. (VMS MAIL
does not tell PMDF what header a given address came from.) This is all a
very complex process involving close to 1000 lines of code. There are
numerous assumptions and heuristics built into it all where PMDF simply has
no way of duplicating a particular chunk of processing someone else does. As
such, it works fairly well but it isn't perfect by any means.

There is an undocumented channel keyword that tells PMDF to take the
results of the reexpansion of the To: and Cc: headers and attempt to build
reasonable RFC822 addresses from the parts that didn't match PMDF addresses.
This is UNSUPPORTED; it is known to have numerous problems; all of which have
been found to be unfixable. However, if you want to try it, the keyword to
use is addlineaddrs.

In summary, it isn't possible for PMDF to build RFC822 headers that
accurately reflect all the information that was in the original VMS MAIL
headers. This is largely due to the fact that VMS MAIL provides no information
to PMDF other than the original header lines and PMDF-specific addresses
extraced from these headers. We have attempted to duplicate the logic that
is used in an effort to provide this information, but we have found numerous
problems with this approach that are simply intractable. If you want to
use the results of the reexpansion you can do so, but this usage is
unsupported by Innosoft.

				Ned
Newsgroups: vmsnet.mail.pmdf
Subject: Addressing confusion
From: "karen Byrd, Med. School Computer, U of PA"
Date: 17 Dec 1992 14:25 -0500 (EST)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 17 Dec 1992 14:25 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Return-Path: BYRD@mscf.med.upenn.edu
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GSF687MSPU90MY3R@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"ipmdf@ymir.claremont.edu"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT


Is the below a configuration problem? Or am I missing some
subtle logic?



>		The first of the two attached messages shows what I put
>in the To: and CC: fields when I sent it and is the copy that went to the
>second entry in the CC: field. The second attached message is the copy
>that went to the first entry in the CC: field. Note that its To: field is
>empty, whereas it should be EMPTY, and the CC: field is incomplete. I
>think PMDF must be garbling the header.
>
>_______________________________________________________________________________
>From:	MSCF::PRING        15-DEC-1992 15:59:34.04
>To:	EMPTY
>CC:	IN%"Pring@mscf.med", PRING
>Subj:	delete me
>
>
>______________________________________________________________________________
>From:	IN%"PRING@mscf.med.upenn.edu" 15-DEC-1992 15:59:42.96
>To:
>CC:	IN%"Pring@mscf.med.upenn.edu"
>Subj:	delete me
>
>Return-path: <PRING@mscf.med.upenn.edu>
>Received: from mscf.med.upenn.edu by mscf.med.upenn.edu (PMDF #12721) id
> <01GSCML1ZIDS0008US@mscf.med.upenn.edu>; Tue, 15 Dec 1992 15:59 EST
>Date: Tue, 15 Dec 1992 15:59 EST
>From: PRING@mscf.med.upenn.edu
>Subject: delete me
>Cc: Pring@mscf.med.upenn.edu
>Message-id: <01GSCML1ZIDS0008US@mscf.med.upenn.edu>
>X-VMS-To: EMPTY
>X-VMS-Cc: IN%"Pring@mscf.med", PRING
>
>
>_______________________________________________________________________________




	Karen Byrd, VAX Sys. Manager
	University of Pennsylvania
	Medical School Computer Facility
	Philadelphia, PA 19104 (USA)
	Internet: byrd@mscf.med.upenn.edu
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Mailserv subscriptions
From: Stephen Tihor <tihor%nyuacf.bitnet@ymir.claremont.edu>
Date: 18 Dec 1992 16:42:27 -0500 (EST)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 18 Dec 1992 16:42:27 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: ipmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GSGOS78SUQ90N51P@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"DAN@INNOSOFT.COM"
X-Vms-Cc: IN%"ipmdf@ymir.bitnet"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Huh?

A user phil sends mail from pole.nyu.edu his workstation but wants
all his mail to go towards mail.nyu.edu from which it is redirected.
The mailer on his workstation does not support forging the From: address.
So his subscription request would be from phil@polar.nyu.edu but reply-to
phil@mail.nyu.edu.  It would be sent to mailserv@somehwreelse ...
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Stuck msgs in queue for local channel
From: Ned Freed <ned@sigurd.innosoft.com>
Date: 15 Dec 1992 12:16:42 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 15 Dec 1992 12:16:42 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GSCETZVS8Y8ZKMYM@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"bob@camb.com"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Your conversion of the lists sounds fine to me. However, I don't see why
you expected to get anything other than "node::user" stuff as a result. This
is clearly _all_ you're going to get unless the node is known to PMDF.

In any case, I don't think the way you've set up the distribution list has
anything to do with your problems. The problem is your use of MAIL-11, and
in order to fix the hung jobs and such you're going to have to reconsider your
choice of protocols here. I explained in my original response that we're done
a
all we can to cater to MAIL-11 bugs. I'm open to suggestions as to what else
we can do, but I don't think there's much else that's possible.

				Ned
From: operator%wfeb2.bitnet@ymir.claremont.edu (Daphne Yang)
Newsgroups: vmsnet.mail.pmdf
Subject: Help: How to get mail deliver messages for internet nodes?
Date: 17 Dec 92 16:05:48 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 17 Dec 1992 11:05:48 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GSEYYMLLSI90MWR1@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"info-pmdf@ymir.bitnet"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT


We are on both Bitnet and Internet.  Before we joined Internet last month, we
can receive messages dislayed on the screen shown where the mail has been
delivered.  After I adding a channel and installing the slave program
PMDF_ROOT:[EXE]MTCP_SLAVE.EXE to act as TGV MultiNet's SMTP server, now I can
receive deliver messages only when the mail's destination is a BITNET node.
Some of my users REALLY sit in front of the terminal until they saw their mails
been delivered to the destination.  That feature is very important to them.
Can anyone tell me if it is possible to get the deliver messages for all the
addresses(not only Bitnet)?  Is there some kind of switch I need to set?
Thank you very much for your help.



Daphne Yang
System Manager
Worcester Foundation
222 Maple Ave,
Shrewsbury, MA

operator@wfeb2.bitnet
operator@sci.wfeb.edu
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Queued mail messages.
From: "Daniel C. Newman" <dan@innosoft.com>
Date: 14 Dec 1992 10:03:56 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 14 Dec 1992 10:03:56 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GSAVVCQHF68ZLEG8@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"FLEP@NET.CCD.BNL.GOV"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

>>> How can I find out WHY a mail message is being queued??
>>
>>We need a little more context in order to answer this question in a meaningful
>>way.  I.e., does the same message keep on appearing on your system as a new
>>message; is there a message looping around on your system; are there messages
>>seemingly appearing from nowhere; etc.
>>
>
>	When ever I look at the mail queues, with @pmdf_root:[exe]qm
>	all I see are mail messages with sizes and dates. What I would
>	like to know is why a particular message is queued. The "postmaster"
>	sometimes receives copies of mail to various users stating his
>	mail sent is queued for three days and will continue to be queued
>	for "n" more days, the question is WHY is this particular
>	message being queued and resent. Often the user wants to know.

At present you have to look in the log files to determine why PMDF has been
unable to send the message.  There are two primary causes of mail not being
able to be sent: the network is down or the destination host is down.

PMDF V4.2 stores with each message, non-delivery information.  This information
will be sent to the sender along with non-delivery notices.

Dan
Newsgroups: vmsnet.mail.pmdf
Subject: RE: default routing in Jnet V3.6
From: "Terry Kennedy, Operations Mgr" <terry@spcvxa.spc.edu>
Date: 14 Dec 1992 23:42:48 -0500 (EST)
Organization: St. Peter's College, US
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 14 Dec 1992 23:42:48 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: IPMDF@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GSBIF9Z6368ZLJ85@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"KVC@SUMMER.INNOSOFT.COM"
X-Vms-Cc: IPMDF@YMIR.CLAREMONT.EDU,TERRY
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Kevin V. Carosso <KVC@SUMMER.INNOSOFT.COM> writes:

> Depends a bit on what Jnet default routes mean.  If it is purely a Jnet issue
> and has nothing to do with mail, then PMDF won't know or care anything about
> Jnet default routes.  I suspect this is the case.

  Correct. I have been running with default routes on all my BITNET systems
except for my external gateway for at least 6 months with no problems. All
the default route does is tell the local Jnet that "in the absence of an ex-
plicit route for system "X", send it out link "Y". This is useful if you
have a number of Jnet systems, as you only have to update one host's routing
tables. [I suggest that you still run full routes on your external gateway
system(s), as sending traffic for nonexistent nodes to your Jnet neighbors
is (I feel) not polite].

  Since PMDF uses the info in XMAILER.NAMES and DOMAIN.NAMES, it will still
refuse to let you sent to a nonexistent BITNET host, even if a Jnet default
route is configured (as long as you keep those files updated 8-).

	Terry Kennedy		Operations Manager, Academic Computing
	terry@spcvxa.bitnet	St. Peter's College, Jersey City, NJ USA
	terry@spcvxa.spc.edu	+1 201 915 9381
Newsgroups: vmsnet.mail.pmdf
Subject: Did a rewritten "From:" make a message appear forged?
From: Aidan Evans <ae@ac.dal.ca>
Date: 17 Dec 1992 10:46:24 -0400
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 17 Dec 1992 10:46:24 -0400
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GSEWUZSAJ690MWCV@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"ipmdf@ymir"
X-Vms-Cc: AE
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

  One of our users (ECH) got a message that said in the VMS MAIL "From:" line:

        From:   IN%"hannon@ac.dal.ca" 16-DEC-1992 11:55:18.99

and replied to that message.  When user "hannon" got the reply she was
surprised, because she hadn't sent the original message.  She was worried that
someone was forging mail.
  We got ECH to send us the original message he replied to.  The headers,
including VMS MAIL's, looked like this:

From:   IN%"hannon@ac.dal.ca" 16-DEC-1992 11:55:18.99
To:     IN%"ECH@ac.dal.ca"
CC:
Subj:   Beer compatible solder

Return-path: <hannon@sparc3303.cacd.cr.rockwell.com>
Received: from sparc3303.cacd.cr.rockwell.c (sparc3303.cacd.cr.rockwell.com) by
 AC.DAL.CA (PMDF #2545 ) id <01GSDREERFN4001Z65@AC.DAL.CA>; Wed,
 16 Dec 1992 11:28:35 -0400
Received: from pc234sun2601.cacd.cr.rockwell.com ([131.198.60.234]) by
 sparc3303.cacd.cr.rockwell.com (4.0/SMI-4.0) id AA15863; Wed,
 16 Dec 92 09:27:56 CST
Date: 16 Dec 1992 09:25:20 +0000
From: hannon@ac.dal.ca (<hannon@sparc3303.cacd.cr.rockwell.com>)
Subject: Beer compatible solder
To: ECH@ac.dal.ca
Message-id: <QB2F4A61@pc234sun2601>
Content-transfer-encoding: 7BIT

  My theory, based on the domain name "pc234sun2601.cacd.cr.rockwell.com" in
one of the "Received:" lines, is that a badly written PC mail program wrote
the original "From:" line like

        From: hannon (<hannon@sparc3303.cacd.cr.rockwell.com>)

and that PMDF rewrote "hannon" to "hannon@ac.dal.ca".  Is this possible? If
so, is there any way to prevent PMDF from doing this?  I can see it might be
difficult, given that mapping my theoretical "From:" line to VMS MAIL might
produce ``From: IN%"hannon"'' which is not much better than what was done in
the first place.

Aidan Evans (AE@AC.Dal.CA), Computer Facilities & Operations,
University Computing & Information Services, Dalhousie University,
Halifax, N.S., Canada, B3H 4H8