I recently had a problem with non-reception of a single restricted
list (pseudonym REST-L) from a listserv site from which I regularly received
one other restricted list and one open list without problems.  It eventually
resolved into our version of SMTPlink (v. 2.11) rejecting the messages because
one other user at our site was subscribed with two slightly different
addresses, one which made it think he was on one post office, the other saying
he was on a different one.  The genesis is below for others who may have a
similar problem.
 
        Approximately March of 95, our cc:Mail (then v. 2.1) post office had
grown to the point that it needed to be subdivided.  This subdivision was into
a master PO (AFIP01) and 4 subordinates (AFIP02 thru AFIP05).  (Users on the
master PO continued to be listed as "[log in to unmask]".)  My personal
address changed from "[log in to unmask]" to
"[log in to unmask]", indicating a location on one of the four
subordinate PO's.  I continue to receive mail addressed to the old address,
but the system inserts the new address into outgoing "From: " headers.  List
mail continued to arrive but I was unable to respond because "I" was not
subscribed.  Several listowners manually unsubscribed me and I resubscribed to
resolution of the non-posting problem.
 
        By the end of Mar. 96, a "REVIEW" command of REST-L showed my
colleague subscribed as (pseudonym) "[log in to unmask]".  Shortly after
this time, he attempted to post a message and was rejected as not being a
subscriber.  He sent a new "SUBSCRIBE REST-L" message and was added to the list
as "[log in to unmask]".  This occurred at about the time we
upgraded our mail system to cc:Mail v. 2.21.  (Unrelated confusing factor.)
 
        REST-L is not a terribly active list (2 messages total in April, 20 in
May) and it took me until mid-June to notice I wasn't getting any messages at
all.  A "REVIEW" command of REST-L showed my colleague subscribed as
"[log in to unmask]", as "[log in to unmask]", and me as
"[log in to unmask]" at our site.  The listowner confirmed to
me that there was list traffic and suggested our end had problems.  I tried
unsubscribing and re-subscribing without resolving the problem.  A "QUERY *"
command showed the same subscription options for REST-L and the other open
list I was subscribed to then at that site ([log in to unmask]).
 
        Multiple trials followed with different manipulations of addresses,
test accounts on different PO's, subscription to a second restricted list at
Emory, subscription from the Unix system outside the PC mail gateway, etc,
with our mail administrator being able to see messages from REST-L trapped in
the gateway, but without an apparent reason the messages were being trapped.
The listowner, the listserv administrator at the originating site, and L-Soft
(Listserv authors/developers/vendor) staff unanimously said "Got to find out
why YOUR gateway traps, it isn't the listserv program."  (Thanks folks, you
were right.)
 
        Suddenly it hit us:  SMTPlink configuration is setable with regard to
whether undeliverable messages are forwarded to the Postmaster (they weren't
being so), the level of information being retained in the gateway log (set to
minimal), and whether the log files were sent to the Postmaster at a defined
interval (default is no, and they weren't.)  On correction of these settings,
the following came up:
      Error messages from SMTPLINK log:
      13:42:20  (starting point of transaction)
                - Opening file SMTPLINK\Inbox\SM221370.to
                - Writing cc:Mail message
                - hause at afip02
                - hause at afip02
                - user2 at afip02
                - user2 at afip02
     ****->     - [log in to unmask]
     ****->     - user2 at AFIP01
 
     (Error)    - (106) Cannot set message recipient
     (Error)    - (1014) Name already exists in post office
     (Error)    - (41) Cannot write cc:Mail message
 
                - Renaming file
     ***->      - REMOVING FILE
 
       From the postmaster: "user2's name appears immediately as the cause of
the error. It appears that the gateway is thinking that user2 is on AFIP02,
then it thinks he's on AFIP01, then the error message appears."  The listowner
manually removed "[log in to unmask]", leaving his current address, from
the REST-L list and everything works again.
 
 
DAVID W. HAUSE          Office of the Armed Forces Medical Examiner
LTC, MC, USA            Armed Forces Institute of Pathology
Deputy Medical Examiner 14th St. and Alaska Ave., NW
Washington, DC 20306    ph. 301-319-0000, DSN 285-0000
email:  [log in to unmask]