Content-Transfer-Encoding: |
7bit |
Sender: |
|
Subject: |
|
From: |
|
Date: |
Thu, 15 Sep 2005 16:11:59 -0400 |
Content-Type: |
text/plain; charset=ISO-8859-1; format=flowed |
MIME-Version: |
1.0 |
Reply-To: |
|
Parts/Attachments: |
|
|
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
|
|
|