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.