On Thu, 15 Sep 2005 22:21:39 -0400, "Alexander J. Willman"
<[log in to unmask]> wrote:

>Please give an example of how one might capture copies of the 
>relevant DSNs from a production LISTSERV server, without adversely 
>affecting the production service,

OK, it isn't pretty and I don't have a handy unix system to try this on, but
in principle it ought to work.

Add another non-quiet address to the POSTMASTER= list (the same list youa re
on that gets these notifications.  Do this at LISTSERV, not at some external
routing application like your procmail scripts.  We do not want the mail to
be captured to ever leave the LISTSERV machine.  I'll assume for the sake of
illustration that the address is [log in to unmask]  (I'm not
sure what the difference is between lists.princeton.edu and
lists01.princeton.edu so you may need to modify this to make sure it stays
on the same machine.)

Create an alias address in sendmail on this machine similar to the normal
LISTSERV listname aliases.  Like this

capture: "|/usr/local/bin/lsv_amin /home/listserv/spool capture"

However, we do NOT want these files to collect in /home/listserv/spool/
(where LISTSERV may try to process them) but rather in a new directory you
create for this purpose:  /home/listserv/capture  So the final form of the
alias will be

capture: "|/usr/local/bin/lsv_amin /home/listserv/capture capture"

(the path to /usr/local/bin/lsv_amin on your system may also be different,
adjust as necessary)

Test by sending a msg to [log in to unmask]  This should produce a
file named ******.job in the /home/listserv/capture directory. Unfortunately
this file is in a special format ready for LISTSERV processing, and thus
unreadable as-is, but you can also copy in the jobview* executable from your
regular /home/listserv/spool/ to turn the files of interest back into plain
text.  

This process will capture all postmaster notification emails, including many
you don't want, as files.  So simulate this error with special setup
addresses and note the exact times of your tests that produce errors.  By
reading the exact time from the headers of the error email you get that
matches this problematic behavior, you should find the time the msg was sent
from LISTSERV.  Look for 1 (or perhaps more) files in the capture directory
at this same date/time and jobview them into plain text until you find the
file you want that is the exact LISTSERV output of the same job under
concern.

I said this wasn't pretty.  There may be other scripting methods to pipe
mail for a specific alias to a file written (in plain text) in a specific
directory.  That would probably be less trouble.  None of this will be
really easy, especially given your regular traffic levels.  

I suppose I'm going to this trouble because while I agree the MIME headers
are not correct, I do not share your assumption that the fault must be in
LISTSERV.  I think the change is being done by some agent outside of
LISTSERV.  I'm sure there would be lots more noise from a lot more unhappy
users if this were a widespread problem.  

Further, my efforts to reproduce the exact steps in your case on 3 different
servers (including one running 14.3 and two running 14.4) all produce a
consistent subject: line "Delivery error report from (FQDN of server)" for
both your original error (PW REPL) and Dan Wheeler's and my (slightly easier
to test) error on the PW ADD command.  i.e. the nature of the kind of error
did not produce a change in the Subject: line.  Further, none of my tests
had a subject line of simply "Subject: Undelivered mail".  Since I cannot
reproduce either the erroneous MIME headers or the 'interesting' change in
Subject: line, I am not statisfied we have sufficient proof that this is an
error in LISTSERV.  I remain open to further information from your
investigation on your installation where the problem is occurring.