Ben: Thank you for the explanation. I've tried it, and it works for messages sent to LISTSERV, but not for messages sent by LISTSERV (unless perhaps those messages were directed back through LISTSERV). I have tried to implement a similar procedure within the sendmail that is receiving messages from our LISTSERV, but doing so doesn't isolate LISTSERV. I've managed to capture some of the "Delivery error report from" messages after being received by only one sendmail, but not any "Undelivered mail" messages yet. I have managed to get a couple of the "Undelivered mail" messages delivered to my hotmail account, removing two pieces of our e-mail infrastructure from the mix. The messages arrived at my hotmail account after passing through only two sendmail-based SMTP servers, and they had the MIME boundary problem. I doubt that sendmail is mucking with the MIME boundaries, and I doubt that both hotmail and our local messaging servers would do it, both in the same way. The only piece left is LISTSERV. You may want to try generating an "Undelivered mail" message as follows: Subscribe an invalid e-mail address to a list, then try to set or change the password for that address via the web interface. LISTSERV should try to send a confirmation message to the invalid address, then generate an "Undelivered mail" message to the postmaster when sending the confirmation message fails. (That's what happens when I do it, at least.) Alex Ben Parker wrote: > 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.