> > Does Gump publish "nightlies" for James?
> it would be cool to have nighly published somewhere
? now that we have gump working again :-)
Absolutely not! GUMP is explicitly an untrusted system that is not
permitted to export artifacts other than text reports.
We can, if there is sufficient r
Jason Webb wrote:
>
> > -Original Message-
> > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
> > At
> > the least, I think that we should default to binding to
> localhost only.
>
> Given the current lack of security I'd vote for the
> NoopSystemManager any
> day
+1 to that!
-- Ste
On 8/17/05, Danny Angus <[EMAIL PROTECTED]> wrote:
>
> > I think it's better to have this committed and
> > changes between versions in svn
>
> +1 this is what we agreed with the students.
>
> Anagha:
> Now just submit incremental patches, you're doing a great job.
> Sorry I don't have time to p
On 8/17/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> I think it's better to have this committed and changes between versions in
> svn than having only patches in JIRA so I merged and applied the patch. I
> tested the code and it seems to work: we could always revert later if
> needed.
>
> Anag
> Everyone:
> Does Gump publish "nightlies" for James?
I asked the same a few days ago: it would be cool to have nighly published
somewhere now that we have gump working again :-)
Stefano
-
To unsubscribe, e-mail: [EMAIL PROTEC
> I think it's better to have this committed and
> changes between versions in svn
+1 this is what we agreed with the students.
Anagha:
Now just submit incremental patches, you're doing a great job.
Sorry I don't have time to pay closer attention!
If you want people to test it, post to this list
I think it's better to have this committed and changes between versions in
svn than having only patches in JIRA so I merged and applied the patch. I
tested the code and it seems to work: we could always revert later if
needed.
Anagha: can you add a check while loading the configuration that will a
Added:
james/server/trunk/src/java/org/apache/james/smtpserver/SMTPHandlerChain.java
URL:
http://svn.apache.org/viewcvs/james/server/trunk/src/java/org/apache/james/smtpserver/SMTPHandlerChain.java?rev=233185&view=auto
==
[ http://issues.apache.org/jira/browse/JAMES-410?page=all ]
Stefano Bagnara resolved JAMES-410:
---
Resolution: Fixed
> Re-enable EHLO support in RemoteDelivery
>
>
> Key: JAMES-410
> URL: ht
[ http://issues.apache.org/jira/browse/JAMES-52?page=all ]
Stefano Bagnara resolved JAMES-52:
--
Resolution: Fixed
It should be fully compliant now. SMTP server announce 8BITMIME, RemoteDelivery
tries to send in 8bit when remote server supports it a
Author: bago
Date: Wed Aug 17 07:35:49 2005
New Revision: 233184
URL: http://svn.apache.org/viewcvs?rev=233184&view=rev
Log:
8BITMIME support while delivering. Added conversion to 7bit when the transport
is not sun javamail and when the remote host does not support 8bitmime
(JAMES-52).
Also re-a
On 8/17/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> My personal opinion about this security issue is that handler writers are
> developers. They got an interface and should use it. If they cast to the
> real class we can't grant them it will work but I don't see any problem in
> doing that.
>
> [..]
> None of the commandhandlers throw exception except doAuth().
> Even the doData also handles the exception internally I was
> also planning to make onCommand throw exception. If so should
> it should the generic Exception. Should I throw the base
> class Exception?
You are right.
Proba
stefano, thanks for the feedback. find my responses inline
-- Anagha
On 8/17/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> A few notes/questions from a first review:
>
> 1) Your tipical onCommand implementation is:
>
>public void onCommand(SMTPSession session) {
>//deviation from
Hello,
Is anyone working on the IMAP source?
Do they need help?
What version is IMAP currently
scheduled for?
Is there a checklist of things to do
before IMAP is done somewhere? That
may help programmers looking to
contribute at least a bit of time
into it.
Regards,
Kervin
-
A few notes/questions from a first review:
1) Your tipical onCommand implementation is:
public void onCommand(SMTPSession session) {
//deviation from the Main code
//Instead of throwing exception just end the session
try{
doAUTH(session, session.getCommandA
> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
> Sent: 17 August 2005 01:02
> To: James Developers List
> Subject: Did we mean to enable JMX by default?
>
> > -
> class="org.apache.avalon.phoenix.components.manager.NoopSystemManager"
> > +
> class="org.apache.aval
[
http://issues.apache.org/jira/browse/JAMES-406?page=comments#action_12318984 ]
Soren Hilmer commented on JAMES-406:
Ahh, yes you are right it was the CVS that had the fixes.
> Investigate about libraries upgradability
> (cornerstone/excalibur/avalon
Author: bago
Date: Wed Aug 17 01:34:08 2005
New Revision: 233134
URL: http://svn.apache.org/viewcvs?rev=233134&view=rev
Log:
Reverted the kernel changes introduced while fixing JAMES-406.
We don't want to enable MX4J by default. Also added a comment for the future.
Modified:
james/server/trun
[
http://issues.apache.org/jira/browse/JAMES-406?page=comments#action_12318980 ]
Stefano Bagnara commented on JAMES-406:
---
Soren, differences between phoenix 4.0.1 and phoenix 4.0.4 are really FEW:
- An added log line in DefaultApplication.java
- Port c
> > -
> class="org.apache.avalon.phoenix.components.manager.NoopSystemManager"
> > +
> class="org.apache.avalon.phoenix.components.manager.MX4JSystemManager"
>
> We deliberately disabled JMX by default because of security
> issues. At the least, I think that we should def
[
http://issues.apache.org/jira/browse/JAMES-406?page=comments#action_12318979 ]
Soren Hilmer commented on JAMES-406:
I know of a few bugs in the Phoenix we currently use (from the top of my head
it had to do with JMX and classloading) which seams fixed
22 matches
Mail list logo
