From:	CRDGW2::CRDGW2::MRGATE::"SMTP::YMIR.CLAREMONT.EDU::POSTMAST"  8-JAN-1990 08:39
To:	MRGATE::"ARISIA::EVERHART"
Subj:	RE: PMDF mail files.

Resent-From: postmast@YMIR.CLAREMONT.EDU
Received: from HMCVAX.BITNET by YMIR.BITNET; Sat, 6 Jan 90 04:57 PST
Resent-Date: Sat, 6 Jan 90 04:59 PST
Date: Sat, 6 Jan 90 04:57 PST
From: "Ned Freed, Postmaster" <ned@YMIR.CLAREMONT.EDU>
Subject: RE: PMDF mail files.
Resent-To: INFO-PMDF-LIST3@YMIR.CLAREMONT.EDU
To: DMPM@DUKEMC.BITNET, INFO-PMDF@YMIR.CLAREMONT.EDU
Errors-To: postmast@YMIR.CLAREMONT.EDU
Resent-Message-Id: <FA35A55143BF4003E6@YMIR.BITNET>
Message-Id: <FA3607A8BD9F0001B2@HMCVAX.BITNET>
X-Vms-To: IN%"DMPM@DUKEMC.BITNET"
X-Vms-Cc: IPMDF

Bob Tinkelman writes:

> One of the problems with the UUCP to PMDF direction is that  PMDF does not
> realize that the body of the message has 822 header lines.  (UUCP, like
> PMDF, had nothing better it could do with these when delivering to VMSmail.)
> These header lines then remain as part of the body text.

> Now PMDF has some `smarts' in recognizing mail from itself on the local
> channel, to avoid doing this sort of thing.  One example is mail that
> arrives from PMDF to a VMSmail account where the user has set forwarding to
> in%something.

> Is there a way to tell PMDF that mail received on the local channel from
> UUCP%anything has 822 mail headers at the start of its text?  Is there 
> another way to address this problem?

and James Dryfoos writes:

> IS there a way with PMDF to do the following?
     
> I want to be able to create a file that contains a mail header (rfc822?),
> followed by a blank line, and then a mail message.  Then I want to be
> able to hand this file to PMDF to process as though it was mail from
> the local system.  The problem with using VMS mail to send mail
> to PMDF is that I cannot include all the header information I want (VMS mail
> only has TO: CC: FROM: and SUBJ:).  I realize that you
> can do some things with logicals but this is still not enough.  I really
> need to be able to create my own headers.
> If this cannot be done with PMDF as it is now I would appreciate any help
> in how I can make this work.  This will not be something that the users will
> be doing so it does not have to be glamorous nor pretty.
> Please let me know one way or another.
> If it makes a diff PMDF uses the BITnet channel and the CMU tcp/ip channel
> as well as the LOCAL VMS mail channel.

These are both requests for basically the same thing. It has come up before,
but no general mechanism was ever added to deal with it. I think the time has
come to add one. It is a generalization of the mechanism used by PSIPMDF (a
special interface between PSImail and VMS MAIL that uses hooks into PMDF to
translate PSI DTEs into reasonable domain names).

PSIPMDF uses a special call into the PMDF foreign protocol image to accomplish
its task. This is not generally exploitable by other foreign protocol
transports. So I've added a special logical, PMDF_RELAYING, which when defined
will tell PMDF to (1) Use the translation of PMDF_RELAYING to compose a proper
Received: line, (2) Copy the header at the top of the incoming message into the
outgoing message, and (3) Inhibit the addition of Date: and To: header lines if
they are already part of the header. 

PMDF_RELAYING must be an executive mode logical in order to be effective. This
restriction is imposed to stop casual users from forging message headers with
this interface. If you don't want an additional Received: line, simply
equate PMDF_RELAYING to a single space.

The following DIFFerences listing shows the changes needed in PMDF_MAIL.PAS to
make this work. Once again I'm not assigning this a bug-fix number since it is
a more-or-less untested enhancement and not a bug fix.

				Ned

************
File PMDF_COMMON:[SRC]PMDF_MAIL.PAS;114
  853       welcome_file : text; stat : integer; mode : [byte] 0..255;
  854       welcome_line, relaying_line : string;
  855   
******
File PMDF_COMMON:[SRC]PMDF_MAIL.PAS;108
  842       welcome_file : text; welcome_line : varying [256] of char; stat : integer;
  843   
************
************
File PMDF_COMMON:[SRC]PMDF_MAIL.PAS;114
  911     stat := $TRNLOG (lognam := 'PMDF_RELAYING',
  912                      rslbuf := relaying_line.body,
  913                      rsllen := relaying_line.length,
  914                      acmode := mode);
  915     (* Check for relay operation requested by logical name assignment. *)
  916     if odd (stat) and (stat <> SS$_NOTRAN) and (mode = 1) then begin
  917       header_already_there := relayed;
  918       if relaying_line[relaying_line.length] = ' ' then
  919         relaying_line.length := pred (relaying_line.length);
  920       if relaying_line.length > 0 then begin
  921         save_recvd.body := relaying_line.body;
  922         save_recvd.length := relaying_line.length;
  923         os_cnvtdate (save_recvd);
  924       end;
  925     end;
  926     if mm_status = uninitialized then
******
File PMDF_COMMON:[SRC]PMDF_MAIL.PAS;108
  899     if mm_status = uninitialized then
************
************
File PMDF_COMMON:[SRC]PMDF_MAIL.PAS;114
 1233     if (header_already_there = relayed) and (save_recvd.length > 0) then 
 1234       do_hdr1 (save_recvd, he_received, he_received);
******
File PMDF_COMMON:[SRC]PMDF_MAIL.PAS;108
 1206     if header_already_there = relayed then 
 1207       do_hdr1 (save_recvd, he_received, he_received);
************
