You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Dave Rushall (JIRA)" <ji...@apache.org> on 2008/08/22 13:32:44 UTC
[jira] Created: (GERONIMO-4260) Multipart message from POP3 has
spurious attachment
Multipart message from POP3 has spurious attachment
---------------------------------------------------
Key: GERONIMO-4260
URL: https://issues.apache.org/jira/browse/GERONIMO-4260
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: mail
Environment: geronimo-javamail_1.4_mail-1.4.jar
IBM JRE 6 SR 1
Windows XP
Reporter: Dave Rushall
Priority: Minor
A multi-part message retrieved from a POP3 store is reported as having an extra attachment. For the message quoted below, Multipart.getCount() reports 3 when the correct answer is 2. Calling getBodyPart(0) and getBodyPart(1) returns the two valid parts as expected. Calling getBodyPart(2) returns a spurious "text/plain" attachment, which appears to consist of some blank lines and has no headers. Perhaps the MIME decoder is incorrectly interpreting the blank lines following the end boundary as an additional part?
RETR 1
+OK 1076 octets
Received: ***********************************************************
by *****************************************************************************
for ***********************************; Fri, 22 Aug 2008 12:17:00 +0100
Date: Fri, 22 Aug 2008 12:17:00 +0100
Message-Id: <200808221117.m7MBGxhc1310736@*************************>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0_070831_1751148640_104597052_1219403816453"; charset="ISO-8859-1"
Subject: Test message
To: *********************************
From: ***********************
Status: O
--0_070831_1751148640_104597052_1219403816453
Content-Type: text/html;
charset="UTF-8"
Content-Transfer-Encoding: base64
PGh0bWw+PGJvZHk+PHA+SGVsbG8gdGhlcmUhIEhvdyBhcmUgeW91IHRvZGF5PzwvcD48L2Jv
ZHk+PC9odG1sPg==
--0_070831_1751148640_104597052_1219403816453
Content-Location: attachment1.txt
Content-Disposition: attachment;
filename="attachment1.txt"
Content-Type: text/plain
Content-Transfer-Encoding: base64
QXR0YWNobWVudCAx
--0_070831_1751148640_104597052_1219403816453--
.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4260) Multipart message from POP3 has
spurious attachment
Posted by "Rick McGuire (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625335#action_12625335 ]
Rick McGuire commented on GERONIMO-4260:
----------------------------------------
I'm not able to reproduce the problem from this data. It might require using the same sequence of calls on the message object to reproduce. Could you include the code snippet that shows how you are getting this?
> Multipart message from POP3 has spurious attachment
> ---------------------------------------------------
>
> Key: GERONIMO-4260
> URL: https://issues.apache.org/jira/browse/GERONIMO-4260
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: mail
> Environment: geronimo-javamail_1.4_mail-1.4.jar
> IBM JRE 6 SR 1
> Windows XP
> Reporter: Dave Rushall
> Assignee: Rick McGuire
> Priority: Minor
>
> A multi-part message retrieved from a POP3 store is reported as having an extra attachment. For the message quoted below, Multipart.getCount() reports 3 when the correct answer is 2. Calling getBodyPart(0) and getBodyPart(1) returns the two valid parts as expected. Calling getBodyPart(2) returns a spurious "text/plain" attachment, which appears to consist of some blank lines and has no headers. Perhaps the MIME decoder is incorrectly interpreting the blank lines following the end boundary as an additional part?
> RETR 1
> +OK 1076 octets
> Received: ***********************************************************
> by *****************************************************************************
> for ***********************************; Fri, 22 Aug 2008 12:17:00 +0100
> Date: Fri, 22 Aug 2008 12:17:00 +0100
> Message-Id: <200808221117.m7MBGxhc1310736@*************************>
> MIME-Version: 1.0
> Content-Type: multipart/mixed; boundary="0_070831_1751148640_104597052_1219403816453"; charset="ISO-8859-1"
> Subject: Test message
> To: *********************************
> From: ***********************
> Status: O
> --0_070831_1751148640_104597052_1219403816453
> Content-Type: text/html;
> charset="UTF-8"
> Content-Transfer-Encoding: base64
> PGh0bWw+PGJvZHk+PHA+SGVsbG8gdGhlcmUhIEhvdyBhcmUgeW91IHRvZGF5PzwvcD48L2Jv
> ZHk+PC9odG1sPg==
> --0_070831_1751148640_104597052_1219403816453
> Content-Location: attachment1.txt
> Content-Disposition: attachment;
> filename="attachment1.txt"
> Content-Type: text/plain
> Content-Transfer-Encoding: base64
> QXR0YWNobWVudCAx
> --0_070831_1751148640_104597052_1219403816453--
> .
> (Note there are actually three blank lines between the end boundary and the '.' marker, but the extra white space is not showing up in the formatted description of this bug)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4260) Multipart message from POP3 has
spurious attachment
Posted by "Rick McGuire (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick McGuire resolved GERONIMO-4260.
------------------------------------
Resolution: Fixed
Committed revision 689164.
I was finally able to find a combination of conditions to recreate this.
> Multipart message from POP3 has spurious attachment
> ---------------------------------------------------
>
> Key: GERONIMO-4260
> URL: https://issues.apache.org/jira/browse/GERONIMO-4260
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: mail
> Environment: geronimo-javamail_1.4_mail-1.4.jar
> IBM JRE 6 SR 1
> Windows XP
> Reporter: Dave Rushall
> Assignee: Rick McGuire
> Priority: Minor
>
> A multi-part message retrieved from a POP3 store is reported as having an extra attachment. For the message quoted below, Multipart.getCount() reports 3 when the correct answer is 2. Calling getBodyPart(0) and getBodyPart(1) returns the two valid parts as expected. Calling getBodyPart(2) returns a spurious "text/plain" attachment, which appears to consist of some blank lines and has no headers. Perhaps the MIME decoder is incorrectly interpreting the blank lines following the end boundary as an additional part?
> RETR 1
> +OK 1076 octets
> Received: ***********************************************************
> by *****************************************************************************
> for ***********************************; Fri, 22 Aug 2008 12:17:00 +0100
> Date: Fri, 22 Aug 2008 12:17:00 +0100
> Message-Id: <200808221117.m7MBGxhc1310736@*************************>
> MIME-Version: 1.0
> Content-Type: multipart/mixed; boundary="0_070831_1751148640_104597052_1219403816453"; charset="ISO-8859-1"
> Subject: Test message
> To: *********************************
> From: ***********************
> Status: O
> --0_070831_1751148640_104597052_1219403816453
> Content-Type: text/html;
> charset="UTF-8"
> Content-Transfer-Encoding: base64
> PGh0bWw+PGJvZHk+PHA+SGVsbG8gdGhlcmUhIEhvdyBhcmUgeW91IHRvZGF5PzwvcD48L2Jv
> ZHk+PC9odG1sPg==
> --0_070831_1751148640_104597052_1219403816453
> Content-Location: attachment1.txt
> Content-Disposition: attachment;
> filename="attachment1.txt"
> Content-Type: text/plain
> Content-Transfer-Encoding: base64
> QXR0YWNobWVudCAx
> --0_070831_1751148640_104597052_1219403816453--
> .
> (Note there are actually three blank lines between the end boundary and the '.' marker, but the extra white space is not showing up in the formatted description of this bug)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4260) Multipart message from POP3 has
spurious attachment
Posted by "Rick McGuire (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick McGuire reassigned GERONIMO-4260:
--------------------------------------
Assignee: Rick McGuire
> Multipart message from POP3 has spurious attachment
> ---------------------------------------------------
>
> Key: GERONIMO-4260
> URL: https://issues.apache.org/jira/browse/GERONIMO-4260
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: mail
> Environment: geronimo-javamail_1.4_mail-1.4.jar
> IBM JRE 6 SR 1
> Windows XP
> Reporter: Dave Rushall
> Assignee: Rick McGuire
> Priority: Minor
>
> A multi-part message retrieved from a POP3 store is reported as having an extra attachment. For the message quoted below, Multipart.getCount() reports 3 when the correct answer is 2. Calling getBodyPart(0) and getBodyPart(1) returns the two valid parts as expected. Calling getBodyPart(2) returns a spurious "text/plain" attachment, which appears to consist of some blank lines and has no headers. Perhaps the MIME decoder is incorrectly interpreting the blank lines following the end boundary as an additional part?
> RETR 1
> +OK 1076 octets
> Received: ***********************************************************
> by *****************************************************************************
> for ***********************************; Fri, 22 Aug 2008 12:17:00 +0100
> Date: Fri, 22 Aug 2008 12:17:00 +0100
> Message-Id: <200808221117.m7MBGxhc1310736@*************************>
> MIME-Version: 1.0
> Content-Type: multipart/mixed; boundary="0_070831_1751148640_104597052_1219403816453"; charset="ISO-8859-1"
> Subject: Test message
> To: *********************************
> From: ***********************
> Status: O
> --0_070831_1751148640_104597052_1219403816453
> Content-Type: text/html;
> charset="UTF-8"
> Content-Transfer-Encoding: base64
> PGh0bWw+PGJvZHk+PHA+SGVsbG8gdGhlcmUhIEhvdyBhcmUgeW91IHRvZGF5PzwvcD48L2Jv
> ZHk+PC9odG1sPg==
> --0_070831_1751148640_104597052_1219403816453
> Content-Location: attachment1.txt
> Content-Disposition: attachment;
> filename="attachment1.txt"
> Content-Type: text/plain
> Content-Transfer-Encoding: base64
> QXR0YWNobWVudCAx
> --0_070831_1751148640_104597052_1219403816453--
> .
> (Note there are actually three blank lines between the end boundary and the '.' marker, but the extra white space is not showing up in the formatted description of this bug)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4260) Multipart message from POP3 has
spurious attachment
Posted by "Dave Rushall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dave Rushall updated GERONIMO-4260:
-----------------------------------
Description:
A multi-part message retrieved from a POP3 store is reported as having an extra attachment. For the message quoted below, Multipart.getCount() reports 3 when the correct answer is 2. Calling getBodyPart(0) and getBodyPart(1) returns the two valid parts as expected. Calling getBodyPart(2) returns a spurious "text/plain" attachment, which appears to consist of some blank lines and has no headers. Perhaps the MIME decoder is incorrectly interpreting the blank lines following the end boundary as an additional part?
RETR 1
+OK 1076 octets
Received: ***********************************************************
by *****************************************************************************
for ***********************************; Fri, 22 Aug 2008 12:17:00 +0100
Date: Fri, 22 Aug 2008 12:17:00 +0100
Message-Id: <200808221117.m7MBGxhc1310736@*************************>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0_070831_1751148640_104597052_1219403816453"; charset="ISO-8859-1"
Subject: Test message
To: *********************************
From: ***********************
Status: O
--0_070831_1751148640_104597052_1219403816453
Content-Type: text/html;
charset="UTF-8"
Content-Transfer-Encoding: base64
PGh0bWw+PGJvZHk+PHA+SGVsbG8gdGhlcmUhIEhvdyBhcmUgeW91IHRvZGF5PzwvcD48L2Jv
ZHk+PC9odG1sPg==
--0_070831_1751148640_104597052_1219403816453
Content-Location: attachment1.txt
Content-Disposition: attachment;
filename="attachment1.txt"
Content-Type: text/plain
Content-Transfer-Encoding: base64
QXR0YWNobWVudCAx
--0_070831_1751148640_104597052_1219403816453--
.
(Note there are actually three blank lines between the end boundary and the '.' marker, but the extra white space is not showing up in the formatted description of this bug)
was:
A multi-part message retrieved from a POP3 store is reported as having an extra attachment. For the message quoted below, Multipart.getCount() reports 3 when the correct answer is 2. Calling getBodyPart(0) and getBodyPart(1) returns the two valid parts as expected. Calling getBodyPart(2) returns a spurious "text/plain" attachment, which appears to consist of some blank lines and has no headers. Perhaps the MIME decoder is incorrectly interpreting the blank lines following the end boundary as an additional part?
RETR 1
+OK 1076 octets
Received: ***********************************************************
by *****************************************************************************
for ***********************************; Fri, 22 Aug 2008 12:17:00 +0100
Date: Fri, 22 Aug 2008 12:17:00 +0100
Message-Id: <200808221117.m7MBGxhc1310736@*************************>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0_070831_1751148640_104597052_1219403816453"; charset="ISO-8859-1"
Subject: Test message
To: *********************************
From: ***********************
Status: O
--0_070831_1751148640_104597052_1219403816453
Content-Type: text/html;
charset="UTF-8"
Content-Transfer-Encoding: base64
PGh0bWw+PGJvZHk+PHA+SGVsbG8gdGhlcmUhIEhvdyBhcmUgeW91IHRvZGF5PzwvcD48L2Jv
ZHk+PC9odG1sPg==
--0_070831_1751148640_104597052_1219403816453
Content-Location: attachment1.txt
Content-Disposition: attachment;
filename="attachment1.txt"
Content-Type: text/plain
Content-Transfer-Encoding: base64
QXR0YWNobWVudCAx
--0_070831_1751148640_104597052_1219403816453--
.
> Multipart message from POP3 has spurious attachment
> ---------------------------------------------------
>
> Key: GERONIMO-4260
> URL: https://issues.apache.org/jira/browse/GERONIMO-4260
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: mail
> Environment: geronimo-javamail_1.4_mail-1.4.jar
> IBM JRE 6 SR 1
> Windows XP
> Reporter: Dave Rushall
> Priority: Minor
>
> A multi-part message retrieved from a POP3 store is reported as having an extra attachment. For the message quoted below, Multipart.getCount() reports 3 when the correct answer is 2. Calling getBodyPart(0) and getBodyPart(1) returns the two valid parts as expected. Calling getBodyPart(2) returns a spurious "text/plain" attachment, which appears to consist of some blank lines and has no headers. Perhaps the MIME decoder is incorrectly interpreting the blank lines following the end boundary as an additional part?
> RETR 1
> +OK 1076 octets
> Received: ***********************************************************
> by *****************************************************************************
> for ***********************************; Fri, 22 Aug 2008 12:17:00 +0100
> Date: Fri, 22 Aug 2008 12:17:00 +0100
> Message-Id: <200808221117.m7MBGxhc1310736@*************************>
> MIME-Version: 1.0
> Content-Type: multipart/mixed; boundary="0_070831_1751148640_104597052_1219403816453"; charset="ISO-8859-1"
> Subject: Test message
> To: *********************************
> From: ***********************
> Status: O
> --0_070831_1751148640_104597052_1219403816453
> Content-Type: text/html;
> charset="UTF-8"
> Content-Transfer-Encoding: base64
> PGh0bWw+PGJvZHk+PHA+SGVsbG8gdGhlcmUhIEhvdyBhcmUgeW91IHRvZGF5PzwvcD48L2Jv
> ZHk+PC9odG1sPg==
> --0_070831_1751148640_104597052_1219403816453
> Content-Location: attachment1.txt
> Content-Disposition: attachment;
> filename="attachment1.txt"
> Content-Type: text/plain
> Content-Transfer-Encoding: base64
> QXR0YWNobWVudCAx
> --0_070831_1751148640_104597052_1219403816453--
> .
> (Note there are actually three blank lines between the end boundary and the '.' marker, but the extra white space is not showing up in the formatted description of this bug)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.