While each error needs thorough investigation to know for sure, I have
run into several users who can get mail from a list and other responses
but generally don't get responses to commands or confirmation requests.

   When I've traced the session with the host (using LSMTP site features)
I've often found that the systems are not complying with the SMTP
standards (RFC 1123 Host Requirements) because they are rejecting E-mail
with an SMTP MAIL FROM address of "<>" (null).  The Null address MUST be
supported according to RFC 1123 and it is generally used in places where
you do NOT want to get a bounce - such as a magic cookie confirmation.

   The other day someone using POBOX.COM ran into this.  This user had
other accounts and could get mail ok when sending from them.  However, I
didn't do the tracing to check what was actually happening.

   The symptoms of this are that the LISTSERV and LSMTP logs look fine -
the request comes in and the confirmation information request goes out.
But the user never gets it.

   In the sample request for confirmation message the key header is:

Return-Path: <Mailer-Daemon>

which usually reflects the SMTP MAIL FROM address (not normally shown
otherwise - it is often DIFFERENT than the internal From: address).  But
in this case it just says "Mailer-Daemon" which seems to be inserted when
there isn't an address.  If you could "see" the SMTP command it would be
     MAIL FROM:<>
(The value is also used in the mail separator on unix mail folders which
start with "From ").

   I suspect that either the notice of expiration was sent with a
different MAIL FROM (like [log in to unmask]) or a different mail
handler handled it or this was a different problem altogether... ;-)

   As for a duplicate request to confirm I would suspect either an
impatient user who might have fired off more than one request or mail that
got duplicated on the way to LISTSERV...

   One other item which is sort of the reverse of this.  I've had
complaints from some USA.NET users lately that they don't get LIST mail
although I can see in the logs that it is being delivered to their system.
Is this a well known problem?  (Those were NOT the service messages but
the actual individual list item distributions which were failing).

   As always, your results might vary...

   Marty