HDTenEightyP/NetNews huggingface dataset:
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"NED@SIGURD.INNOSOFT.COM"
X-VMS-Cc: IN%"KLENSIN@INFOODS.MIT.EDU", IN%"IPMDF@YMIR.CLAREMONT.EDU"
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Mail-System-Version: <VAX-MM(312)+TOPSLIB(155)+PMDF(4.1)@INFOODS.MIT.EDU>
Date:         Fri, 4 Sep 92 06:56:48 GMT
From:         John C Klensin <KLENSIN@INFOODS.MIT.EDU>
Subject:      RE: Handling of aliases via Option Name_table_name
Newsgroups: bit.listserv.pmdf-l

Ned,
  Thanks very much for the quick response.

  My last question wasn't clear....
> (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
>
>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.

Sorry... The requirement is a production one, not a "test" one.  In
essence, I'm trying to construct a rule that sends things out one
channel if they map onto aliases specified by a particular logical name
table, and out another channel if they aren't found there.  I'm actively
trying to translate the requirement into some more reasonable form, but
have not yet been successful in doing so.

   john
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"JEREMY@vsm.com.au"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Fri, 4 Sep 92 10:42:10 GMT
From:         Ned Freed <NED@INNOSOFT.COM>
Subject:      RE: Erroneous output from CONFIGURE.COM
Newsgroups: bit.listserv.pmdf-l

> 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.

I have changed CONFIGURE.COM so that in the future it will insure that the
official local host name gets its own rewrite rules.

> 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>

> 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.

Did you remove them from both the D AND the L channels? You have to get rid of
it in both places. charset8 has nothing to do with it unless you use 8-bit
characters. You can also solve the problem by getting rid of the linelength
limits. The proper solution, of course, is to get a newer version of PMDF that
handles this interaction correctly. Please contact your distributor if you want
a updated version; all distributors have had updated versions in hand for quite
a while.

Dan was incorrect on one point -- the problem has nothing to do with actually
having long lines. The problem is rather due to the fact that a line length
limit was given AND a character set was given WITHOUT providing an incentive
for an actual detailed length check of the message. The result is that the
general MIME converter in PMDF doesn't know the lengths but knows there's a
limit; it then assumes the worst and encodes "just to be on the safe side".
This is also the reason base64 is used -- there is no frequency information
available to indicate that quoted-printable would be a better choice.

This problem was corrected by making a bunch of different and interrelated
changes. In some cases more analysis is now done and in others the converter is
no longer quite so strict.

All this is an unfortunate consequence of the interaction of linelengths and
character sets. I have described the problem and the ways to solve it in
previous info-pmdf postings. I am fairly sure this is the problem you're
seeing; the symptoms are absolutely identical to previous problem reports.

If you cannot get things to work even after you have removed all linelength and
charset7 specifications and recompiled and reinstalled (if you use a compiled
configuration) please send me your configuration and I'll look into it further.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
Organization: Cambridge Computer Associates, Inc.
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: in%"tkslen@ubvms.cc.buffalo.edu"
X-VMS-Cc: in%"info-pmdf@innosoft.com",TINKELMAN
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Sun, 23 Aug 92 14:11:55 GMT
Comments:     Warning -- original Sender: tag was TINKELMAN@EISNER.DECUS.ORG
From:         Bob Tinkelman <bob@CAMB.COM>
Subject:      RE: pmdf 4.1-4 and slow delivery
X-To:         tkslen@ubvms.cc.buffalo.edu
X-cc:         info-pmdf@INNOSOFT.COM, TINKELMAN@Eisner.DECUS.Org
Newsgroups: bit.listserv.pmdf-l

This is probably not your problem, but it was something that surprised us.

PMDF 4.1 can use many more batch jobs than 4.0.  If you're not using the
process symbiont, that could make a performance difference.  In versions
prior to 4.0, the periodic delivery job would, if it was running in the
appropriate batch queue for a channel, run the channel itself, rather than
submitting a separate batch job for that channel.  With 4.1, it always
submits a separate batch job.

When I installed 4.1 on eisner.decus.org, the number of batch jobs run (on
the whole system) went up from about 800/day to about 1250/day.  [The
configuration here at that time did no immediate delivery; all delivery was
from the periodic delivery job, running with a post interval of 10 min.]
--
Bob Tinkelman <bob@camb.com>
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"jjc+@pitt.edu"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Mon, 31 Aug 92 00:25:37 GMT
From:         Ned Freed <NED@INNOSOFT.COM>
Subject:      RE: Holding Mail
X-To:         jjc+@pitt.edu, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

The usual way to do this is to associate the machine with a channel of
its own and then set the notices intervals for the machine to either
very large or very small values. This has the effect of either holding the
mail or bouncing it more or less immediately.

The PMDF_HOLD stuff may work and you are welcome to try it, but it is
largely a holdover from times when we didn't have notices intervals.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"INFO-PMDF@YMIR.CLAREMONT.EDU"
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Thu, 27 Aug 92 22:46:15 GMT
From:         "Jeffrey J. Carpenter" <jjc+@PITT.EDU>
Subject:      Holding Mail
X-To:         INFO-PMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

Hi,

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

We have a machine on campus that will be down for several days.  Is
there a way I can configure a channel for this specific host so that it
does not follow the normal schedule for return of undeliverable mail?

Is this what the PMDF_HOLD logical in RETURN.COM is intended for?

Thanks,


        jeff
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"jjc+@pitt.edu"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Tue, 1 Sep 92 03:30:42 GMT
From:         Ned Freed <NED@SIGURD.INNOSOFT.COM>
Subject:      RE: Holding Mail
X-To:         jjc+@pitt.edu, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

Sure -- use the NOTICES channel keyword to do this. This works in both
PMDF V4.0 and V4.1, although it wasn't documented until V4.1 came out.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
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
Date:         Fri, 4 Sep 92 05:28:16 GMT
From:         Ned Freed <NED@SIGURD.INNOSOFT.COM>
Subject:      RE: Handling of aliases via Option Name_table_name
Newsgroups: bit.listserv.pmdf-l

> 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: tkslen@ubvms.cc.buffalo.edu (Lenny Miceli)
Newsgroups: bit.listserv.pmdf-l
Subject: Solution to vms5.5-1/pmdf4.1-1 performance problem.
Date: 26 Aug 92 18:04:55 GMT
Reply-To: tkslen@ubvms.cc.buffalo.edu (Lenny Miceli)
Organization: SUNY at Buffalo, Systems group


My performance problem with mail delivery (with vms 5.5-1 and pmdf 4.1-1) went
away when I changed the file ownership of PMDF_ROOT:[TABLE]QUEUE_CACHE.DAT;1
from SYSTEM to PMDF.  I took so long to relay this information because I waited
a couple of days to see if a queue buildup would occur (and it didn't).
Anyways, thanks to all that replied, and to Dan, because I got this information
from his post.

Thanks again,
  Lenny Miceli 
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Return-path: uucp@mccall.UUCP
Errors-to: epmdf@YMIR.BITNET
Organization: Beckman Instruments
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"ipmdf-newsgate@mccall.UUCP"
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Sat, 29 Aug 92 09:37:36 GMT
From:         dsroberts@BECKMAN.COM
Subject:      Justifying PMDF maintenance costs
X-To:         ipmdf-newsgate@mccall.UUCP
Newsgroups: bit.listserv.pmdf-l

We've been using PMDF for a year now, and it's time to renew the contract.
There was a great deal of management resistance here to PMDF simply because the
maintenance cost more than the initial license, and management has been looking
for an excuse to get rid of it.  Mgmt was sold on the PMDF-MR capability, but
we have subsequently gotten rid of ALL-IN-1 and the need for PMDF-MR, so I am
in the painful position of having to justify PMDF all over again.  We'll dump
-mr, but I need justification to keep regular PMDF.  I've explained about
the flexible addressing, DELIVER, and personal aliases, but so far am
getting no budget.

My question for the list, how do you justify PMDF to your management when you
already have MultiNet's SMTP processing capabilities?  Do other managements
think personal aliases are enough, or is there more that I'm forgetting in
trying to justify continuing support for this product?  Has anyone put together
some justification documents for THEIR management?  Or maybe PMDF just isn't
necessary for us.
--
   Don Roberts                   Internet:  don@beckman.com
   Beckman Instruments, Inc.     Phone:     714/961-3029
   2500 Harbor Bl. Mailstop X-12 FAX:       714/961-3351
   Fullerton, CA  92634          Disclaimer:  Blame me, not Beckman.
   People are as happy as they decide to be - A. Lincoln
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"ipmdf@YMIR.CLAREMONT.EDU"
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Tue, 1 Sep 92 14:37:03 -0700
From:         bthomas@DRIFTER.UWYO.EDU
Subject:      PMDF Process Symbiont problems
X-To:         ipmdf@YMIR
Newsgroups: bit.listserv.pmdf-l


I converted our PMDF-MR gateway jobs from the old method of using
standard batch queues to using the PMDF process symbiont two days
ago. Starting today I have been getting the following sequence of
errors on the operator consoles:

%PMDF-W-PRCSMBWRN, PMDF process symbiont non-fatal warning
%PMDF-W-MRLSUBERR, Error submitting OMDF-MR for local mailbox "SMTP",
  status=178028674
-PMDF-E-HOST, Illegal host/domain in address "!AD"

Our Message Router mail box for PMDF-MR is "SMTP" instead of "PMDF"

The manual says that the error may be due to an incorrect PMDF-MR configuration.

I used MR-CONFIGURE to build the PMDF-MR configuration. PMDF-MR seems to still
work since jobs get started on the symboint queues and mail goes from MR to
PMDF (excluding a bug in PMDF-MR, Thanks for the quick answer on that Ned).

Did I miss something when I changed the queues or is something more required
in the PMDF-MR configuration to make this work?

-------------------------------------------------------------------------------
|   ####   ###  ##    |   Brad Thomas                                         |
|   ####   ###  ##    |   System Programmer                                   |
|   ####   ###  ##    |   Network Development Group                           |
|   ####   ###  ##    |   University of Wyoming                               |
|    ###    #   #     |   Bthomas@Outlaw.UWyo.Edu                             |
|     ###### ###      |   bthomas@drifter.uwyo.edu                            |
-------------------------------------------------------------------------------
From: ECF_STBO@JHUVMS (especially the mouth part of the face)
Newsgroups: bit.listserv.pmdf-l
Subject: postmaster bounces - 4.1-10
Date: 28 Aug 92 18:52:59 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"ipmdf@ymir"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
X-To:         ipmdf@YMIR

I've just upgraded to 4.1, well actually I did it as a new install and copied
the config files from my old 4.0 installation and then switched over from
ctlsmb to pmdf_process_smb. 4.1 does seem to use less resources in mail$batch,
thanks to the developers for getting around the dir/sin bottleneck! I'll bet
this will help us out a lot when we get smothered when the semester starts.


There is an (as far as I can tell) undocumented difference in the behavior of
BSMTP processing: apparently the (local) recipient is checked by the gateway
channel instead of by the local channel. So if you don't want to get bounces
for every unknown user, you have to put nosendpost on the bit_gateway channel.
I'm sure there must be some good reason for this but frankly,  I preferred the
old behavior and think it was much 'cleaner'. I could find out about bsmtp
errors, but the mandane misaddressed mail would be handled by the local channel
(which would have nosendpost). After all it's a local error. Also, the
vast majority of mail which is correctly addressed will now be checked twice,
once by bit-gateway and once by the local channel (vms mail).

Are other folks sucessfully using the postheadonly keyword? It's not working
for me. I have it in a defaults channel block, but I still get the bodies. If I
can get postheadonly to work, I'll take nosendpost off the bsmtp channel.

I would recommend that people on bitnet with a heavy mail load install
bn_master and bn_gateway /open/head/shared. Here these images are invoked
hundreds of times a day. I have also streamlined task_server.com by adding a
set nover and letting all the logfile information just go into the single
process log file. If there is a problem, we can always go back to the old
one. Wirth the one shipped there are way too many files created, with way too
much data in them for normal operation. Our [log] directory was getting up to
10,000 blocks w/ hundreds of files!
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"ipmdf@ymir"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Mon, 31 Aug 92 17:31:12 GMT
From:         especially the mouth part of the face <ECF_STBO@JHUVMS>
Subject:      Postmaster bounces 4.1-10
X-To:         ipmdf@YMIR
Newsgroups: bit.listserv.pmdf-l

Thanks for the comments, Ned and Kevin. If you think bouncing addresses asap is
a win in general, I guess I can live with that. Getting other peoples mail puts
the postmaster in an awkward position. I would rather not get incorrectly
addressed mail, unless the bounce couldn't be sent back to the originator. I
wouldn't mind it at all if I only got the headers. I liked it when all local
checking was done by the local channel because I could put nosendpost there
and pretty much miss all the NOSUCHUSER type postings. I haven't encountered
any real problems on the local channel that were not very obvious and
required copies of bounces. Maybe a dontbounceincorrectlyaddressedmailtopostmast
keyword would help here, or maybe something in an options file, or is this too
hideous too imagine?? This are ERROR postings as far as I know, and errsendpost
will still cause them to be bounced to me. For now, I think I'll try taking
nosendpost off all channels and then gradually put it back on channels where
'defaults postheadonly' isn't working.

About the logfiles, I was really getting like 500 files and 10000 blox within a
couple of hours. The disk space doesn't bother me at all, it's just the overhead
of creating so many files and spewing that much data. Then they all have to be
purged, etc... It may not seem like much, but if I can handle a few more users
with this hardware by doing a few things like this it's worth it. The main
logfile has all the output from the programs. Most of the default output is
just tracing master.com over and over again anyway. I turn off set verify
and get rid of the separate logfiles (I've never used batch jobs by the way)
every time I install PMDF. I don't mind doing it, and many sites may not care,
I was really just suggesting that sites with heavy message traffic might want
to look into doing this.

-Tom O'Toole
-JHUVMS Postmaster
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
Organization: Cambridge Computer Associates, Inc.
X-Envelope-to: PMDF-L@IRLEARN.BITNET
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
Date:         Tue, 1 Sep 92 18:22:39 GMT
From:         Bob Tinkelman <bob@CAMB.COM>
Subject:      RE: NOTES channel for PMDF 4.0
X-To:         ipmdf@INNOSOFT.COM
Newsgroups: bit.listserv.pmdf-l

Back in June I'd posted the following to the vmsnet.mail.pmdf newsgroup.
I never saw it arrive via the mailing list so I'm reposting it directly.

Date: 04 Jun 1992 09:44:48 -0400 (EDT)
From: bob@camb.com (Bob Tinkelman)
Subject: RE: NOTES channel for PMDF 4.0
Message-id: <1992Jun4.094448.39950@camb.com>
Newsgroups: vmsnet.mail.pmdf

In article <01GKQPB2ZOHYAYJZ9L@HMCVAX.CLAREMONT.EDU>, dan@hmcvax.claremont.edu
(Daniel C. Newman) writes:

> PMDF V4.1, due out any day now, has a PMDF -> VAX NOTES channel.

Any thoughts on the other direction: VAX NOTES -> PMDF ???
--
Bob Tinkelman, Cambridge Computer Associates, Inc., 718-464-9392, bob@camb.com
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
Organization: Duke University Medical Center, Durham NC, USA
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"ipmdf@ymir"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Sat, 29 Aug 92 06:19:22 GMT
From:         "James Dryfoos - Postmaster" <DMPM@DUKEMC>
Subject:      (UNIVSCVM) - DMTAXM121E User MAILER not authorized to receive
              file?
X-To:         ipmdf@YMIR
Newsgroups: bit.listserv.pmdf-l

(UNIVSCVM) - DMTAXM121E User MAILER not authorized to receive file?

Any idea what this is telling me?  Is it something on my side?

Jim
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"ECF_STBO%JHUVMS.BITNET@ymir.claremont.edu"
X-VMS-Cc: info-pmdf
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Sun, 30 Aug 92 05:40:26 GMT
From:         "Kevin V. Carosso" <KVC@SUMMER.INNOSOFT.COM>
Subject:      RE: postmaster bounces - 4.1-10
X-To:         ECF_STBO@JHUVMS, info-pmdf@YMIR
Newsgroups: bit.listserv.pmdf-l

> Wirth the one shipped there are way too many files created, with way too
> much data in them for normal operation. Our [log] directory was getting up to
> 10,000 blocks w/ hundreds of files!

I should point out that the size and number of log file created using the
Process Symbiont shouldn't be significantly different in any way from those
produced using a batch queue for processing.  In fact, since the SYLOGIN.COM
is not logged for every processing job under the Process Symbiont (on most
systems it ends up in every batch job's .LOG file) the resulting .LOG files
are usually smaller.

        /Kevin
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU