[ 
http://issues.apache.org/jira/browse/JAMES-570?page=comments#action_12422180 ] 
            
Stefano Bagnara commented on JAMES-570:
---------------------------------------

InternetHeaders have this bugs:
1) if you load an header from stream then following addHeader will not follow 
"default" sorting.
2) if you add a Return-Path to headers loaded from a stream with a Return-Path 
in the bad place it will add the new Return-Path just before the old one, and 
not at the start of the message
3) if you replace a Return-Path to headers loaded from a stream with a 
Return-Path in the bad place it will put the new Return-Path in the same 
position of the old one.

So we changed MailHeaders to fix this issues:
1) Changed the default constructor to use the right one from the super class 
and then load the stream
2) Changed the setHeader and addHeader to correctly handle the Return-Path 
header

Then we removed all the custom routine introduced by Noel to fix the 
Return-Path issues that had the problem described by this issue and was no more 
needed with this update.

This fix also allowed to remove workaround code from MimeMessageTest (it worked 
around the Return-Path: null). I probably have been too lazy inserting this 
workaround instead of trying to understand why it was there when testing.

Btw all the tests now passes, feel free to test it and backport to 2.3

> 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
>    Affects Versions: 2.3.0b3
>            Reporter: Norman Maurer
>         Assigned To: Norman Maurer
>            Priority: Blocker
>             Fix For: 3.0, 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]

Reply via email to