HDTenEightyP/NetNews huggingface dataset:
From: munroe@dmc.com (Dick Munroe)
Newsgroups: vmsnet.mail.mx
Subject: Re: Something is stripping blanks....
Date: 29 Dec 92 13:50:18 EST
Organization: Doyle, Munroe Consultants, Inc., Hudson, MA

In article <1992Dec24.082048.1098@dmc.com>, munroe@dmc.com (Dick Munroe) writes:
> I've performed a series of experiments and something is
> stripping blanks from mail messages:

Well, it was indeed MX, as Earle pointed out.  Specifically it appears to be
MX_RMAIL.  The fix was pretty easy and for those of you with sources the DIFF
to MX_RMAIL.B32 is enclosed.  I've mailed this to Hunter for inclusion in the
next release of MX.

Merry Holidays all.

Dick Munroe
--------------------------------------------------------------------------------
*** mx_rmail.b32.1
--- mx_rmail.b32
**************
*** 1,5
  %TITLE 'MX_RMAIL'
! MODULE MX_RMAIL (IDENT='V1.4-1', MAIN=MX_RMAIL) =
  BEGIN
  !++
  ! FACILITY: 	    MX UUCP interface
--- 1,5 -----
  %TITLE 'MX_RMAIL'
! MODULE MX_RMAIL (IDENT='V1.5', MAIN=MX_RMAIL) =
  BEGIN
  !++
  ! FACILITY: 	    MX UUCP interface
**************
*** 34,39
  !   20-MAY-1991	V1.3-1	Madison	    Check for 822-type address in From_ header.
  !   04-NOV-1991	V1.4	Madison	    Use new RCPTDEF structure.
  !   15-NOV-1991	V1.4-1	Madison	    MEM RCPT rtns.
  !--
  
      LIBRARY 'SYS$LIBRARY:STARLET';
--- 34,41 -----
  !   20-MAY-1991	V1.3-1	Madison	    Check for 822-type address in From_ header.
  !   04-NOV-1991	V1.4	Madison	    Use new RCPTDEF structure.
  !   15-NOV-1991	V1.4-1	Madison	    MEM RCPT rtns.
+ !   27-Dec-1992 V1.5	Munroe	    Do NOT trim blanks from the message when it
+ !				    is put into the message queue!!!
  !--
  
      LIBRARY 'SYS$LIBRARY:STARLET';
**************
*** 373,378
      ELSE
      	STR$COPY_DX (SENDER, %ASCID'<>');
  
      FLQ_ADD (.QAB, NEWENT);
  
      WRITE_INFO (.QAB, NEWENT, %ASCID'SRC_INFO', SENDER, INFOQ,
--- 375,384 -----
      ELSE
      	STR$COPY_DX (SENDER, %ASCID'<>');
  
+     !++
+     ! Add the UUCP message to the router queue.
+     !--
+     
      FLQ_ADD (.QAB, NEWENT);
  
      WRITE_INFO (.QAB, NEWENT, %ASCID'SRC_INFO', SENDER, INFOQ,
**************
*** 390,398
      END;
      WHILE MDM_READF (.UNIT, STR2) DO
      BEGIN
!     	STR$TRIM (STR, STR2);
!     	MDM_WRITEF (.UNIT2, STR);
!     	NEWENT [QENT_L_SIZE] = .NEWENT [QENT_L_SIZE] + .STR [DSC$W_LENGTH];
      END;
      MDM_CLOSEF (.UNIT);
      MDM_CLOSEF (.UNIT2);
--- 396,403 -----
      END;
      WHILE MDM_READF (.UNIT, STR2) DO
      BEGIN
!     	MDM_WRITEF (.UNIT2, STR2);
!     	NEWENT [QENT_L_SIZE] = .NEWENT [QENT_L_SIZE] + .STR2 [DSC$W_LENGTH];
      END;
      MDM_CLOSEF (.UNIT);
      MDM_CLOSEF (.UNIT2);
--------------------------------------------------------------------------------
Dick Munroe				Internet: munroe@dmc.com
Doyle Munroe Consultants, Inc.		UUCP: ...uunet!thehulk!munroe
267 Cox St.				Office: (508) 568-1618
Hudson, Ma.				FAX: (508) 562-1133

GET CONNECTED!!! Send mail to info@dmc.com to find out about DMConnection.
Newsgroups: vmsnet.mail.mx
From: eric@sejnet.sunet.se (Eric Thomas)
Subject: Re: Something is stripping blanks....
Reply-To: ERIC@SEARN.SUNET.SE
Organization: SUNET, Stockholm, Sweden
Date: Fri, 1 Jan 1993 10:23:12 GMT

In article <1992Dec29.183421.22777@news.arc.nasa.gov>, madison@tgv.com (Matt Madison) writes:
> Yes, MX trims trailing blanks.  It does this for two reasons.
> 
>     1.  You have to trim blanks on messages coming in from BITNET.
>         The typical message format there is fixed-length 80-byte records.
> 
>     2.  It saves space on disk.
> 
> The BITNET problem should probably be handled by doing the blank-trimming in
> the MX-Jnet interface ONLY.

And only if the message came in in PUNCH format. Within a few months most of
BITNET (in terms of amount of generated messages, rather than amount of
machines) should be running NETDATA-capable mailers, and there you don't want
to strip spaces. I realize that the JNET interface probably isn't told what
format the file came in, but if the blank line separating the header from the
body is exactly 80 bytes long you can be fairly sure the message was sent in
PUNCH format.

  Eric
From: ake@dayton.saic.com (Earle Ake)
Newsgroups: vmsnet.mail.mx
Subject: Re: Something is stripping blanks....
Date: 26 Dec 1992 15:36:49 -0500
Organization: Science Applications Intl Corp - Dayton, Ohio
NNTP-Posting-Host: dayton.saic.com
X-Newsreader: TIN [version 1.1 PL8]

Dick Munroe (munroe@dmc.com) wrote:
: I've performed a series of experiments and something is
: stripping blanks from mail messages:

: 1. Sent a message containing:

: aaaaaaaaaaa
:            
: bbbbbbbbbbb

: to myself via UUCP%"munroe@dmc.com"

: The "blank" line had been filled with spaces.

: 2. Checked the spool file, it had spaces in it.

: 3. Checked the copy self copy delivered by mail.  IT had spaces
: in it.

: 4. When UUCP/MX delivered the mail, the spaces were gone.

: So a few questions:

: (1) is my experiment bogus?

	No it is not.

: (2) Does DECUS UUCP (or MX, since that's REALLY the entity that
: had the message last) strip blanks?

	It is MX that is doing the stripping.

: (3) Is this behavior legal?

	I don't think so.

: (4) Should it be stopped?

	I had mentioned it to Hunter after I found it.  You can see it also if
you are running MX and not UUCP.  I noticed it with a mail message send via
SMTP and delivered with the traling blanks removed from each line.


-- 
Earle Ake  Internet: <ake@dayton.saic.com>  NSI-DECnet (SPAN): 28276::ake
From: Dan Wing <DWING@UH01.Colorado.EDU>
Newsgroups: vmsnet.mail.mx
Subject: SMTP-over-DECnet security
Date: 29 Dec 1992 15:32:03 -0700 (MST)
Organization: Mx-List<==>Vmsnet.Mail.Mx Gateway
X-Gateway-Source-Info: Mailing List

In the MX version 3.1 manual, section 3.8.1, "Creating a DECnet Object for
DECnet-SMTP", it recommends creating a proxy to allow other systems to use
the username for the SMTP DECnet object on your local node.

Wouldn't this allow a user on the remote system (SYSTEM, or MAILER, or
whatever is the user on the remote system) to get your system to run FAL and
have access to your system, or am I missing something?  It seems more secure
to require the remote system use the normal DECnet login method (the NCP
database supplies the username, password, and the file to execute) -- it
seems like this then locks the remote user into executing the pre-defined
.EXE (or .COM, however you set it up) which can then do nothing more than
deliver mail all over the place.

-Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet (DGW11)
 Systems Administrator, University Hospital, Denver
From: pat@che.phys.Virginia.EDU
Newsgroups: vmsnet.mail.mx
Subject: "error in device name" message on MX 3.1
Date: Tue, 29 Dec 1992 12:22:24 EST
Organization: Mx-List<==>Vmsnet.Mail.Mx Gateway
X-Gateway-Source-Info: Mailing List

I've long been running MX 2.0 on a Vaxcluster, all seven of whose nodes are
currently running VMS 5.5 and CMU-TEK version 6.6-5.  I haven't upgraded MX
for two reasons:  1) "If it ain't broke, don't fix it" and  2) A couple of
previous attempts to upgrade to 3.1 have been unsuccessful.  However, a recent
lack of success on my users' part in sending messages to the CERN particle
accelerator site in Europe (addresses ending in .CH, e.g., joe@foo.bar.ch; the
messages simply vanish and no bounced mail messages are received) is forcing
me to confront this upgrade (to 3.1; unless somebody advises me otherwise,
I'll get 3.1 working first and then worry about 3.1C or whatever is the
current revision) and conquer it by any means necessary, in hopes that the
newer version will have less trouble sending to CERN.

Here's my problem:  I've customized the 3.1 installation for our site (the
ROUTER, LOCAL, and MLF processes all run on 3 of the 7 nodes; SMTP runs on
these 3 plus one other node; and SMTP_SERVER runs on all 7 nodes).  As best
I can tell, I've modified it so it should be configured just as it has been
to successfully run MX 2.0.  I start up MX and all the appropriate processes
start up, and will run until I stop them myself.  However, as soon as I try
to send an outgoing message, I receive the following error:

MAIL> send
To:     mx%"user@site.edu"                 ! dummy user and site, of course
%RMS-F-DEV, error in device name or inappropriate device type for operation

I've checked all of the appropriate logicals I'm aware of (SHOW LOGICAL *MX*
and SHOW LOGICAL *NETLIB*), and as best I can tell they're all defined
properly; i.e., all logicals defined to point to directories or files do so
successfully and MX_INET_HOST, MX_NODE_NAME, MX_SMTP_DEFAULT_ROUTER and
MX_VMSMAIL_LOCALHOST all point to the correct machines.  Does anybody have
any idea what could be wrong here?  Apologies if this is a beginner's question;
I've recently taken over MX duties from the guru who set up 2.0 on this site
and am still on the learning curve.  Also, please let me know if I can supply
additional useful information.  Many thanks in advance.

- Patrick Walsh
  University of Virginia Department of Physics
  pw@virginia.bitnet, pw@virginia.edu, pat@gomez.phys.virginia.edu
From: "Bob Johns, (604)363-6520" <bob@ccs.ios.bc.ca>
Newsgroups: vmsnet.mail.mx
Subject: Re: Picky logical name translation
Date: Thu, 31 Dec 1992 09:17:51 PST
Organization: Mx-List<==>Vmsnet.Mail.Mx Gateway
X-Gateway-Source-Info: Mailing List

I don't have any information to offer concerning an MX -> Message Router
gateway.  But as I indicated in a previous posted note, I am very
interested in a proper implementation.  By that, I mean one that:

   - does not require any non-standard workarounds
   - behaves in an analagous way to MRGATE for SMTP to Message Router
     and equally Message Router clients (e.g. Mailworks for Windows)
     to SMTP
   - uses analagous addressing to that used for MRGATE
     (e.g.  Mailworks client to SMTP:  user@mxgate@host.domain,
     or SMTP to Message Router on same system:  mxgate::"am::user")

Having said the above, however, the primary need is for a Message Router
to SMTP (i.e. to MX) gateway that would allow Message Router clients to
send outgoing SMTP mail.  Incoming SMTP mail can always be routed into
Message Router by setting the appropriate forwarding address within VMSmail.
So altho it would be nice to have a bi-directional gateway, only the
one direction is critical.

Bob Johns  (bob@ios.bc.ca)
Manager, Central Systems & Networks
Scientific Computing
Institute of Ocean Sciences
Sidney, B.C.  Canada
From: Paul Simons <yale!nuconvex.com!simonpg@harvard.harvard.edu>
Newsgroups: vmsnet.mail.mx
Subject: Picky logical name translation
Date: Wed, 30 Dec 1992 18:22:21 EST
Organization: Mx-List<==>Vmsnet.Mail.Mx Gateway
X-Gateway-Source-Info: Mailing List

I finally made some time to get MX 3.1c up and running.  I'm going to write a
gateway between MX and DEC's Message Router.  Any input would be appreciated.
I have successfully transferred messages from MX to ALL-IN-1 using addresses
like <blah@a1.mbus.nuconvex.com>.  I defined the logical mx_event_oper_class
to be "network", and all the MX processes died:

%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=244D4E4C,
PC
=00050F07, PSL=03C00001
%TRACE-F-TRACEBACK, symbolic stack dump follows
module name     routine name                     line       rel PC    abs PC

                                                           00050F07  00050F07
                                                           00050E66  00050E66
MX_ROUTER       READ_CONFIG                       288      000000C4  000020A5
MX_ROUTER       MX_ROUTER                         102      00000045  00001C45

When I took away the quotes, all was well!

Paul Simons             simonpg@nuconvex.com
                        yale!nuconvex!simonpg
                        uunet!hsi!nuconvex!simonpg

CONnecticut Valley Electric eXchange
From: hunterl@uwwvax.uww.edu
Newsgroups: vmsnet.mail.mx
Subject: error message
Date: Wed, 23 Dec 1992 07:04:53 CST
Organization: Mx-List<==>Vmsnet.Mail.Mx Gateway
X-Gateway-Source-Info: Mailing List

Does any one the reason the following error message occurs:
%NONAME-E-NOMSG, Message number 08638182
It is reproducible at our site on mail to almaden.ibm.com

Lyle Hunter
Computer Center
University Wisconsin-Whitewater
hunterl@uwwvax.uww.edu
From: Peter Kobe <system@PIB1.physik.uni-bonn.de>
Newsgroups: vmsnet.mail.mx
Subject: RE: error message
Date: Wed, 30 Dec 1992 11:34:59 MEZ
Organization: Mx-List<==>Vmsnet.Mail.Mx Gateway
X-Gateway-Source-Info: Mailing List

Lyle Hunter hunterl@uwwvax.uww.edu aks:

>Does any one the reason the following error message occurs:
>%NONAME-E-NOMSG, Message number 08638182
>It is reproducible at our site on mail to almaden.ibm.com

This Code is given by CMU??? DSFMTERR Domain service:
                                        domain server returned format error

Peter
=====================================================================
Peter Kobe                      Internet: system@pib1.physik.uni-bonn.de
Physikalisches Institut           HEPNET: 13562::SYSTEM
Universitaet Bonn                    Tel: (49) 228 73 3222
D 53 Bonn                            FAX: (49) 228 73 7869
Nussallee 12
Newsgroups: vmsnet.mail.mx
From: madison@tgv.com (Matt Madison)
Subject: Re: Something is stripping blanks....
Reply-To: madison@tgv.com
Organization: The Foundation for Dinner Peas
Date: Tue, 29 Dec 1992 18:34:21 GMT

Yes, MX trims trailing blanks.  It does this for two reasons.

    1.  You have to trim blanks on messages coming in from BITNET.
        The typical message format there is fixed-length 80-byte records.

    2.  It saves space on disk.

The BITNET problem should probably be handled by doing the blank-trimming in
the MX-Jnet interface ONLY.  And saving disk space is probably not as
important as retaining message integrity.  It typically isn't harmful,
though.

You should not expect trailing blanks to be retained on any message you
send, however, in case it has to pass through a network and/or system
that does blank-trimming.

-Matt
--
Matthew Madison | madison@tgv.com    | +1 408 427 4366
TGV, Inc.       | 603 Mission Street | Santa Cruz, CA 95060 USA
Newsgroups: vmsnet.mail.pmdf
Subject: RE: MIME support for fax
From: Ned Freed <ned@innosoft.com>
Date: 31 Dec 1992 02:29:41 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 31 Dec 1992 02:29:41 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GT0OVLOYO090OARS@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"emv@msen.com"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

I'm not sure whether or not PMDF-FAX meets your requirements for "faxes
through e-mail"; perhaps I'd best just say what it is that PMDF-FAX does
do.

PMDF-FAX is a set of channel programs for PMDF that provide facilities for
converting text, PostScript, and various other formats into Group 3 FAX,
as well as a set of programs that take these Group 3 FAX files and use
them to drive a variety of FAX modems. Facilities for receiving FAXes from
the modems that are capable of FAX receive and conversion of these materials
into various formats (PostScript, TIFF, GIF, PCL, etc.) are also provided.
Received FAXes can be printed, delivered to files, or automatically forwarded
on as mail messages.

None of this really involves "faxes through e-mail", however. PMDF-FAX can
and has been used to convert mail messages into FAX images which were then
sent via e-mail to another sort of FAX gateway, but usage of this sort is
quite rare. Most people want a way to convert mail messages into real
FAXes and vice versa, and that's what PMDF-FAX is aimed at.

MIME is used throughout to provide type information, multipart facilities,
and so forth. PMDF-FAX was developed with MIME in mind from the outset.
Tricky stuff like automatic defragmentation of message/partial objects is
supported and works quite well (this is actually a feature of PMDF rather
than being specific to PMDF-FAX). And of course the MIME transfer encodings
provide an effective means of dealing with binary message bodyparts.

All of this functionality has been available for some time in the form of
a commercial product -- we released a fully MIME compliant version of
PMDF and PMDF-FAX right at the time MIME appeared as a proposed standard.
Of course development is ongoing: a new version of PMDF and PMDF-FAX is
currently in field test, and it displays the usual feature-creep you'd
expect (support for more formats, better conversion facilities, improved
PostScript fonts, support for more modems, etc. etc. etc.).

				Ned
Newsgroups: vmsnet.mail.pmdf
Subject: RE: mailserv `unauthorized' rejection msgs
From: Bob Tinkelman <bob@camb.com>
Date: 31 Dec 1992 08:41:15 -0400 (EDT)
Organization: Cambridge Computer Associates, Inc.
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 31 Dec 1992 08:41:15 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GSYDNQ3KUA8WVYUZ@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

> The proper choices of addresses for authorization checking are all
> described in RFC822. Specifically, the Sender: address is used if
> present, and failing that the From: address is used.

I figured out my error.  I was trying to be fancy and
  (1) have the mailserv_access mapping refer to a mailing list, and
  (2) use subaddresses in the mailing list.

It seems that if the authorization file contains bob+other-stuff@camb.com
then bob@camb.com doesn't match and isn't considered authorized.  I guess
this is expected behavior.

Is there a reasonable way for me to use subadresses in a mailing list and
still use that list as the basis of authorization tests?  (My first
thought was to run a daily batch job that converts the mailing list into
an authorization list, stripping the subaddressing, but I really don't
want to get into parsing rfc822 addresses.)
Newsgroups: vmsnet.mail.pmdf
From: gmacdougall@TrentU.CA
Subject: MAILSERV
Reply-To: gmacdougall@TrentU.CA
Organization: Trent University, Peterborough
Date: Tue, 22 Dec 1992 16:15:15 GMT



	I just set up a mailing-list and have been interested in the recent 
thread on MAILSERV and command access. The recent info on the mapping file 
seemed helpful until I tried to implement it. I'm running PMDF 4.1 on VMS 5.4
with dead simple non-compiled pmdf.cnf file (Single off campus Multinet 
Channel). Can somebody please point me at the correct documentation, section 
3.4.1 Locating and Loading the mapping file - says "This file is read once 
during program initialization and loaded into an internal string table."  
Unfortunately this doesn't make sense to me. I have created a mappings file 
which is pointed to by pmdf_mappings_file but the contents do not seem to 
affect the behaviour of my mailserv. 
	I do have the mailserv working as far as subscribe, unsubscribe and 
use of the mailing list goes but I am trying to get send/list and subscribe 
for a third party working for sysop types.

	thanks inadvance,

							George MacDougall
							gmacdougall@trentu.ca
							
	Computing and Telecommunications Department - (705) 748-1602
        Trent University - Peterborough, Ontario - K9J 6S2
Newsgroups: vmsnet.mail.pmdf
Subject: RE: MAILSERV
From: "Daniel C. Newman" <dan@innosoft.com>
Date: 22 Dec 1992 17:55:37 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 22 Dec 1992 17:55:37 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GSMIPW6I1E90NK0J@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"gmacdougall@TrentU.CA"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> 	I just set up a mailing-list and have been interested in the recent
> thread on MAILSERV and command access. The recent info on the mapping file
> seemed helpful until I tried to implement it. I'm running PMDF 4.1 on VMS 5.4
> with dead simple non-compiled pmdf.cnf file (Single off campus Multinet
> Channel). Can somebody please point me at the correct documentation, section
> 3.4.1 Locating and Loading the mapping file - says "This file is read once
> during program initialization and loaded into an internal string table."
> Unfortunately this doesn't make sense to me. I have created a mappings file
> which is pointed to by pmdf_mappings_file but the contents do not seem to
> affect the behaviour of my mailserv.

I don't know how to make the sentence,

   This file is read once during program initialization and loaded...

any clearer without expending four or five sentences.  Only possible rewording
I can imagine is to say "image activation" in place of "program
initialization".  All that is being stated here is that the mapping file is
loaded when a program begins running.

>	I do have the mailserv working as far as subscribe, unsubscribe and
> use of the mailing list goes but I am trying to get send/list and subscribe
> for a third party working for sysop types.

What are the errors you're getting?  You've doubled check to insure that you
do not have a compiled configuration (issuing the command "$ DIRECTORY
PMDF_CONFIG_DATA reveals no files)?  Also, did you make sure that the mapping
file is world readable?  You can test the mappings with PMDF TEST/MAPPING

   $ pmdf test/mapping
   Enter mapping name: MAILSERV_ACCESS
   Input string: SENDLIST|dan|ned@sigurd.innosoft.com
   Output string:
   Output flags: [0,89]
   Input string:

The output flags indicate the ASCII index of any metacharacters (e.g.,
$Y = 89).

Dan
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Hung vn_xxxx jobs
From: Ned Freed <ned@innosoft.com>
Date: 21 Dec 1992 11:34:15 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 21 Dec 1992 11:34:15 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GSKRWWVYMQ90NDQS@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

PMDF wakes UUCP by writing to a mailbox. If the mailbox is full PMDF will
indeed hang at this point. This is expected bahavior. You should be able to
clear the condition by restarting UUCP from ground zero and killing all the
PMDF jobs that are hung.

				Ned
Newsgroups: vmsnet.mail.pmdf
Subject: Talking about MCI, how about a SprintMail PMDF interface?
From: Ken Harris <harris@si-bas.si.com>
Date: 22 Dec 1992 10:39:05 +0000 (GMT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 22 Dec 1992 10:39:05 +0000 (GMT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GSLP1PQW4Y90NH1H@YMIR.CLAREMONT.EDU>
X-Vms-To: MAILGATE::"info-pmdf@ymir.claremont.edu"
X-Vms-Cc: HARRIS
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

>
> does PMDF have a way to talk directly to mcimail?
>
> --
> --- bob pasker
> ---- rbp@netcom.com

Going further... does PMDF have a way to talk to SprintMail?  We are hoping to
become a X.400 PRMD off TMAILUK (Sprint aka Telemail, in the UK) but in the
meantime are using the PC Sprintmail package via dial-up to access mailboxes on
the SprintMail host.  Lotus have a cc:Mail to SprintMail gateway product that
uses cc:Mail import/export much like the PMDF to cc:Mail gateway but it's
pricey and does not support binary attachments (strange because the cc:Mail to
MCI mail gateway DOES).  Looks like it would need a combination of the PMDF
cc:Mail gateway code plus some dialling code from PhoneNet and some...

Any ideas?  BTW the Lotus product SEEMS to only need ONE mailbox on SprintMail
to serve multiple real local users; sounds clever.

Ken
________________________________________________________________________________
Ken Harris                                         | Tel: +44-256-349422
Smiths Industries Aerospace                        | Fax: +44-256-844434
Basingstoke RG22 6HP                               | PSI: 234225600152::HARRIS
UK                                                 | harris@si-bas.si.com