Stephen, > > > >Are you sure this isn't a config problem? > > > > The config elements are cut and paste from the current James CVS HEAD. > If it's a config problem then its a James bug we need to fix because I'm > not getting any errors.
A configuration problem doesn't necessarily generate errors. Noel has informed me that the current James HEAD still has the buggy patch - as he mentions in his recent Avalon-dev email. > >Ignoring the empty command for > >the moment, it looks like your mail to "test@localhost" is being routed > to > >RemoteDelivery for processing. Maybe because it's in the spammer > blacklist? > >A posted configuration file might help immensely. > > > > The configuration is defintioned by a combination of two files: > > 1. avalon-sandbox/merlin/blocks.zml > 2. avalon-sandbox/merlin/src/test/config/james.xml I don't see anything immediately wrong, but I'm very concerned that only one blacklist check is listed. It looks like the source IP is matching the RBL blacklist, which is causing it to be rerouted. But I don't see why that would induce an outgoing connection. How many emails did you try to send over the course of this log? 1, 2, or 3? I'd also recommend that you check your spam repository to see if it contains any received mails. > Debug level is already enabled on the parent. In principal any child > loggers should be inheriting log priority levels of DEBUG unless James > is explicity overulling this - i.e. what is running should be full DEBUG > for everything unless I'm missing something or some explicit > configuration is required. You're missing something. :) Mailets do not use Avalon logging mechanisms. Here is neither the time nor place to address why this is the case, but it is nonetheless so. For interminable discussions please consult james-dev archives. :) That said, in order to get some debugging info you'll need to add a <debug>true</debug> child element to each of the mailets. Substantially more info should come through. Especially if RemoteDelivery is getting triggered. > I'm interested - but before posting something to me can you try > the following against your code base using the attache build file: > > The related resource you will need include: > > <james-dir> > > james.xml > james.properties > > <james-dir>/tests > > test.xml > test.properties > > The build files for both james and the tests simply point to the current > CVS builds for excalibur and cornerstone. Note - to build corenrstone > you will need excalibur-thead-1.1 which includes the bug fix concerning > pool max size control. You will also need to replace the > excalibur-thread-1.0 in phoenix lib with version 1.1. Not going to happen this minute, but I'll see if I can do it tonight. > This smells of something possible - I know I updated the CVS and made a > bunch of other changes and retured to the james test and things were > broken again. I'll resync against the James CVS and post results to > James Dev. See above comments. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
