[
http://issues.apache.org/jira/browse/JAMES-570?page=comments#action_12422153 ]
Stefano Bagnara commented on JAMES-570:
---------------------------------------
The problem seems to be related to code in MimeMessageWrapped added by Noel on
05/05/2005 (r168238)
"revision 109187 introduced a bug where if we had a real Return-Path header its
value would not be the first in the String[]. This tries to eliminate that
problem. We should still test to see if this hack is necessary at all, or if
InternetHeaders.setHeader("Return-Path", <value>) is smart enough in JavaMail
1.3.2 to put the header at the top, instead of in the middle."
I this also the comment to r109187 is usefult:
Additional adjustments to fix JAMES-264. InternetHeaders is an awkward class
to work with due its own internal handling of header order. This change takes
advantage of how InternetHeaders works, pre-placing a null placeholder for a
possible Return-Path header so that when setHeader is called, it will use that
placeholder, and remove any other Return-Path headers. It also ensures that
there are no other placeholders, providing a bit more control as we manipulate
the Delivered-To headers (and possibly other headers that JavaMail may want to
change internally, such as Message-ID, Date and Mime-Version).
InternetHeaders currently works differently if created with empty constructor
or from stream. In the first case it create an empty sorted list of headers to
keep positions, otherwise it does it the wrong way.
Changing the MailHeaders(InputStream) constructor to use the empty super
constructor and calling load(is) seems to fix this difference.
Norman is currently working on writing unit testing and to find a solution to
this issues.
> James insert a Return-Path: null in outgoing email
> --------------------------------------------------
>
> Key: JAMES-570
> URL: http://issues.apache.org/jira/browse/JAMES-570
> Project: James
> Issue Type: Bug
> Reporter: Norman Maurer
> Assigned To: Norman Maurer
> Priority: Blocker
> Fix For: 2.3.0b4
>
>
> At the moment james insert a Return-Path: null to outgoing emails. That is
> not correct. On outgoing emails no Return-Path should be insert.
> From RFC (http://www.faqs.org/rfcs/rfc821.html):
> When the receiver-SMTP makes the "final delivery" of a
> message it inserts at the beginning of the mail data a
> return path line. The return path line preserves the
> information in the <reverse-path> from the MAIL command.
> Here, final delivery means the message leaves the SMTP
> world. Normally, this would mean it has been delivered to
> the destination user, but in some cases it may be further
> processed and transmitted by another mail system.
> We have also to get sure what todo if there is allready one ( should never
> happen). Should we keep the header or strip it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
