Fellow LISTSERV Site Maintainers: Our installation of LISTSERV, version 14.3 on Solaris 8, appears to be generating inconsistent MIME boundaries when it sends Delivery Status Notification messages. Here is an example of such a message, with the Received headers removed, and the beginning and end of the message indicated by asterisks: ********** beginning of message ********** Date: Wed, 14 Sep 2005 22:44:29 -0400 From: [log in to unmask] Subject: Undelivered mail To: "[log in to unmask] c/o LISTSERV postmaster" <[log in to unmask]> Message-id: <[log in to unmask]> MIME-version: 1.0 Content-type: multipart/report; report-type=delivery-status; boundary=--HQMTEQaJeNcOPZUAIbccPKHJWVUALb X-Spam-KB: http://www.Princeton.EDU/spam Original-recipient: rfc822;[log in to unmask] --HQMTEQaJeNcOPZUAIbccPKHJWVUALb --> Error description: Error-For: [log in to unmask] Error-Code: 5.1.1 Error-Text: 550 5.1.1 <[log in to unmask]>... User unknown. Error-End: One error reported. --HQMTEQaJeNcOPZUAIbccPKHJWVUALb Content-Type: message/delivery-status Reporting-MTA: dns; LISTS.PRINCETON.EDU Final-Recipient: RFC822; [log in to unmask] Action: failed Status: 5.1.1 (550 5.1.1 <[log in to unmask]>... User unknown) --HQMTEQaJeNcOPZUAIbccPKHJWVUALb Content-Type: message/rfc822 Date: Wed, 14 Sep 2005 22:40:18 -0400 From: "Princeton University LISTSERV Server (14.3)" <[log in to unmask]> Subject: Command confirmation request (F338043F) To: [log in to unmask] Message-ID: <[log in to unmask]> Your command: PW REP ******** requires confirmation. To confirm the execution of your command, simply point your browser to the following URL: http://lists.princeton.edu/cgi-bin/wa?OK=[CENSORED] Alternatively, if you have no WWW access, you can reply to the present message and type "ok" (without the quotes) as the text of your message. Just the word "ok" - do not retype the command. This procedure will work with any mail program that fully conforms to the Internet standards for electronic mail. If you receive an error message, try sending a new message to [log in to unmask] (without using the "reply" function - this is very important) and type "ok [CENSORED]" as the text of your message. Finally, your command will be cancelled automatically if LISTSERV does not receive your confirmation within 48h. After that time, you must start over and resend the command to get a new confirmation code. If you change your mind and decide that you do NOT want to confirm the command, simply discard the present message and let the request expire on its own. ------------------------- Original mail header -------------------------- X-Received: by LISTS.PRINCETON.EDU via 127.0.0.1 with TCP/IP (TCPGUI protocol, anonymous access) --HQMTEQaJeNcOPZUAIbccPKHJWVUALb-- ********** end of message ********** To be consistent with the declared MIME boundary, the boundary markers within the message and the terminal boundary marker should begin with two more dashes. Alternatively, the declared boundary could begin with two fewer dashes. The following would represent consistent MIME boundaries: Content-type: multipart/mixed; boundary="ABCXYZ" --ABCXYZ part one --ABCXYZ part two --ABCXYZ-- but LISTSERV appears to be generating MIME boundaries like the following: Content-type: multipart/mixed; boundary="--ABCXYZ" --ABCXYZ part one --ABCXYZ part two --ABCXYZ-- The effect of this problem is that recipients of the DSNs cannot see the the error message within their e-mail clients, because the e-mail clients cannot find a MIME boundary matching the declared boundary, and (correctly) ignore the content of the message. Have any of you seen this problem or have an idea what may be going wrong? Thank you. Alex ---------- Alexander Willman Office of Information Technology Princeton University