HDTenEightyP/NetNews huggingface dataset:
From: dan@innosoft.com (Daniel C. Newman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Help: mapping file for VMS addresses
Date: 18 Nov 92 02:39:53 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 17 Nov 1992 19:39:53 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GR9Q5I216Q8ZHQN5@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"martinez@iris-dcp.es"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> According to the manual, I have created a PMDF_MAPPING_FILE that reads
>
> ...
>
> PMDF-TO-VMSMAIL
>
>    PSI$%IBERPAC.*                        PSI$%ARTIX.$0$>
>
> ...

     There are two typos in the documentation.  First, notice how the second
paragraph of item 2. gives the table name as "PMDF-TO-VMSMAIL" although the
discussion is "VMSMAIL to PMDF" and the example table shows "VMSMAIL-TO-PMDF"?
Well, the correct table name is indeed "VMSMAIL-TO-PMDF".

     Now, notice how in the second paragraph the format

         channel_name|address

is given.  However, the example does not use this format.  Well, in this
regard the example is incorrect.

     So, your table should look like

       VMSMAIL-TO-PMDF

         d|PSI$%IBERPAC.*                 PSI%ARTIX.$0$>

Do not use "$%" in the right hand side.  It isn't obvious that you shouldn't
do this.  I'll look into making PMDF V4.2 treat $% and $* in the right hand
side as % and *.


     You can test your mapping as follows:

       $ pmdf test/mapping
       Enter mapping name: VMSMAIL-TO-PMDF
       Input string: d|PSI%IBERPAC.xxx
       Output string: PSI%ARTIX.xxx
       Output flags: [0,62]
       Input string: ^Z
       $

     Note that if you use a compiled configuration, then you must recompile
and reinstall before your mapping file (or changes to it) will be seen by PMDF.
If you have PMDF V4.1-6 or earlier, two bugs prevent you from being able to
use mapping files with compiled configurations.  If you have 4.1-7, then use
the command

       $ PMDF CNBUILD/OPTION

to compile your configuration.  If you have 4.1-8 or later, then none of these
problems affect you.  You can type out the file PMDF_ROOT:[EXE]IDENT.OPT to
determine which revision level of PMDF you have.  If you have 4.1-6 or earlier,
and are using a compiled configuration, then let me know and we will arrange
to get you an updated tape.

Dan
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Sudden switchover to JNET protocol...
From: Ned Freed <ned@innosoft.com>
Date: 23 Nov 1992 10:20:22 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 23 Nov 1992 10:20:22 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GRHKGSZT6A8ZILJ3@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"SYSMARK@minna.iit.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

One additional point. In order to restart PMDF to its proper role in handling
the delivery of Jnet mail you need to stop and restart processing for your
local link in JCP. This corresponds to using the STOP command (with the
local node as a parameter), waiting a bit, and then using the START command
(same parameter).

				Ned
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Memory leak in process symbiont?
From: "Daniel C. Newman" <dan@innosoft.com>
Date: 18 Nov 1992 16:42:41 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 18 Nov 1992 16:42:41 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GRAYABVRXE8ZI00F@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"C.Chaundy@its.unimelb.EDU.AU"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> We are using the PMDF process symbiont under V4.1-13 to run three PMDF
> server queues and have been having a problem where occasionally the queues
> stop.  The error messages that appear in the operator log file are:

This description sounds just like the bug which was fixed prior to -13.
The error messages you sent also support this conclusion.  Could it be that
when you put -13 up that you did not copy the latest version of the symbiont
to SYS$SYSTEM?  Or if you did, then is perhaps an older version of the
symbiont in a specific directory of SYS$SYSTEM overriding the newer version.

You can get the latest copy of the symbiont via anonymous FTP to
thor.innosoft.com.  Look in the [.pmdf_patches] subdirectory.  If you are
indeed using the latest version and still experiencing this problem, then
send e-mail to service@innosoft.com and we'll take it from there.

Dan
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Multinet TCP/IP parameter settings
From: <adelman@tgv.com>
Date: 20 Nov 1992 14:56:22 -0800 (PST)
Reply-To: <Adelman@TGV.COM>
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 20 Nov 1992 14:56:22 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: ipmdf@INNOSOFT.COM, service@TGV.COM
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GRDNB3R48Y9AMLKW@INNOSOFT.COM>
X-Vms-To: IN%"S.ROSS@CGNET.COM"
X-Vms-Cc: IN%"ipmdf@INNOSOFT.COM", IN%"service@TGV.COM"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> Lately some hosts have been unable to connect to our Multinet TCP/IP
> channel.  Currently the multinet/configure utility shows the
> following parameters:

> SERVER-CONFIG>sho smtp /full
> Service "SMTP":
>	  TCP socket (AF_INET,SOCK_STREAM), Port 25
>	  Socket Options = SO_KEEPALIVE
>	  INIT() = TCP_Init
>	  LISTEN() = TCP_Listen
>	  CONNECTED() = TCP_Connected
>	  SERVICE() = Run_Program
>	  Program = "PMDF_ROOT:[EXE]MTCP_SLAVE.EXE"
>	  Working Set = 400
>	  Max Servers = 2
>	  Backlog = 2

> We are interested in increasing the last two, Max Servers and Backlog to
> allow more SMTP slave processes to be running simultaneously and to allow
> more calling machines to be queued while waiting for one of the processes
> already running to finish.

> We have a 9600 bps compressed SLIP line to the internet and we're running
> PMDF 4.1-13 and Multinet 3.0.

> Can anyone recommend appropriate settings for these parameters that allow
> more calls to come in at once?  Is it better to increase Max Servers or
> Backlog or both?

    You really want to increase MAX-SERVERS.

								    Ken
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Multinet TCP/IP parameter settings
From: "Kevin V. Carosso" <kvc@summer.innosoft.com>
Date: 20 Nov 1992 23:14:22 -0800 (PST)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 20 Nov 1992 23:14:22 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: service@tgv.com
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GRE4HWEW1U8ZF2NM@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"S.ROSS@CGNET.COM"
X-Vms-Cc: info-pmdf, in%"service@tgv.com"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

You probably want to increase both maxservers and backlog.

	/Kevin Carosso
	 Innosoft
Newsgroups: vmsnet.mail.pmdf
Subject: RE: ccMail question
From: "Daniel C. Newman" <dan@innosoft.com>
Date: 19 Nov 1992 11:35:32 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 19 Nov 1992 11:35:32 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GRC2C80Z9U8ZI1CP@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"MAC@gvg34.gvg.tek.com"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> Yes, I had added a ``linelength 80'' to the ccMail channel.  I had
> several complaints about ccMail messages from the VAX appearing as
> attachments that had to be double clicked on to be read.  I attempted
> to resolve the problem before I read the documentation by adding the
> linelength keyword to the ccMail channel.  Then I read that PMDF was
> sending messages with lines longer than 80 characters as attachments
> as part of the normal channel processing.  But of course, I did not go
> back on change my configuration, because it looked like that was the
> default action of the channel anyway.

The problem is that cc:Mail has some limitations on the length of lines in
messages.  So you have two choices: do nothing in which case PMDF has to stuff
the message into a cc:Mail file attachment which doesn't have the line length
limitation, or tell PMDF that there is a line length limitation in which case
PMDF will wrap the lines using the MIME quoted printable encoding.

You may wish to take up with Ned the possibility of having an option or
something for the cc:Mail channel which says to just blindly wrap long lines
rather than resort to a file attachment.  (Ned is away this week at IETF.)

Dan
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Errors in MAILSERV command processing
From: Ned Freed <ned@innosoft.com>
Date: 20 Nov 1992 06:28:34 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 20 Nov 1992 06:28:34 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GRD5CWU7NM8ZI0W5@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"SUE@A1.PSUPEN.PSU.EDU"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

This is almost certainly a problem with the definition of the
PMDF_MAILSERV_MAIL_DIR logical name. Check the definition and make sure
it points at a valid directory containing the .DIS files for your various
mailing lists. You should also enable master_debug and check out the
processing log for the mailserv channel to track these sorts of things
down more precisely.

				Ned
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Incoming notification From: prefix = SMTP%
From: Ned Freed <ned@innosoft.com>
Date: 20 Nov 1992 06:40:30 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 20 Nov 1992 06:40:30 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GRD5RR912A8ZHZRK@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"SETH@SPEECH.MIT.EDU"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

When you change TCP/IP packages you also have to reconfigure PMDF and the new
TCP/IP to make things work properly again... None of this is automatic. In
particular, you have to change your PMDF channels to be mtcp_* instead of
ctcp_* _and_ you have to configure the Multinet server process per the
documentation. Failure to do this will mean that Multinet will deliver its
own mail, bypassing PMDF and causing you to get SMTP% prefixes.

				Ned
From: dan@innosoft.com (Daniel C. Newman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Bad return address
Date: 18 Nov 92 19:03:58 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 18 Nov 1992 12:03:58 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GRAOIYX1K28ZHW1B@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"cvm@NAUVAX.UCC.NAU.EDU"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> I have a problem with MS-Mail not using the correct address when
> replying to a message from a POP3 client whose mail address is on our
> VAX.  I have a copy of the queued message on the VAX before it gets sent
> to the MS-Mail system.  All other machines that the POP client sends to,
> reply to CVM@NAUVAX.UCC.NAU.EDU.  The MS-Mail system replies to
> CVM@PC19.UCC.NAU.EDU.  Before I go to Microsoft or the MS-Mail
> discussion list, I need to know is what the first line in this file is
> used for.  That is the line that says:
>
> m;cvm@pc19.ucc.nau.edu

This first line is the envelope From: address.  The lines immediately following
it up until the control A's are the envelope To: addresses.  In the SMTP session
this information is used in the MAIL FROM and RCPT TO commands; e.g.,

  HELO xxxx
  MAIL FROM:<cvm@pc19.ucc.nau.edu>
  RCPT TO:<cvm@msmail.ucc.nau.edu>

> What does PMDF use this for when communicating with the MS-Mail
> SMTP gateway?  Here is the queued message that causes the problem:

Now, I have no idea what MS-Mail is doing with the envelope From: address.  I
could conjecture all sorts of things, but they'd be merely conjectures.  You
need to find out from the MS-Mail discussion list what MS-Mail uses for a
reply address.  It probably has some sort of precedence list (i.e., first
choice is Resent-reply-to:, second choice Resent-From:, third Reply-to:, etc.)
I've seen all sorts of behavior: some just plain wrong (e.g., using the
envelope From: address as the reply address; building a Reply-to: address out
of the envelope From: address) and others not as black-and-white wrong but
certainly not in alignment with common practice (e.g., using a Return-path:
address preferentially over a From: address; the Return-path: address is
built by the final transport system which delivers the mail to the recipient;
it is usually built from the envelope From: address).

Dan
Newsgroups: vmsnet.mail.pmdf
Subject: MAILSHR.EXE patch for VMS 5.5-2?
From: Greg Isett <gwi@icf.hrb.com>
Date: 20 Nov 1992 15:15:44 -0500 (EST)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 20 Nov 1992 15:15:44 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GRDHIMMH5U8ZIB8N@YMIR.CLAREMONT.EDU>
X-Vms-To: IPMDF@YMIR.CLAREMONT.EDU
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

I have been using a widely available patch for MAILSHR.EXE that allows
it to accept most rfc822 type mail addresses and surround them by IN%"".
This patch worked up to VMS 5.5-1.  After we installed VMS 5.5-2 this
patch no longer works.  I suspect the internal addressing of MAILSHR have
changed.

Has anyone gotten this to work on 5.5-2?

-------------------------------------------------------------------------------
Greg Isett				Internet: gwi@icf.hrb.com
HRB Systems				FAX	: (814)234-7720
300 Science Park Road			Voice	: (814)238-4311
State College, Pa. USA 16804-0060
-------------------------------------------------------------------------------
Newsgroups: vmsnet.mail.pmdf
Subject: Incoming notification From: prefix = SMTP%
From: seth@speech.mit.edu
Date: 19 Nov 1992 21:58:25 -0500 (EST)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 19 Nov 1992 21:58:25 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GRCHANU1J68ZI6OC@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"IPMDF@YMIR.CLAREMONT.EDU"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
X-Vmsmail-To: NETMAIL"IPMDF@YMIR.CLAREMONT.EDU"

Hi,
	A while back I posted a note concerning occasional file
create errors of the following form:

%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

	It turned out that we were mixing IN% and SMTP% protocols
in a given MAIL session. Simply requiring the use of only one
of these form solved the problem, but in hindsight brings up an
interesting question.

	Why would all incoming mail on a machine newly updated
from CMU TCP/IP to Multinet suddenly start using the SMTP prefix
on ALL incoming Internet mail? I don't seem able to determine the
cause of this change. As far as I know, it was nothing I did during
the switch from CMU to TGV code, at least knowingly... :-)


                                Thanks in advance,

                                                Seth Hall
                                                Systems Manager
                                                Speech and Sensory
                                                 Communications Groups
                                                MIT, Cambridge
Newsgroups: vmsnet.mail.pmdf
Subject: Alias, reply address problem.
From: "James D. Dryfoos" <dryfo001@deneb.mc.duke.edu>
Date: 19 Nov 1992 11:09:14 -0500 (EST)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 19 Nov 1992 11:09:14 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: James Dryfoos <dryfo001@deneb.mc.duke.edu>
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GRBUVJAXG29AMKSV@INNOSOFT.COM>
X-Vms-To: IN%"ipmdf@INNOSOFT.COM"
X-Vms-Cc: IN%"dryfo001@deneb.mc.duke.edu"  "James Dryfoos"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: 7BIT


Below is an error I got replying to a message I received. I realize why I got
the error.  In PMDF on our vax (DUKEMC) I have put in an alias for dryfo001 and
pointed it to dryfo001@deneb.mc.duke.edu (my workstation).

This has worked fine for some time.  However, just found a case where it does
not.  Someone sent me mail from a Bitnet node (DUKEMVS) to dryfo001@dukemc.  My
alias forward sent it to me at deneb.mc.duke.edu, but the return address was
setup so that it would only work we replying through the PMDF system (which it
was not) -- i.e. user@node.bitnet.  Normal SMTP internet mail works fine as my
reply goes directly to the sender and not through PMDF.  I suspect I need a
rewrite rule or something to prevent this?  Am I doing something I am not
supposed to? On systems connected to the PMDF system, I want replies to go
through our Bitnet connection, but for cirumstances such as this, we need to go
through an SMTP/Bitnet gateway or back through the PMDF system?

Thanks in advance,

--Jim Dryfoos

---------- Forwarded message ----------
Date: Thu, 19 Nov 1992 11:06:53 -0500
From: MAILER-DAEMON@deneb.mc.duke.edu
To: dryfo001@deneb.mc.duke.edu
Subject: Returned mail: Host unknown

   ----- Transcript of session follows -----
550 dukemvs.bitnet (tcp)... 550 Host unknown
554 WEINER6@DUKEMVS.BITNET... 550 Host unknown (Authoritative answer from name server)

   ----- Unsent message follows -----
Date: Thu, 19 Nov 1992 11:03:39 -0500 (EST)
From: "James D. Dryfoos" <dryfo001>
Subject: Re: BBS access
To: WEINER6@DUKEMVS.BITNET
Message-Id: <Pine.3.05.9211191138.E933-b100000@deneb.mc.duke.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



On 19 Nov 1992 WEINER6@DUKEMVS.BITNET wrote:

message deleted...
From: sue@a1.psupen.psu.edu (Sue Ake (814) 863-2524)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Errors in MAILSERV command processing
Date: 20 Nov 92 15:18:00 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 20 Nov 1992 10:18 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GRD7KTRH028ZI6VE@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"ipmdf@YMIR.CLAREMONT.EDU"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Posting-Date: 20 Nov 1992 10:21 -0500 (EST)
Importance: normal
Priority: non-urgent
X-Hop-Count: 1
A1-Type: MAIL


Thanks, Ned.  That was it!  The old unsupported documentation says to define
the mailserv logicals in master.com.  When I upgraded, the old master.com was
wiped out, of course, leaving me with no logicals.

Sue
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Working with MR "flags" like sensitivity in PMDF-MR
From: "Daniel C. Newman" <dan@innosoft.com>
Date: 19 Nov 1992 15:08:43 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 19 Nov 1992 15:08:43 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GRC98PNV2A8ZHVGC@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"BOWMAN_BRETT_E@LILLY.COM"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> Our company is evaluating migrating users to DEC's Mailworks.  We currently use
> a gateway machine to connect to the Internet and exchange mail between the
> Internet and our internal mail network using PMDF and PMDF-MR.
>
> We have a mechanism in place to control who can send messages out onto the
> Internet.  Before people can get access, them are required to read and
> acknowledge a statement about use of the Internet and about not sending
> confidential information over it.  For the most part, this system seems to work
> fairly well.  However, we occasionally have people who are "authorized" that
> "accidentally" send messages to the wrong address (Internet rather than
> intra-company).
>
> A1Mail has a feature of being able to specify a "Sensitivity" for a message.
> Are there any plans for PMDF-MR to be able to do something with this flag?
> (Such as only allowing messages where sensitivity is not COMPANY_CONFIDENTAIL
> to be sent out onto the Internet.)  We are looking at starting to use PMDF for
> some of the internal mail routing, also, so it would be best if something could
> be applied based upon the routing rather than just applying to everything
> coming through PMDF-MR.

While I cannot speak as to planned uses for the Sensitivity flag (that's Ned's
ballicwick), I thought I'd point out that PMDF V4.1-10 and later has a mapping
table which allows you to control who can send to where (source channel, source
address, destination channel, destination address).  This, of course, doesn't
prevent authorized people from accidentally sending company-confidential
material out to the Internet, but it does add another degree of control
to your present system.  That may or may not be interesting to you.  Since this
was added as an interim feature (requested by a customer) it is not in the
printed documentation.  It's also not in the on-line 4.1 docs.  If you're
interested I can send you the relevant documentation.

Dan
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Additional mailing list security
From: "Daniel C. Newman" <dan@innosoft.com>
Date: 16 Nov 1992 20:25:37 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 16 Nov 1992 20:25:37 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GR8DFGAS4I8ZGF26@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"fineberg@wupost.wustl.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

>>With the MAPPINGS file now in PMDF, it is possible to control who add
>>subscribe and unsubscribe users from MAILSERV mailing lists, get copies
>>of the list, etc., but has anyone implemented a system where only a
>>restricted group of users may actually mail to particular lists?
>
> Hmm.  When I read the 4.1 docs it seemed trivial to limit who could post
> to a list, but allowing mailed list ownership didn't seem to be there at
> all.  So what did my denseness ignore?  That is where in the manual is
> the reference to controlling who may add and delete users?

This information did not make it into the printed documentation.  Look in your
on-line docs (4.1-10 or later).  It should be under the MAILSERV documentation.
This additional documentation (complete with crucial typo) was posted to
info-pmd back in September (or thereabouts) by Ned.  Let mek know (anyone)
who wants this information e-mailed to them.

Dan