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.