You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-user@james.apache.org by Steve Cockwell <st...@canux.com> on 2001/03/20 17:51:19 UTC

Infinite Loop, Error Messages, and Archiving

Hello all,

I'm relatively new to James and this list, and I have a couple of
questions after installing and configuring James in a RH7/MySQL/JDK1.3
environment.

1.  Somehow I put James into an infinite loop - I believe because error
messages were themselves generating errors (ie: the error mailet was
causing error messages...)  It took me a while to fix, but commenting
out the following entry in the error processor seemed to do the trick:

<mailet match="All" class="ToRepository"
	<repositoryPath> town://mail-error </repositoryPath>
	<passThrough> true </passThrough>
</mailet>

Instead I simply returned the error to both the sender and postmaster. 
I'm using the DBMS to store everything else and so I'm not sure why this
was a problem.  I suppose that would be my question.  Presumably this
problem may also occur with spam (although not the infinite looping of
course) but I haven't been able to test that yet...

2.  My second question is related to the first in a way.  If I send a
message to James destined to be delivered locally, but to a bogus user
id, I get the message back "We were unable to deliver the attached
message because of an error in the mail server."  Is there a way to get
this error to specify the exact problem such as "User Unknown" or
something?  I can't roll this out with such an error for fear of many
daily phone calls about a "problem with the mail server".

James is exactly what I want in a mail server.  I've done a lot of web
application development with ApacheJServ and now Tomcat.  Eventually I
hope I'm going to be able to build management tools for James with
Jakarta-Velocity - perhaps even an open-source web mail client...

Actually, I just thought of another question.  One of the things I'm
going to have to get James to do is to archive all sent and received
email somewhere (ideally outside of the DBMS).  I presume that I can
store messages in both the DBMS and in a file/directory somewhere, but
only process them from the DBMS...  Basically I need a way to make a
backup of all company email....

Thanks a TON for James!  You folks are doing GREAT WORK.

Cheers!

.src

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


Re: Infinite Loop, Error Messages, and Archiving

Posted by Steve Cockwell <st...@canux.com>.
Steve Cockwell wrote:

> 1.  Somehow I put James into an infinite loop - I believe because error
> messages were themselves generating errors (ie: the error mailet was
> causing error messages...)  It took me a while to fix, but commenting
> out the following entry in the error processor seemed to do the trick:
> 
> <mailet match="All" class="ToRepository"
>         <repositoryPath> town://mail-error </repositoryPath>
>         <passThrough> true </passThrough>
> </mailet>
> 
> Instead I simply returned the error to both the sender and postmaster.
> I'm using the DBMS to store everything else and so I'm not sure why this
> was a problem.  I suppose that would be my question.  Presumably this
> problem may also occur with spam (although not the infinite looping of
> course) but I haven't been able to test that yet...

Talking to yourself, they say, is the first sign of impending mental
collapse.  Be that as it may, the resolution to this problem lies in the
Message table structure itself.

It turns out that the field 'message_name' does not a primary key
make...  When james was moving message between repositories, it was not
changing the message ID.  Since (it would appear to me anyway) James
copies the message before removing it from the original repository, this
causes a duplicate key error in the DBMS.

Setting the combination of 'message_name' and 'repository_name' as
primary keys solves this problem (and makes more sense).  The file
./docs/james-message-mysql.sql from the distribution (james 1.2.1)
should look more like this:

DROP DATABASE mail;

CREATE DATABASE mail;

USE mail;

CREATE TABLE Message (
	message_name varchar (128) NOT NULL ,
	repository_name varchar (128) NOT NULL ,
	message_state varchar (30) NOT NULL ,
	error_message varchar (200) NULL ,
	sender varchar (100) NOT NULL ,
	recipients text NOT NULL ,
	remote_host varchar (100) NOT NULL ,
	remote_addr varchar (20) NOT NULL ,
	message_body longblob NOT NULL ,
	last_updated datetime NOT NULL ,
	PRIMARY KEY (message_name,repository_name)
);

CREATE TABLE Users (
	username varchar (32) NOT NULL PRIMARY KEY,
	password varchar (32) NOT NULL
);

> 2.  My second question is related to the first in a way.  If I send a
> message to James destined to be delivered locally, but to a bogus user
> id, I get the message back "We were unable to deliver the attached
> message because of an error in the mail server."  Is there a way to get
> this error to specify the exact problem such as "User Unknown" or
> something?  I can't roll this out with such an error for fear of many
> daily phone calls about a "problem with the mail server".

Nobody answered this question either, so I'm guessing it's either "no"
or "join the dev. list".

> Actually, I just thought of another question.  One of the things I'm
> going to have to get James to do is to archive all sent and received
> email somewhere (ideally outside of the DBMS).  I presume that I can
> store messages in both the DBMS and in a file/directory somewhere, but
> only process them from the DBMS...  Basically I need a way to make a
> backup of all company email....

I've tried unsuccessfully to create a separate table called Archive just
like the Message table and dump copies of all incoming and outgoing mail
messages in there.  However, it's quite easy to move copies of any
messages into a repository called archive as I'm sure you all know.  I
would like to vote now for this functionality if anyone is considering
adding this ability.
 
.src

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