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