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: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Sun, 30 Aug 92 02:10:20 GMT
From:         Ned Freed <NED@INNOSOFT.COM>
Subject:      RE: postmaster bounces - 4.1-10
X-To:         ECF_STBO@JHUVMS, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

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

The change was to validate all addresses much sooner and much more completely.
It has nothing to do with  batch SMTP processing per se; it is a general change
in the underpinnings of PMDF itself.

> So if you don't want to get bounces
> for every unknown user, you have to put nosendpost on the bit_gateway channel.

Previously you could get some sorts of bounces from the bit_gateway channel.
You just get more now -- enough to notice.

I also recommend using errsendpost rather than nosendpost; someone should
get notified when a delivery failure occurs.

> I'm sure there must be some good reason for this but frankly,  I preferred the
> old behavior and think it was much 'cleaner'.

Failing messages as soon as possible is a real time-saver. It is particularly
valuable in non-batch SMTP where it avoids the need to even transfer the
message. It saves a channel-to-channel transfer in the case of batch SMTP,
and this gives a not inconsiderable saving, but nowhere near as much as the
non-batch case.

> I could find out about bsmtp
> errors, but the mandane misaddressed mail would be handled by the local channe
   l
> (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).

The overhead of checking an address is really small compared with the overhead
of doing full message processing. Even though the fraction of badly addressed
messages is small compared with the number of correctly addressed messages the
cost of doing an address check twice is still less than the cost of not failing
messages until local delivery is done.

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

postheadonly only works for some types of error messages. It didn't work much
at all in V4.0. V4.1 supports postheadonly in a lot more cases. Unfortunately,
the handling of batch SMTP errors is a very special case that didn't get
updated for V4.1. It will be fixed in the next release of PMDF -- a large
portion of the batch SMTP mechanisms in PMDF have already been rewritten to
allow for longer lines, proper error message formats, improved error reporting,
and closer compliance to the batch SMTP standard (please note that this
standard currently exists only in very preliminary draft form -- the existing
batch SMTP documents are NOT standards and cannot be considered to be
standards).

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

This certainly makes sense. However, please note that the bulk of the code that
drives these programs is in the PMDF_SHARE_LIBRARY image, and this image is
always supposed to be installed /OPEN/HEADER/SHARE.

A facility has been added for the next release of PMDF that lets you put these
sorts of things in a site-specific installed image list.

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

Kevin has already discussed this. However, let me mention the fundamental flaw
in this approach -- it causes you to lose information that may prove to be
vital for debugging. When you detect a problem you want the information about
that problem, and in some cases it may be impossible to  recreate the situation
with increased logging turned on.

Even if it is possible to recreate a problem it may prove to be very difficult.
I have sometimes spent many hours recreating something when having a single log
file would have given me all the information I needed.

For these reasons we prefer to default to a fairly heavy level of logging, in
order to make port-mortem debugging easier. We will undoubtedly add
capabilities for reducing logging in the future, but reduced logging is
unlikely to become the default.

> 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 must admit that this sounds like a fairly small amount of material to me.
I routinely deal with much larger amounts of log information on some
of the systems I manage. I don't see this to be a big performance problem,
and I would be rather uncomfortable if there was much less material to
check in the event of an error.

However, to each his own. We'll certainly enhance PMDF in this way, although I
have my doubts about its general utility for anything but a system with very
high throughput rates.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU