JAMES 2.2.1 Release Candidate?

["Noel J. Bergman" <no...@devtech.com>]

Guys,

I would like to put out a JAMES 2.2.1 Release Candidate so that we can all
look at it and decide that it looks good to release.  I would like to
include the patch I posted earlier this week as well as the changes already
committed by Vincenzo and Steve.  FWIW, a side-effect of the reverse path
handling change may be significantly reduced memory footprint, although
there is room for even more improvement.

Thoughts?  Has anyone other than Danny had time to look at the reverse path
handling changes?  Vincenzo, you need for me to commit these bounce castle
jars that I've got in the JAMES 2.1.1 test builds, right?  Anything else
anyone can think of?

I'm posting a test build to the usual place.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

RE: JAMES 2.2.1 Release Candidate?

["Noel J. Bergman" <no...@devtech.com>]

> I didn't noticed that subtle bug you mentioned

I'm still fighting it, but I think I've got it licked.  The problem is in
the lack of control we have with the InternetHeaders class.  It has a lot of
undocumented semantics that can really get in the way, and cause headers to
get out of order if you don't understand the undocumented behavior.

> the hardest part is to justify that there are no other places which
> contains incorrect dependency on the Return-Path.

I grep'd the source tree, and didn't see any, but that's why I want more
eyes on the code.  :-)

> the pop3 downloader(?)

Should be setting the envelope sender so that fetched messages look like all
others.  Similar for the mbox repository.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: JAMES 2.2.1 Release Candidate?

[Hontvari Jozsef <ho...@solware.com>]

> Thoughts?  Has anyone other than Danny had time to look at the reverse
path
> handling changes?  Vincenzo, you need for me to commit these bounce castle

I also read it carefully and it seems to be correct (but I didn't noticed
that subtle bug you mentioned). However the hardest part is to justify that
there are no other places which contains incorrect dependency on the
Return-Path. It must be tested well before releasing the final.

One other place comes into my mind, the pop3 downloader(?), which may be
affected, but I don't know that module at all and accidentally that is
likely the only place where it is legal to read the Return-Path header.


----- Original Message ----- 
From: "Noel J. Bergman" <no...@devtech.com>
To: "James-Dev Mailing List" <se...@james.apache.org>
Sent: Thursday, August 19, 2004 2:54 AM
Subject: JAMES 2.2.1 Release Candidate?


> Guys,
>
> I would like to put out a JAMES 2.2.1 Release Candidate so that we can all
> look at it and decide that it looks good to release.  I would like to
> include the patch I posted earlier this week as well as the changes
already
> committed by Vincenzo and Steve.  FWIW, a side-effect of the reverse path
> handling change may be significantly reduced memory footprint, although
> there is room for even more improvement.
>
> Thoughts?  Has anyone other than Danny had time to look at the reverse
path
> handling changes?  Vincenzo, you need for me to commit these bounce castle
> jars that I've got in the JAMES 2.1.1 test builds, right?  Anything else
> anyone can think of?
>
> I'm posting a test build to the usual place.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

RE: JAMES 2.2.1 Release Candidate?

["Noel J. Bergman" <no...@devtech.com>]

Vincenzo,

Those jars ARE in the test builds.  I'm verifying that we want them in CVS
or not.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: JAMES 2.2.1 Release Candidate?

[Vincenzo Gianferrari Pini <vi...@praxis.it>]

Noel J. Bergman wrote:

>Thoughts?  Has anyone other than Danny had time to look at the reverse path
>handling changes? 
>
I'll have a look at it tomorrow.

> Vincenzo, you need for me to commit these bounce castle
>jars that I've got in the JAMES 2.1.1 test builds, right?  Anything else
>anyone can think of
>
You mean 2.2.1 test builds, I suppose :-) Yes, please commit those jars 
for me , as I can't do it right now (very low speed and expensive 
connection for now):

   bcmail-jdk13-124.jar
   bcprov-jdk13-124.jar
   jce-jdk13-124.jar

They can be found in
   http://www.bouncycastle.org/latest_releases.html 

The "124" in the jar names above means the last available release from Bouncy Castle.

The server side signing functionality is complete: org.apache.james.transport.mailets.SMIMEAbstractSign, org.apache.james.transport.mailets.SMIMESign and org.apache.james.security.SMIMEAttributeNames are ready; org.apache.james.security.KeyHolder is also ready, but some javadoc is still missing in it (I'll try to commit it tomorrow, but anyhow the code is ready for RC). The next coming steps (signature verification and others) can go in a future 2.2.2.

Vincenzo



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

RE: JAMES 2.2.1 Release Candidate?

["Noel J. Bergman" <no...@devtech.com>]

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

Re: JAMES 2.2.1 Release Candidate?

[Vincenzo Gianferrari Pini <vi...@praxis.it>]

>Thoughts?  Has anyone other than Danny had time to look at the reverse path
>handling changes?
>  
>
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.
Looking at the code, it seems all OK.

IMHO we should remove the 
org.apache.james.transport.mailets.AbstractRedirect#getExistingReturnPath(Mail 
mail) method as it becomes misleading and is no longer used (at least in 
the official code - being protected it could be used by a mailet 
subclass somewhere, but it is very unlikely).

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.

Vincenzo