HDTenEightyP/NetNews huggingface dataset:
From: sumedh@charlie.ece.scarolina.edu (Sathaye Sumedh W (CS))
Subject: (none)
Reply-To: sumedh@charlie.ece.scarolina.edu (Sathaye Sumedh W (CS))
Date: Tue, 7 Apr 1992 16:42:29 GMT

Dear MX-Masters,

	I recently reinstalled MX 3.0A onto a new disk other than the system
disk and have started facing problems with the outgoing messages. The messages
are not delivered. Apparently, the VMS mail does not pass the address on the
envelope to the MX router (this is my prediction). I have attached the router
LOG file as well as the MC configuration files herewith. Can somebody guide
me in this respect?

Thanks and regards,

Sumedh Sathaye,
System Administration, College Of Engg,
University Of South Carolina, Columbia, SC 29208.

(vax_sumedh@mv3800.engr.scarolina.edu)

================================================================================
The mx_router_log.log file:
================================================================================

 7-APR-1992 12:18:32.74 %PROCESS, Processing entry number 103
 7-APR-1992 12:18:32.87 %PROCESS, Status from READ_INFO was 00000001
 7-APR-1992 12:18:32.87 %PROCESS, Message originated in VMS Mail.
 7-APR-1992 12:18:32.88 %PROCESS,  will run domain expander on envelope addresses.
 7-APR-1992 12:18:32.89 %PROCESS,  will run domain expander on message headers.
 7-APR-1992 12:18:33.91 %PROCESS, Finished VMSmail-origin preprocessing.
 7-APR-1992 12:18:33.91 %PROCESS, Marking this entry as finished.

================================================================================
! Configuration file: MX_ROOT:[000000]MX_CONFIG.MXCFG;4
! MX version id: MX V3.0A
DEFINE PATH "mv3800.engr.scarolina.edu" Local
DEFINE PATH "*.UUCP" SMTP /ROUTE="uunet.uu.net"
DEFINE PATH "*.BITNET" SMTP /ROUTE="cunyvm.cuny.edu"
DEFINE PATH "*" SMTP
SET SMTP/ACCOUNTING/RETRY_INTERVAL="   0 00:30:00.00" -
  /MAXIMUM_RETRIES=96 /DNS_RETRIES=12-
  /NODEFAULT_ROUTER
SET LOCAL/NOACCOUNTING/RETRY_INTERVAL="   0 00:30:00.00" -
  /MAXIMUM_RETRIES=96/HEADERS=(TOP=(-
    FROM,SENDER,TO,RESENT_TO,CC,RESENT_CC,BCC,RESENT_BCC,MESSAGE_ID,-
    RESENT_MESSAGE_ID,IN_REPLY_TO,REFERENCES,KEYWORDS,SUBJECT,-
    ENCRYPTED,DATE,REPLY_TO,RECEIVED,RESENT_REPLY_TO,RESENT_FROM,-
    RESENT_SENDER,RESENT_DATE,RETURN_PATH,OTHER), BOTTOM=(-
    NOALL))
SET ROUTER/PERCENT_HACK
SET JNET/PERCENT_HACK/NOBSMTP_REPLY/NOACCOUNTING/NOLENIENT
SET DECNET_SMTP/NOACCOUNTING/RETRY_INTERVAL="   0 00:30:00.00" -
  /MAXIMUM_RETRIES=96
SET SITE/RETRY_INTERVAL="   0 00:30:00.00" -
  /MAXIMUM_RETRIES=96
================================================================================
Newsgroups: vmsnet.mail.mx
From: gowen@walt.CS.MsState.Edu (Lon Gowen)
Subject: MX sending too many "receive" commands.
Organization: Mississippi State Univ.
Date: Mon, 13 Apr 1992 19:37:16 GMT

Yet another question about MX V3.1.   First off, I am using a VAXstation
4000/60, VMS V5.5, and UCX V1.3 (don't laugh).  Anyway, I can send mail
just fine (now), but my receive operations fail.  I am currently trying
to send a message from a Sun Unix box to VMS.  The message I get back on
my Unix account says the following:

Rcvd:  554  Received too many times by this host.

Needless to say, I assume that MX is sending too many "receive" commands.
All the other handshaking between the two hosts seems fine.  The VAX
just never receives the DATA properly.  Does anyone have any ideas or
hints?  By the way, I sent a message to the VAX by just replying to
the message I sent from the VAX to the Unix account.

Thanks in advance!

Lon Gowen, PhD
gowen@cs.msstate.edu
Newsgroups: vmsnet.mail.mx
From: madison@mdmvs.ecs.rpi.edu (Matt Madison)
Subject: MX V3.1 revision level A now available
Reply-To: madison@vms.ecs.rpi.edu
Date: Wed, 8 Apr 1992 17:48:22 GMT

After receiving a handful of bug reports for MX V3.1, I have produced a
maintenance release, called revision A.  Everyone who obtains the MX031 kit
by anonymous FTP will be getting the updated version (savesets A, C, I, and
J are changed from the original V3.1 release).  If you have MX V3.1 currently
installed and would like to upgrade painlessly to V3.1A, you should get the
files 01README.REVA_UPGRADE and MX_REVA_UPGRADE031.A_Z, which is the upgrade
kit for existing V3.1 users.

The MX031 kit on FILESERV will remain the older version for the time
being; request package MX_REVA_UPGRADE031 for the upgrade kit.

The following V3.1 bugs are fixed by this maintenance release (excerpted
from the release notes):

    1. MX_MAILSHR was not performing logical name translations on VMS Mail
       To-lines in a case-blind fashion, resulting in incorrect RFC822 To:
       headers in certain cases. This has been fixed.

    2. The Sender: header provided for messages originating in VMS Mail was
       using incorrect syntax for addresses according to RFC 822, although
       by RFC 1123 it was correct. This was causing some problems with
       finicky mailers still using the old standard, so the syntax has been
       changed. In addition, the Sender: header is no longer provided if it
       matches the From: header, since it is unnecessary to do so.

    3. The SITE delivery agent would behave unpredictably, usually dying with
       an ACCVIO, when a delivery resulted in an error status that caused a
       message to be requeued for another delivery attempt. This has been
       fixed.

    4. MCP would not update the configuration database when invoked with a
       one-shot command on the MCP command line, even if that command made a
       change to the configuration. This has been fixed.

    5. The MLF agent would lose its information about mailing lists and file
       servers when it received a RESET/ACCOUNTING signal. This has been fixed.

Also fixed was the error in the installation procedure that caused it to
provide an incorrect default answer for the placement of the MX top-level
directory on systems where MX had never been installed before.

Have fun,
-Matt

PS: I will be out of town the 9th through the 12th, so if you send me
    something and don't hear from me, don't think I'm ignoring you.  -mdm
--
Matthew Madison, Systems Programmer  | Internet: madison@vms.ecs.rpi.edu
Engineering Computing Services       | Bitnet:   MADISON@RPIECSVX
Rensselaer Polytechnic Institute     |
Troy, New York 12180-3590 USA        |
From: willis@evax0.eng.fsu.edu
Newsgroups: vmsnet.mail.misc
Subject: Buckets
Date: 4 Apr 92 14:13:31 GMT
Organization: Famu/Fsu College of Engineering

Hello,

     would someone mind explaining to a non-computer science major what 
the significance of Data Buckets and Index Buckets have with respect to
the following command:

MAIL> PURGE/RECLAIM/STATISTICS

Thanks!
-- 

======================================================================
Russell E. Willis                             
The Florida State University Computing Center
Innovation Park
Tallahassee, Fl. 32310
                                             
e-mail:      willis@evax0.eng.fsu.edu
             willis@loligo.cc.fsu.edu        
             russell willis@rai.cc.fsu.edu   
             willis@fsuavm                        
             willis@fsu1.cc.fsu.edu          
*
* Mistakes and personal quotes are the two things you can truly call
* your own.  Combining the two can be synergistically catastrophic.
*                                                           --R.E.W.--
======================================================================
From: sue@uno.cc.geneseo.edu (Sue Chichester)
Newsgroups: vmsnet.mail.pmdf
Subject: Enqueued and undeliverable for 1 day
Date: 7 Apr 92 14:56:00 GMT
Article-I.D.: geneseo.01GIKAK9UBN4000DKI
Reply-To: sue@uno.cc.geneseo.edu
Organization: The Internet
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Resent-Date: Tue, 7 Apr 1992 08:01 PST
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-Id: <01GIK4GSUZUO8WWORH@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"info-pmdf@ymir.claremont.edu"

My l_master.log file maxed out on version limit so I deleted the l_master.log 
files and submitted the master.  All the messages that were queued are
not being sent to the users but are being sent back and a note left
with postmaster saying
Your message has been enqueued and undeliverable for 1 day.
No further attempts will be made to deliver your messsage.
Why is it doing this?
Sue Chichester
sue@geneseo.bitnet

P.S.  I'm running PMDF version 4.0.  Does this run okay on VMS 5.5?
From: dsroberts@beckman.com
Newsgroups: vmsnet.mail.pmdf
Subject: uucp re-write rule
Date: 17 Apr 92 09:58:27 PDT
Organization: Beckman Instruments

I just can't seem to get these dang re-write rules right...

I have a re-write rule for uucp:

.uucp			$H!$U@uu.psi.com@MTCP-DAEMON

This gets turned into:

@MTCP-DAEMON:host!user@uu.psi.com

Which always bounces.  My guess is that using uu.psi.com is what is wrong.  Is
there a better choice, or is there something administratively I need to do to
get a generic host for gatewaying to uucp?

-- 
   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.
   Sometimes I feel like I'm the only one born without an instruction manual.
           - Ron Tye
Newsgroups: vmsnet.mail.pmdf
Subject: I lost the signoff formula for the list (sigh).
From: Vern Cole -- Systems Manager <coleve@cc.uvcc.edu>
Date: Tue, 7 Apr 1992 07:47 MDT
Organization: The Internet
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Resent-Date: Tue, 7 Apr 1992 06:48 PST
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-Id: <01GIK1VC25TS8WWO8M@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"ipmdf@ymir.claremont.edu"

I appear to have forgotton or misplaced the formula for signing off from
this mailing list.  I tried LISTSERV, but that's not it.  (I have a news-
reader now so I don't need the mail service.)

Perhaps a reminder for my benefit might help others, too.

Please, Sir, what is the incantation?
-------------
Vern Cole
Newsgroups: vmsnet.mail.pmdf
Subject: RE: TGV address?
From: "Daniel C. Newman" <dan@hmcvax.claremont.edu>
Date: Tue, 14 Apr 1992 10:30 PST
Organization: The Internet
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Resent-Date: Tue, 14 Apr 1992 10:31 PST
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-Id: <01GIU1PR1DZK8WXF4Z@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"ZVONKO@yubgef51.bitnet"
X-Vms-Cc: IPMDF

> I am searching for e-mail address and fax number of TGV Incorporated.
> If TGV doesn't exist any more, I need the same information for the
> current manufacturer of "Multinet".
> 
> According to the papers I have, Multinet info and orderings should be
> maintained by <service@tgv.com>. Unfortunately, the only answer from
> that address is

TGV is still in business; their address is

           TGV, Inc.
           603 Mission Street
           Santa Cruz, CA  95060
           USA

           (408) 427-4366          service@tgv.com
           (408) 427-4365 [FAX]
 
>> 550 Host 'tgv.com' Unknown
> 
> What happened to TGV?

This looks like you're having temporary name server difficulties.

Dan
Newsgroups: vmsnet.mail.pmdf
Subject: signoff formula for the list (sigh)
From: peter@embl-hamburg.de
Date: Wed, 8 Apr 1992 09:49 +0200
Organization: The Internet
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Resent-Date: Wed, 8 Apr 1992 00:51 PST
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-Id: <01GIL3Q4O4KW8WWSWZ@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"ipmdf@ymir.claremont.edu"
Comments: ---- EMBL Hamburg is no longer in BITnet ---- use EMBL-Hamburg.DE ----

Vern Cole tells us:
  > I appear to have forgotton or misplaced the formula for signing off from
  > this mailing list.

I thought it was RPMDF @    ymir.bitnet .OR. ymir.claremont.edu

but I have requested a change of address to the second version _three_ times
  now without any change.
  (I'm now trying to turn off my X400 which only carries its own admin traffic!)

How about a PMDF_COMMENTS line just for the IPMDF mail headers giving the 
  registration address? The facility might be good for other newsletter lists,
  too. I can think of a couple here in house.
  (Would also be useful for System Managers fielding "gone-away" users mail.)

regards
Peter Bendall
Newsgroups: vmsnet.mail.pmdf
Subject: Problems with forward to PMDF all the sudden
From: James Dryfoos- PostMaster <dmpm@dukemc.bitnet>
Date: Mon, 13 Apr 1992 11:05 EDT
Organization: The Internet
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Resent-Date: Mon, 13 Apr 1992 08:08 PST
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-Id: <01GISIFI1JE88WXCTF@YMIR.CLAREMONT.EDU>
X-Organization: Duke University Medical Center, Durham NC, USA
X-Vms-To: IN%"ipmdf@ymir"

I am sending mail to a VMS .dis group and two addresses in it
have forwards across DECnet to PMDF.  This worked fine for awhile
and now I get:
 
%MAIL-E-SENDERR, error sending to user IN%"funde001@dukemc" at DUKEMC
%MAIL-E-OPENIN, error opening  as input
-RMS-E-ACC, ACP file access failed
-SYSTEM-F-EXQUOTA, exceeded quota
%MAIL-E-SENDERR, error sending to user IN%"polla001@dukemc" at DUKEMC
-MAIL-E-PROTOCOL, network protocol error
-SYSTEM-F-LINKABORT, network partner aborted logical link
 
PMDF is installed on the system disk, and that disk DOES NOT have
quotas.  I assume it is another quota and disk quota (i.e. process
level quota).
 
Thanks for any help.
 
Jim Dryfoos
Newsgroups: vmsnet.mail.pmdf
Subject: RE: signoff formula for the list (sigh)
From: "Ned Freed, Postmaster" <ned@hmcvax.claremont.edu>
Date: Wed, 8 Apr 1992 02:25 PST
Organization: The Internet
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Resent-Date: Wed, 8 Apr 1992 02:26 PST
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-Id: <01GIL70RI4E88WWSGZ@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"PETER@EMBL-Hamburg.DE"
X-Vms-Cc: ipmdf

> I thought it was RPMDF @    ymir.bitnet .OR. ymir.claremont.edu

This is correct.

> but I have requested a change of address to the second version _three_ times
> now without any change.

We only got one of them. It came in a day or so ago, I think, and the
change was made then. You should have received a reply message as well.

>   (I'm now trying to turn off my X400 which only carries its own admin
> traffic!)

It sounds like it is losing mail as well.

> How about a PMDF_COMMENTS line just for the IPMDF mail headers giving the 
> registration address? The facility might be good for other newsletter 
> lists, too. I can think of a couple here in house.

It is a thought. I'll consider it.

					Ned
Newsgroups: vmsnet.mail.pmdf
Subject: Question about XMAILER.NAMES, DOMAIN.NAMES, and BITEARN.NODES
From: John W Manly <jwmanly@amhchn.amherst.edu>
Date: Wed, 8 Apr 1992 21:32 -0500
Organization: The Internet
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Resent-Date: Wed, 8 Apr 1992 18:33 PST
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-Id: <01GIM4TS6XV48WWW9T@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"info-pmdf@ymir.claremont.edu"

Hello again.

Now I have a question about the DOMAIN.NAMES and XMAILER.NAMES files.  Amherst
College (domain AMHERST.EDU) is connected to both BITNET and Internet.  I
was looking at our entries in the files above, and found the following:

---------------------------------------------------------------------------
DOMAIN.NAMES:

:nick.AMHERST.EDU :mailer.SMTPUSER@AMHERST  BSMTP  3   :served.YES
:site.Amherst College
:gatemast.BITMGR@AMHERST        :interconnect.NO
---------------------------------------------------------------------------
XMAILER.NAMES:

:nick.AMHERST :alias.AMHERST :net.BITNET :mailer. :netsoft.JNET
---------------------------------------------------------------------------

Do these look right?  Shouldn't we have ":interconnect.YES" in DOMAIN.NAMES 
since we ARE on the Internet?  If so, who do we contact about getting
the necessary changes made?

And what is the relationship between these files and the BITEARN.NODES
database maintained by BITNIC.  Do they ostensibly contain any of the same
data?  If so, does either one refer to the other directly, or are there
serious consequences if the two get out of synch?

- John W. Manly  <JWMANLY@AMHERST.EDU>   System Manager -- Amherst College
Newsgroups: vmsnet.mail.pmdf
Subject: Question about $BITNET$xxx.00 files
From: John W Manly <jwmanly@amherst.edu>
Date: Tue, 7 Apr 1992 13:13 -0500
Organization: The Internet
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Resent-Date: Tue, 7 Apr 1992 10:14 PST
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-Id: <01GIK93TR8TC8WW1UE@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"ipmdf@ymir.claremont.edu"

Hi there.  Two questions, one of which is (I'm certain) asked a lot.  I
thought I remembered the answer, but it turns out I don't.

1) What are all these $BITNET$xxxxx.00 files in the PMDF_ROOT:[QUEUE]
   directory?  They seem to be scattered around in little clumps in terms
   of creation time, but other than that I can't detect a pattern by looking
   at them or their contents.  I assume these are files of messages which 
   never made it out of the system, but at what point are they created?  What
   kind of circumstances, specifically, need to arise for them to appear?

   For example, if the JNET system were shut down when someone sent a message
   to a BITNET address through PMDF, could that result in such a file?

2) Assuming they are messages which never made it out, what is required
   to get them sent on their way?  (The message contents and headers look
   fine, so I suspect they would just go out normally.)  Do I just need
   to rename them into one of the channel subdirectories?  (If so, which
   one?)

- John W. Manly  <JWMANLY@AMHERST.EDU>   System Manager -- Amherst College
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Question about $BITNET$xxx.00 files
From: "Ned Freed, Postmaster" <ned@hmcvax.claremont.edu>
Date: Tue, 7 Apr 1992 17:49 PST
Organization: The Internet
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Resent-Date: Tue, 7 Apr 1992 17:51 PST
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-Id: <01GIKP1C32SG8WWJX0@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"JWMANLY@amherst.edu"
X-Vms-Cc: ipmdf

> 1) What are all these $BITNET$xxxxx.00 files in the PMDF_ROOT:[QUEUE]
>    directory?  They seem to be scattered around in little clumps in terms
>    of creation time, but other than that I can't detect a pattern by looking
>    at them or their contents.  I assume these are files of messages which 
>    never made it out of the system, but at what point are they created?  
>    What kind of circumstances, specifically, need to arise for them to 
>    appear?

When PMDF sends files on to Jnet it must first create a temporary file. Some
forms of errors (like a system crash) can leave these files behind.

It depends on the version of PMDF you are running. Under PMDF V4.0 these
files are all garbage. The code is arranged in a way that guarantees this;
the original message will remain in the queue until a confirmation comes in
from Jnet saying that the message has been replicated in the Jnet queue.

Under earlier versions of PMDF there are some holes that will result in
message loss. This is caused by some types of errors that Jnet returns.

>   For example, if the JNET system were shut down when someone sent a message
>   to a BITNET address through PMDF, could that result in such a file?

Under versions of PMDF prior to V4.0 the answer is yes. V4.0 does not leave
such a file around when this happens.

> 2) Assuming they are messages which never made it out, what is required
>    to get them sent on their way?  (The message contents and headers look
>    fine, so I suspect they would just go out normally.)  Do I just need
>    to rename them into one of the channel subdirectories?  (If so, which
>    one?)

There are two sorts of files you'll find out there. Those that are in
BSMTP format can be placed in the [QUEUE.BIT_GATEWAY] directory to make
PMDF reprocess them itself. Those that don't have BSMTP envelopes must be
forwarded manually.

The real solution is to run V4.0, which never leaves you in a position where
you care what these files say.

				Ned
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Problems with forward to PMDF all the sudden
From: "Daniel C. Newman" <dan@hmcvax.claremont.edu>
Date: Mon, 13 Apr 1992 11:25 PST
Organization: The Internet
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Resent-Date: Mon, 13 Apr 1992 11:26 PST
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-Id: <01GISPC3H2N48WXCD5@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"DMPM@DUKEMC.BITNET"
X-Vms-Cc: IPMDF

> I am sending mail to a VMS .dis group and two addresses in it
> have forwards across DECnet to PMDF.  This worked fine for awhile
> and now I get:
> 
> %MAIL-E-SENDERR, error sending to user IN%"funde001@dukemc" at DUKEMC
> %MAIL-E-OPENIN, error opening  as input
> -RMS-E-ACC, ACP file access failed
> -SYSTEM-F-EXQUOTA, exceeded quota
> %MAIL-E-SENDERR, error sending to user IN%"polla001@dukemc" at DUKEMC
> -MAIL-E-PROTOCOL, network protocol error
> -SYSTEM-F-LINKABORT, network partner aborted logical link

This looks like a DECnet problem on the node DUKEMC.  My guess is that you're
sending to an address of the form DUKEMC::in%"funde001@dukemc" and for some
reason the remote DECnet task which runs on DUKEMC is failing.  You'll have to
look at the NETSERVER.LOG files on DUKEMC to figure out what is going wrong.

Dan
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Interpretation of delivery failure
From: "Ned Freed, Postmaster" <ned@hmcvax.claremont.edu>
Date: Wed, 8 Apr 1992 03:22 PST
Organization: The Internet
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Resent-Date: Wed, 8 Apr 1992 03:23 PST
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-Id: <01GIL912ICMO8WWSGR@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"SUE@A1.PSUPEN.PSU.EDU"
X-Vms-Cc: ipmdf

> Hi!  I'm running PMDF 4.0.  I received the following delivery failure but 
> I'm having difficulty deciding what (or who) is causing the problem.  I have
> a mailer registered (MAILER, not SMTPUSER).  Any help would be appreciated 
> since it appears that the originator of the message is not being told that 
> his message didn't make it.

This looks like a busted mailer to me -- not yours, the one on the other end.
The fact that the message is bouncing to SMTPUSER pretty much confirms it.

It may be just a configuration problem or it may be something deeper. There's
no way to tell from your end.

I do note that there's one thing that's a little strange in your 
configuration. Your registered mailer is MAILER@PSUPEN.BITNET. However, you
seem to use PSUPENA.BITNET as your official host name on your Jnet channels. I 
don't know what your Jnet configuration does; it may be that PSUPEN is a 
cluster alias or something. 

This configuration will generate a HELO line that does not agree with your
registered mailer name. I cannot say whethere either of these agrees with
the envelope host name on outgoing message -- the JAN_BN_MASTER_FLAGS logical
would control that if you have a Jnet cluster alias.

I would recommend making all three of these things agree -- your registered
mailer host, the local alias on your Jnet channels, and the host name that's
stamped on outgoing messages by Jnet.

					Ned