Vincenzo Gianferrari Pini wrote:
> If I understood correctly, the new behaviour is never adding
> a Return-Path header except during local delivery, and have
> getSender() == null being the only test done throughout the
> code.

The change is to rely upon the envelope sender (getSender()) rather than
the Return-Path header, and to add the Return-Path header when we make a
final delivery, as called for by RFC 2821.  The getSender == null check is
the check for <>, aka a null sender.

> Looking at the code, it seems all OK.

Cool.  So far the latest change seems to be working properly.  I'm not
seeing any further problems with header order.

> IMHO we should remove the
> AbstractRedirect#getExistingReturnPath(Mail mail)
> method as it becomes misleading and is no longer used.

I had thought about deprecating it, at the least.  Removing it is fine
with me.

> The same for org.apache.james.core.MailImpl#getReturnPath(MimeMessage
> message), that is also inconsistent with getExistingReturnPath(Mail
> mail) above. Being private, there should no problem at all to remove it.

Actually, we need that one.  It has a very specific use.  It is used when
creating a MailImpl from only a MimeMessage.  We no longer have the
envelope information, and need to reconstruct it from a delivered message.
The only use of that at present is in the MBoxRepository code.

        --- Noel

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to