> - I've not been able to run james in "Phoenix trunk"
Peter Royal indicated that he would help us with any Phoenix changes that we
really needed.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional comm
> Should we move to Loom?
Not if it means some of the things you noted. I am particularly not keen to
start using more excalibur code instead of Jakarta Commons code.
> we could avoid using DBCP at all.
But we want to use DBCP. It is well-tested, supported and broadly used.
And I really don't
> The advantages for the changes are:
5) Loom currently has a website (http://loom.codehaus.org/) with
informations for the deployer the administrator, the assembler and even if
it is not updated so often it is a lot better than the avalon site
(http://avalon.apache.org/closed.html).
More conside
Should we move to Loom?
I've tested it today and the changes I had to do in order to run inside Loom
have been:
1) remove all the spaces from XML: loom does not automatically remove spaces
so leaving the spaces in the config means misconfiguration.
2) change the data-source configuration to use
or
[ http://issues.apache.org/jira/browse/JAMES-413?page=all ]
Stefano Bagnara resolved JAMES-413:
---
Resolution: Fixed
I was working on DNSServer so I fixed this: Soren, please review the patch.
> James does not resolve CNAME DNS registrations
> ---
[ http://issues.apache.org/jira/browse/JAMES-413?page=all ]
Stefano Bagnara updated JAMES-413:
--
Attachment: DNSServerTest.java
The test I used to check the new feature.
Please note that www.pippo.com has no MX server but has a CNAME to pippo.com
pippo.
Author: bago
Date: Tue Sep 6 15:30:39 2005
New Revision: 279163
URL: http://svn.apache.org/viewcvs?rev=279163&view=rev
Log:
James did not resolve CNAME DNS registrations (JAMES-413).
We should carefully test this change.
Modified:
james/server/trunk/src/java/org/apache/james/dnsserver/DNSSer
[ http://issues.apache.org/jira/browse/JAMES-413?page=all ]
Stefano Bagnara reassigned JAMES-413:
-
Assign To: Stefano Bagnara (was: Soren Hilmer)
> James does not resolve CNAME DNS registrations
> --
>
>
OK, let me provide a use case.
Someone sends e-mail. I accept it as being for a local domain and find that
I need to generate a bounce, or I accept from an authorized sender for a
remote domain. Either way, when I try to deliver the e-mail, I end up
trying to send it to myself because the lookup
BTW, I'm not condoning the practise the practise or
anything.
Noel J. Bergman wrote:
Because it is an error if anyone else ever looks it up. Any remote system
would (attempt to) send to itself instead of you.
I am not sure how it's done exactly, but I think
that's taken care of by the eithe
Because it is an error if anyone else ever looks it up. Any remote system
would (attempt to) send to itself instead of you.
--- Noel
-Original Message-
From: Kervin L. Pierre [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 06, 2005 15:41
To: James Developers List
Subject: Re:
Noel J. Bergman wrote:
I'm seeing a problem where misconfigured domains (sometime I suspect
intentionally) have 127.0.0.1 for their MX record.
Lots of workstations run their own mail servers.
Why is it a misconfiguration?
Regards,
Kervin
-
On Tue, 2005-09-06 at 13:01 -0400, Noel J. Bergman wrote:
> I'm seeing a problem where misconfigured domains (sometime I suspect
> intentionally) have 127.0.0.1 for their MX record.
>
> Should we filter out 127/8, and not consider it valid in RemoteDelivery?
I think this could be an option but I
Author: bago
Date: Tue Sep 6 10:08:28 2005
New Revision: 279041
URL: http://svn.apache.org/viewcvs?rev=279041&view=rev
Log:
Forgot to add concurrent jar to the sar (used by cornerstone-datasources)
Modified:
james/server/trunk/build.xml
Modified: james/server/trunk/build.xml
URL:
http://sv
Author: bago
Date: Tue Sep 6 10:05:13 2005
New Revision: 279040
URL: http://svn.apache.org/viewcvs?rev=279040&view=rev
Log:
Not sure how did this work before, but it extends AbstractLogEnabled and should
use getLogger.
Found out this problem by deploying in LOOM (now it should be compatible with
> > Why "in v2.2.0 java.net.InetAddress.getByName() has pretty
> > thoroughly been replaced by
> > org.apache.james.dnsserver.DNSServer.getByName(), "
> IIRC java.net.InetAddress.getByName() does not respect the DNS TTL.
Correct.
--- Noel
--
I'm seeing a problem where misconfigured domains (sometime I suspect
intentionally) have 127.0.0.1 for their MX record.
Should we filter out 127/8, and not consider it valid in RemoteDelivery?
--- Noel
-
To unsubscribe,
>
> Why "in v2.2.0 java.net.InetAddress.getByName() has pretty
> thoroughly been replaced by
> org.apache.james.dnsserver.DNSServer.getByName(), " in the
> first place?
>
IIRC java.net.InetAddress.getByName() does not respect the DNS TTL.
Steve
--
[
http://issues.apache.org/jira/browse/JAMES-418?page=comments#action_12322745 ]
Stefano Bagnara commented on JAMES-418:
---
I tryed Loom-1.0 RC3 (based on phoenix 4.1.0alpha) and actually after a few
fixes in James it works correclty and we would not ne
> > > I'm experiencing spooling issues with file repositories too.
> > Actually, I have occassionally seen the same symptom with JDBC, too.
> Simple delay of messages or full hangs of single messages?
Just the simple delay.
As an aside, we need to make sure that dbfile is working with Derby. It
Stefano,
I use
getClass().getClassLoader() in SMTPHandlerChain for loading handler classes
in load() method.
Should I replace it with Thread.currentThread().getContextClassLoader()?
-- Anagha
On 9/6/05, Stefano Bagnara (JIRA) wrote:
>
> [
> http://issues.apache.org/jira/browse/JAMES
[
http://issues.apache.org/jira/browse/JAMES-418?page=comments#action_12322740 ]
Stefano Bagnara commented on JAMES-418:
---
The whole classloading issue should be demanded to the container.
In fact latest phoenix trunk contains code to automatically prov
> > Soren wrote:
> > > I am having trouble with the JamesSpoolManager in the trunk.
> > > I experience mails hanging in the spool, it looks like
> the offending
> > > piece of code is the return statement in line 418.
>
> To be clear, that is the return statement in
> process(MailImpl) that doe
Stefano Bagnara wrote:
> Soren wrote:
> > I am having trouble with the JamesSpoolManager in the trunk.
> > I experience mails hanging in the spool, it looks like the
> > offending piece of code is the return statement in line 418.
To be clear, that is the return statement in process(MailImpl) tha
> > I'm experiencing spooling issues with file repositories too.
>
> Well, I haven't until now :-(
Can you try downgrading to 2.2.0 and verify wether the issue is there or
not?
Can you try using db/derby to check wether the issue is there or not?
My tests results are that filerepositories have t
> I am having trouble with the JamesSpoolManager in the trunk.
> I experience mails hanging in the spool, it looks like the
> offending piece of code is the return statement in line 418.
> The reason I suspect that line is that I cannot reproduce the
> effect if I remove the line.
If you remove
On Tuesday 06 September 2005 14:59, Stefano Bagnara wrote:
> > Hi,
> >
> > I am having trouble with the JamesSpoolManager in the trunk.
> > I experience mails hanging in the spool, it looks like the
> > offending piece of code is the return statement in line 418.
> > The reason I suspect that line
> Hi,
>
> I am having trouble with the JamesSpoolManager in the trunk.
> I experience mails hanging in the spool, it looks like the
> offending piece of code is the return statement in line 418.
> The reason I suspect that line is that I cannot reproduce the
> effect if I remove the line.
>
>
Hi,
I am having trouble with the JamesSpoolManager in the trunk.
I experience mails hanging in the spool, it looks like the offending piece of
code is the return statement in line 418. The reason I suspect that line is
that I cannot reproduce the effect if I remove the line.
Have anyone seen so
[
http://issues.apache.org/jira/browse/JAMES-302?page=comments#action_12322721 ]
Danny Angus commented on JAMES-302:
---
"I seem to remember reading in some RFC that mail should always rely on DNS
information and should not be delivered base on local host ta
[ http://issues.apache.org/jira/browse/JAMES-394?page=all ]
Stefano Bagnara resolved JAMES-394:
---
Resolution: Fixed
> Remove OLD mm.mysql driver (not compatible with newer MySQL db)
> ---
Author: bago
Date: Tue Sep 6 02:09:51 2005
New Revision: 278947
URL: http://svn.apache.org/viewcvs?rev=278947&view=rev
Log:
Removed OLD mm.mysql driver (not compatible with newer MySQL db) (JAMES-394)
Removed:
james/server/trunk/lib/mm.mysql-2.0.14.jar
james/server/trunk/lib/mm.mysql.LIC
32 matches
Mail list logo
