HDTenEightyP/NetNews huggingface dataset:
From: ned@sigurd.innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Mail-11 delivery and soft-vs-hard failures
Date: 31 Aug 92 22:40:38 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 31 Aug 1992 15:40:38 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GO8J1MUO9E95O4DJ@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

The code to determine whether or not a given error is temporary or
permanent is deeply buried in the internals of the VMS mail foreign
protocol interface. This code is not shipped with PMDF as a rule (it is
available under nondisclosure). The code is extremely complex since these
are not simple numbers -- they are strings and have to be parsed to obtain
their content.

This error in particular is also produced when a forwarding address is
broken on receiving system's side of things. This can in fact be a
consequence of the system not being fully initialized, so it does happen
at completely transient times. It is therefore inappropriate to reclassify
this particular error as permanent. Classification of errors is very tricky
because you have to know all the circumstances that can produce the error.
(My personal favorite is the "no such device" error, which you might think
would be permanent, but turns out to be what you get when some network
software is temporarily shut down!)

				Ned
From: jjc+@pitt.edu (Jeffrey J. Carpenter)
Newsgroups: vmsnet.mail.pmdf
Subject: BN_MASTER and SEND/FILE
Date: 4 Sep 92 14:31:12 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 04 Sep 1992 10:31:12 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOFS2Z835E96VMU9@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"INFO-PMDF@YMIR.CLAREMONT.EDU"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Hi,

I am running PMDF 4.0, JNET 3.4, Multinet 3.0, and VMS 5.4-3.

We have a connection to an MVS machine on our campus via BITNET.  The
mailer on that machine really wants the External Writer field to be set
to the destination user.  If this is not done, it parses the headers for
the "To:" line, which causes unpleasant results.

By default, the SEND/FILE command comes from Joiner with "/OPTIONS" set
to "".   I see from the source that the Options file seems to be used to
create a "/OPTIONS=blah" switch on the SEND/FILE that BN_MASTER performs.

Here are my questions:

1. Can I add a "W=" to the options file to have it set use the options
as follows:

	SEND/FILE/OPTIONS="W="

2. Joiner Tech Support tells me it is safe to include "/OPTIONS="W=" to
have the external writer field filled in on each SEND.  Is that true?
Are there any NJE mail software packages that would not like this?  If
there are, what is the best way to have this option apply to our
specific host (or a specific queue)?


Thanks,


	jeff
From: kvc@summer.innosoft.com (Kevin V. Carosso)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Problem  sending mail
Date: 13 Sep 92 01:53:47 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 12 Sep 1992 17:53:47 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
X-MX-Warning: Warning -- Invalid "To" header.
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOPF77ML6A984RPF@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"PJORGENSEN@COLGATEU.BITNET"
X-Vms-Cc: info-pmdf
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> This may not be a PMDF problem, but Digital is stumped and we have users who
> can't send mail.
>
> This problem only affects Mail for Macintosh users.
>
> This problem only affects non-priviledged users, users such as the system
> manager are not affected.

The first thing to do is to use one of these user accounts to send a message
using PMDF from VMS MAIL. See if you get any errors in that case.  I suspect
you are getting some sort of PMDF error, related either to incorrect file
ownership or protection in the PMDF_ROOT: tree or to insufficient disk quotas
for the PMDF or SYSTEM UIC on the PMDF_ROOT disk.  In the VMS MAIL environment
we don't ACCVIO when these errors occur.  The PCSA MAIL server, however, may
not handle the error properly.

You can also enable "master_debug" on the local channel in
PMDF_ROOT:[TABLE]PMDF.CNF.  This will produce debug output from PMDF
in the NETSERVER.LOG file.  Note that all VMS MAIL users who send to
a PMDF address while you have "master_debug" turned on will also see
debug messages on their terminals.  Keep that in mind when you try this.

	/Kevin Carosso
	 Innosoft

ps. I forgot to mention that we (among others) use the Pathworks Mail for Mac
    all the time without seeing this problem, so it definitely can work.
From: jeremy@vsm.com.au (Jeremy Begg)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Erroneous output from CONFIGURE.COM
Date: 4 Sep 92 05:18:37 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 04 Sep 1992 11:18:37 -0600 (CST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: info-pmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOCWHYCIOY95PAP1@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"DAN@INNOSOFT.com"
X-Vms-Cc: IN%"info-pmdf@ymir.claremont.edu"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

>There is no problem with CONFIGURE, per se, but rather with how you answered
>the questions.  The host name which is associated with the local (l) channel
>is that given in response to the question "Official local host name".  No
>rewrite rule is generated for this host: it is assumed to have been a host name
>which was given earlier in the configuration query/response session.  Ned just
>went ahead and added some additional DCL to CONFIGURE.COM to support what you
>did.

That makes sense, I told it the official local host name was r.s.g.a, not
SERF.r.s.g.a which was the default response.  Although this does mean I
have mis-understodd how the rewrite rules and the channel blocks interact.

>> But when I tried to send a message to a user on PAPER, the message was
>> encoded using BASE64 and was not readable:
>
>This was a bug in the interaction between linelength and charset7 which was
>fixed early on in 4.1 but your 4.1-2 tape pre-dates that fix.  The mail you
>sent must have had some long lines (> 255 characters) and PMDF went ahead and
>wrapped the lines but also encoded them when that wasn't necessary.

Actually, no.  I just did this:
$ MAIL
MAIL> send
To:   in%"sysprgg@paper"
Subj: Test mail to paper
Enter your message below. Press CTRL/Z when complete, or CTRL/C to quit:
This is a short test message to paper.
^Z
MAIL>

>
>Fortunately, there is a simple work around: remove the "charset7 us-ascii" from
>your d and l channels.  It's superfluous anyhow since charset7 us-ascii is the
>default.  Removing it will, however, remedy the problem.

Didn't work.  I removed the "charset7 us-ascii" without success, and then
also the "charset8 iso-8859-1" and that didn't help either.

Regards,

        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: dan@sigurd.innosoft.com (Daniel C. Newman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE:  FAX pop-up form and VMS MAIL keypad keys: problem resolved
Date: 12 Sep 92 17:07:55 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 12 Sep 1992 10:07:55 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: ipmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOOYX1JJGY984R9H@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"KLENSIN@INFOODS.MIT.EDU"
X-Vms-Cc: IN%"ipmdf@ymir.claremont.edu"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

>  Excuse me for being dumb if I'm missing something here, but it seems
> to me that there is another possible workaround.  The following is done
> from memory and can probably be improved upon, but wouldn't:
>
>  TRICKMAIL.COM:
>      $ oldkpd = F$GETDVI("SYS$INPUT","TT_APP_KEYPAD")
>      $ set term/application
>      $ mail
>      $ if .not. oldkpd then set term/numeric
>      $ exit
>and
>   $ MAIL :== @DEV:[DIR]TRICKMAIL
> do the job at a lower level of pain than /APPLIC/PERM ?

Yes, this will work.

On re-reading my posting I see that I inadvertently left the whole paragraph in
there on the /PERM/APPLICATION workaround.  (A half finished paragraph with
that dangerous phrase "the only work around".) I meant to leave that whole
paragraph out since the diagnosis of the problem, in the following paragraph,
brings to light the key issue (be in application mode before running VMS MAIL).
Sites troubled with this problem can then do as they  see fit prior to the
release of 4.2.

Since others may be interested in your suggestion, I'm posting this back to
info-pmdf.

Thanks,
Dan
From: ned@sigurd.innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Handling of aliases via Option Name_table_name
Date: 3 Sep 92 09:03:46 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 03 Sep 1992 16:03:46 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOCQQ836N695P5C9@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"KLENSIN@INFOODS.MIT.EDU"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> The Options file entry "name_table_name" can be used to specify
> a logical name table "to be searched for address aliases".

It can either be the name of a table or the name of a search that translates
to a list of actual tables. For example, you can use LNM$FILE_DEV to search
the name list of tables RMS uses.

We sort of frown on this mechanism since it is too easy to overlap your tables
with system tables and capricious use of system logical name tables for mail
aliases can cause serious trouble -- I've seen systems crash and be rendered
unbootable as a result of careless logical name table use.

> (1) is this searched before the conventional "aliases." file and its
> database or after it?  Are the targets of these equivalence-name aliases
> processed back through the rewrite rules as the "aliases." entries are,
> are are they processed only as part of delivery actions?

The ordering is as follows:

(1) Personal alias database.
(2) Aliases in logical name table(s).
(3) System alias database.
(4) System alias file.

All of these are essentially equivalent in terms of when they apply; they are
all invoked as part of message enqueue operations in PMDF.

> (2) Is there any reasonable way to test whether such a search resulted
> in a "hit?".  It appears that one might be able to do this with a
>   $[image,...]
> rule that searched the logical name table itself, but is there an
> easier/better way?  If not, does anyone have such code lying around that
> could be examined or scrounged?

The PMDF TEST/REWRITE utility lists the expansion of any address you give it at
the very end of its output. This takes all alias expansion into account. In
general aliases don't expand into headers, so they don't show up in the earlier
output of PMDF TEST/REWRITE that pertains to what headers would look like.

				Ned
From: d.nash@utexas.edu (Donald L. Nash)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Reprocessing channel
Date: 31 Aug 92 16:24:46 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 31 Aug 1992 10:24:46 -0600 (CST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GO83T8FAS295OSIN@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"NED@INNOSOFT.COM", in%"IPMDF@YMIR.CLAREMONT.EDU"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

>There's no explanation of the reprocessing channel largely because there's
>very little to explain.

Yes, but it is still rather hard to know this if it isn't written down
somewhere.  I think this is worth mentioning in the "Other Channels" chapter
of the manual, even if it is only one paragraph.

Anyway, thanks for the explanation.

				++Don
From: kvc@summer.innosoft.com (Kevin V. Carosso)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Mail system to use with PathWorks?
Date: 13 Sep 92 01:43:07 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 12 Sep 1992 17:43:07 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOPETQLPCY984RWA@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"alistair@mits.com.au"
X-Vms-Cc: info-pmdf
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> We are currently in the process of connecting all our PC's to the
> network using PathWorks, and I am trying to determine the most
> appropriate mail system to put in place.  It must be able to integrate
> with VMS Mail.
>
> 1.	The unsupported mail client.  This is a DOS application and
>	most of our users use Windows, so this is a bit clunky.

I assume you mean PATHworks mail.  I don't think it is considered "unsupported".
It works fine with PMDF with no additional software requirements.  However,
if they want a Windows application, this won't do it.

> 2.	Microsoft Mail as licensed with MS Office.  Has anyone
>	integrated this with PMDF?

PMDF does not currently have a direct gateway to MS Mail.  If you are using the
MS Mail PC product (as opposed to the completely different MS Mail Mac product)
then your best bet would be to purchase an MS Mail <-> SMTP gateway from
Microsoft.  If you use the Mac product then purchase the SMTP gateway from
Star Nine (details available if you need them).

> 3.	DEC's Mailworks.

This works very well with PMDF.  You will, however, need Message Router and
PMDF-MR.  MR when purchased as part of the MAILworks WAN Server package does
not add much to the cost, but you will need to install and manage it.

You might also look into cc:Mail from Lotus.  PMDF does have a gateway to
cc:Mail.

Unfortunately, like MS Mail, the disadvantage to running cc:Mail  is that you
will need to manage PC based "Post Offices".  Personally I find a solution that
uses the VMS machine for all mailboxes (like MAILworks) with only the client on
the PC to be preferable.  Management is centralized, the reliability is higher,
and you get all the advantages (backup, clusters, shadowing, striping, etc...)
of VMS behind the user's data.

	/Kevin Carosso
	 Innosoft
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Problems with cc:Mail channel.
From: "Kevin V. Carosso" <kvc@summer.innosoft.com>
Date: 14 Sep 1992 20:16:42 -0800 (PST)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 14 Sep 1992 20:16:42 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOSCS0WNXU984YNZ@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"andrewr@itd.adelaide.edu.au"
X-Vms-Cc: info-pmdf
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

>> 	ident="V4.1-A"
>> 	Not sure what the latest release from our supplier is, will
>> contact service as requested if they don't dave -10 or greater.
>
> Interesting -- I don't know of an instance where we used a letter as a
> dash number. Be that as it may, this is definitely a very early version
> and you need a more recent one.

V4.1-A is the ident applied to PMDFDISP.EXE after the mandatory security patch
has been applied.  All other images (and PMDF_ROOT:[EXE]IDENT.OPT) should
still contain the original ident after the patch has been applied.

	/Kevin Carosso
	 Innosoft
From: kvc@innosoft.com (Kevin V. Carosso)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: PMDF Process Symbiont problems (with MR-NOTIFY)
Date: 4 Sep 92 07:12:35 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 04 Sep 1992 00:12:35 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOFRUNYBCE96VMU9@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"bthomas@drifter.uwyo.edu"
X-Vms-Cc: INFO-PMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

The %PMDF-W-MRLSUBERR error occurs when the process symbiont
cannot figure out what PMDF channel goes with the mailbox
name for which Message Router says it has a message ready for
pickup.

In your case, MR has sent us a notification message with a mailbox
name of "SMTP".  We have to figure out which channel goes with that
mailbox, and we couldn't -- generally that is indicative of a PMDF-MR
configuration problem.

First of all, make sure that SMTP really is the name of the PMDF-MR
mailbox and that there are no other Message Router mailboxes for
PMDF-MR.  Check that PMDF.CNF or MR.CHANS (whichever contains your
"mr_local" channel definition) refers to the proper mailbox.  If
you change this and you use a compiled configuration you need to
recompile.

If you still can't figure out what the problem is, contact
"service@innosoft.com" and we'll see what else we can look at.  Do not
contact me personally as I will be out of town next week.

	/Kevin Carosso
	 Innosoft
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Notifying POP3 users of new mail.
From: Ned Freed <ned@sigurd.innosoft.com>
Date: 15 Sep 1992 02:18:31 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 15 Sep 1992 02:18:31 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOSPE2U4OY984UVG@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

This cannot be done efficiently in MASTER.COM -- it would require breaking
out of VMS MAIL for each message, and the overhead cost of doing this
is really huge. It is unfortunate that firing up VMS MAIL is expensive,
but it is and there's nothing we can do about it. It is also fairly
nontrivial to do the translation of local channel addresses into
meaningful usernames -- the rules for this are complex and far from
obvious.

The best way to do this would be for us to provide a hook in the local
delivery process to call some of your code. The best we could do
would be to give you the address we're passing to VMS MAIL (this is quite
different from the original recipient address). You could then go off
and do whatever you want with it.

Another possibility is for us to send out the notice ourselves. But
this requires some knowledge of the protocol used to ring up the
PC. POP is only a remote mail access protocol; it doesn't have remote
notification capability as far as I know. So what protocol do you use for
this?

We would probably just add the hook in any case; but we could also
write the specific module to deliver these notifications if, say,
Multinet is what you use as a transport.

				Ned
syscon!gator!inla
   nd!cmkrnl!infopiz!mccall!ipmdf-newsgate!list
Newsgroups: vmsnet.mail.pmdf
Subject: Using PMDF to deliver printer files
From: helmke@crf.cuis.edu (Rich)
Date: 3 Sep 92 06:03:38 GMT
Organization: Concordia University Information Systems, River Forest, Il.
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 03 Sep 1992 11:03:38 -0500 (CDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOCC34ABTU9ED9L1@INNOSOFT.COM>
X-Vms-To: IN%"info-pmdf@innosoft.com"
X-Vms-Cc: HELMKE
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT


    We have a number of small satellite VAX/VMS systems all over the
    USA that we remotely support via dialup logins and PMDF e-mail.

    We are investigating the possibility of setting up a home grown
    implementation of something that acts like DQS, but uses PMDF
    (dialup PhoneNet) and DELIVER instead of a DECNet connection to
    transfer print files.  We are facing the fact that even a modest
    file (without any graphics--just line printer ASCII of 200-1000
    blocks) will take many minutes to transfer so we must consider a
    data compression utility as well.

    Has anyone "pushed the envelope" with PMDF and associated
    utilities to deliver files to remote printer queues?  Any
    suggestions for implementation (or pit falls)?

    Thanks for your help,
    Rich Helmke
    Associate Director
    Concordia University Information Systems
    708/209-3221
From: ned@sigurd.innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: GATES.RULES file does not look right.
Date: 9 Sep 92 02:07:25 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 08 Sep 1992 19:07:25 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOK4FD4IG296VWNM@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"tkslen@ubvms.cc.buffalo.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

The GATES.RULES file you posted looks correct to me. The multiple entries
are a result of the need to hide BITNET addresses behind a route when
messages are relayed out to the Internet.

The results from PMDF TEST also look correct. The local channel reference
at the beginning is a chimera; it is the (correct) reference to bit_mailer
at the bottom you should be concerned with. The headers also look correct.

				Ned