RE: Anti-SPAM mailet
(4) You might want to look at http://sourceforge.net/projects/pop3filterproxy/ Wouldn't this be outside of James though? I meant for some additional ideas on filtering spam. :-) (5) If we have a generic RegexMatcher ... This seems like a worthy project to get the experience with... And not too difficult, either. :-) (6) We'll want a mailet capable of tagging a message. Are there any examples that have this functionality? Yes and no. There are examples of adding headers, but nothing generic. Perhaps because there isn't a means (yet) to tag meta data on a mail object, which could be used to communicate between different James components. That could be used to convey information such as a non-binary spam rating or a spam reason. But for a simple binary rating, one could do something like: mailet matcher=SpamScan=... class=AddHeader headerX-SPAM: true/header /mailet Or we could drop the notion of a seperate matcher (for now), and combine the two: mailet matcher=All class=SpamScanner param.../param /mailet Anyhow, that's just an idea. See you on the developer's list. --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-james/src/java/org/apache/james/remotemanager package.html RemoteManager.java RemoteManagerHandler.java
pgoldstein2002/08/18 00:21:10
Modified:src/java/org/apache/james/remotemanager RemoteManager.java
RemoteManagerHandler.java
Added: src/java/org/apache/james/remotemanager package.html
Log:
Added extensive commenting
Revision ChangesPath
1.8 +20 -0
jakarta-james/src/java/org/apache/james/remotemanager/RemoteManager.java
Index: RemoteManager.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/remotemanager/RemoteManager.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- RemoteManager.java12 Aug 2002 18:51:11 - 1.7
+++ RemoteManager.java18 Aug 2002 07:21:09 - 1.8
@@ -35,6 +35,12 @@
return new DefaultHandlerFactory( RemoteManagerHandler.class );
}
+/**
+ * Pass the codeConfiguration/code to the instance.
+ *
+ * @param configuration the class configurations.
+ * @throws ConfigurationException if an error occurs
+ */
public void configure( final Configuration configuration )
throws ConfigurationException {
@@ -61,6 +67,13 @@
super.configure( configuration.getChild( handler ) );
}
+/**
+ * Initialize the component. Initialization includes
+ * allocating any resources required throughout the
+ * components lifecycle.
+ *
+ * @throws Exception if an error occurs
+ */
public void initialize() throws Exception {
getLogger().info( RemoteManager init... );
StringBuffer infoBuffer =
@@ -76,6 +89,13 @@
getLogger().info(RemoteManager ...init end);
}
+/**
+ * The dispose operation is called at the end of a components lifecycle.
+ * Instances of this class use this method to release and destroy any
+ * resources that they own.
+ *
+ * @throws Exception if an error is encountered during shutdown
+ */
public void dispose()
{
getLogger().info( RemoteManager dispose... );
1.13 +67 -10
jakarta-james/src/java/org/apache/james/remotemanager/RemoteManagerHandler.java
Index: RemoteManagerHandler.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/remotemanager/RemoteManagerHandler.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- RemoteManagerHandler.java 10 Aug 2002 17:53:08 - 1.12
+++ RemoteManagerHandler.java 18 Aug 2002 07:21:09 - 1.13
@@ -55,15 +55,47 @@
private UsersStore usersStore;
private UsersRepository users;
-private boolean inLocalUsers = true;
+
+/**
+ * The scheduler used to handle timeouts for the RemoteManager
+ * interaction
+*/
private TimeScheduler scheduler;
private MailServer mailServer;
+/**
+ * Whether the local users repository should be used to store new
+ * users.
+ */
+private boolean inLocalUsers = true;
+
+/**
+ * The reader associated with incoming commands.
+ */
private BufferedReader in;
+
+/**
+ * The writer to which outgoing messages are written.
+ */
private PrintWriter out;
-private HashMap admaccount = new HashMap();
+
+/**
+ * The TCP/IP socket over which the RemoteManager interaction
+ * is occurring
+ */
private Socket socket;
+/**
+ * A HashMap of (user id, passwords) for James administrators
+ */
+private HashMap admaccount = new HashMap();
+
+/**
+ * Pass the codeConfiguration/code to the instance.
+ *
+ * @param configuration the class configurations.
+ * @throws ConfigurationException if an error occurs
+ */
public void configure( final Configuration configuration )
throws ConfigurationException {
@@ -78,6 +110,15 @@
}
}
+/**
+ * Pass the codeComponentManager/code to the codecomposer/code.
+ * The instance uses the specified codeComponentManager/code to
+ * acquire the components it needs for execution.
+ *
+ * @param componentManager The codeComponentManager/code which this
+ *codeComposable/code uses.
+ * @throws ComponentException if an error occurs
+ */
public void compose( final ComponentManager componentManager )
throws ComponentException {
@@ -95,8 +136,8 @@
* This handler is responsible for processing connections as they occur.
*
* @param connection the connection
- * @exception IOException if an error reading from socket occurs
- * @exception ProtocolException if an error handling
cvs commit: jakarta-james/src/java/org/apache/james/pop3server POP3Handler.java
pgoldstein2002/08/18 00:27:51
Modified:src/java/org/apache/james/transport JamesSpoolManager.java
src/java/org/apache/james/transport/mailets
RemoteDelivery.java
src/java/org/apache/james/pop3server POP3Handler.java
Log:
Added null check after retrieving mail from repository. This avoids
spurious NPEs. Thanks to Noel Bergman
Revision ChangesPath
1.13 +5 -2
jakarta-james/src/java/org/apache/james/transport/JamesSpoolManager.java
Index: JamesSpoolManager.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/transport/JamesSpoolManager.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- JamesSpoolManager.java16 Aug 2002 17:08:53 - 1.12
+++ JamesSpoolManager.java18 Aug 2002 07:27:51 - 1.13
@@ -301,6 +301,9 @@
try {
String key = spool.accept();
MailImpl mail = spool.retrieve(key);
+// Retrieve can return null if the mail is no longer on the spool
+// (i.e. another thread has gotten to it first).
+// In this case we simply continue to the next key
if (mail == null) {
continue;
}
1.23 +7 -2
jakarta-james/src/java/org/apache/james/transport/mailets/RemoteDelivery.java
Index: RemoteDelivery.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/transport/mailets/RemoteDelivery.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- RemoteDelivery.java 9 Aug 2002 06:04:22 - 1.22
+++ RemoteDelivery.java 18 Aug 2002 07:27:51 - 1.23
@@ -516,6 +516,11 @@
.append(key);
log(logMessageBuffer.toString());
MailImpl mail = outgoing.retrieve(key);
+// Retrieve can return null if the mail is no longer on the
outgoing spool.
+// In this case we simply continue to the next key
+if (mail == null) {
+continue;
+}
if (deliver(mail, session)) {
//Message was successfully delivered/fully failed... delete
it
outgoing.remove(key);
1.10 +5 -0
jakarta-james/src/java/org/apache/james/pop3server/POP3Handler.java
Index: POP3Handler.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/pop3server/POP3Handler.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- POP3Handler.java 15 Aug 2002 21:57:27 - 1.9
+++ POP3Handler.java 18 Aug 2002 07:27:51 - 1.10
@@ -260,6 +260,11 @@
for (Iterator it = userInbox.list(); it.hasNext(); ) {
String key = (String) it.next();
MailImpl mc = userInbox.retrieve(key);
+// Retrieve can return null if the mail is no longer in the store.
+// In this case we simply continue to the next key
+if (mc == null) {
+continue;
+}
userMailbox.addElement(mc);
}
backupUserMailbox = (Vector) userMailbox.clone();
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-james/src/java/org/apache/james/nntpserver/repository ArticleIDRepository.java NNTPRepositoryImpl.java NNTPSpooler.java
pgoldstein2002/08/18 00:30:18
Modified:src/java/org/apache/james/nntpserver ArticleWriter.java
AuthService.java AuthServiceImpl.java
LISTGroup.java NNTPHandler.java NNTPServer.java
src/java/org/apache/james/nntpserver/repository
ArticleIDRepository.java NNTPRepositoryImpl.java
NNTPSpooler.java
Log:
Added comments, adjusted spacing.
Revision ChangesPath
1.4 +1 -1
jakarta-james/src/java/org/apache/james/nntpserver/ArticleWriter.java
Index: ArticleWriter.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/nntpserver/ArticleWriter.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ArticleWriter.java18 Jan 2002 02:48:36 - 1.3
+++ ArticleWriter.java18 Aug 2002 07:30:17 - 1.4
@@ -14,7 +14,7 @@
/**
* used by ARTICLE, HEAD, BODY, STAT command.
- * these commands are identical except in the writing the Article header
+ * these commands are identical except in how they write the Article header
* and body to the response stream
* ARTICLE - writes header and body
* HEAD - writes headers
1.3 +28 -1
jakarta-james/src/java/org/apache/james/nntpserver/AuthService.java
Index: AuthService.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/nntpserver/AuthService.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- AuthService.java 3 Jun 2002 16:07:06 - 1.2
+++ AuthService.java 18 Aug 2002 07:30:17 - 1.3
@@ -8,16 +8,43 @@
package org.apache.james.nntpserver;
/**
- * Authenticates users and
+ * Authenticates users and provides
* Access Control for User Commands.
*
* @author Harmeet [EMAIL PROTECTED]
*/
public interface AuthService {
+
+/**
+ * The component role used by components implementing this service
+ */
String ROLE = org.apache.james.nntpserver.AuthService;
+/**
+ * Check whether the service is authenticated
+ *
+ * @return true if the user and password have been set and are valid, false
otherwise
+ */
boolean isAuthenticated();
+
+/**
+ * Set the user id for this service
+ *
+ * @param userid the user id for this AuthService
+ */
void setUser(String userid);
+
+/**
+ * Set the password for this service
+ *
+ * @param password the password for this AuthService
+ */
void setPassword(String password);
+
+/**
+ * Check whether the service is authenticated
+ *
+ * @return true if the user is authenticated and is authorized to execute this
command
+ */
boolean isAuthorized(String command);
}
1.5 +15 -0
jakarta-james/src/java/org/apache/james/nntpserver/AuthServiceImpl.java
Index: AuthServiceImpl.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/nntpserver/AuthServiceImpl.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- AuthServiceImpl.java 7 Aug 2002 23:37:02 - 1.4
+++ AuthServiceImpl.java 18 Aug 2002 07:30:17 - 1.5
@@ -52,6 +52,15 @@
return allowed;
}
+/**
+ * Pass the codeComponentManager/code to the codecomposer/code.
+ * The instance uses the specified codeComponentManager/code to
+ * acquire the components it needs for execution.
+ *
+ * @param componentManager The codeComponentManager/code which this
+ *codeComposable/code uses.
+ * @throws ComponentException if an error occurs
+ */
public void compose( final ComponentManager componentManager )
throws ComponentException
{
@@ -59,6 +68,12 @@
repo = usersStore.getRepository(LocalUsers);
}
+/**
+ * Pass the codeConfiguration/code to the instance.
+ *
+ * @param configuration the class configurations.
+ * @throws ConfigurationException if an error occurs
+ */
public void configure( Configuration configuration ) throws
ConfigurationException {
authRequired =
configuration.getChild(authRequired).getValueAsBoolean(false);
1.5 +3 -0
jakarta-james/src/java/org/apache/james/nntpserver/LISTGroup.java
Index: LISTGroup.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/nntpserver/LISTGroup.java,v
retrieving revision 1.4
retrieving revision 1.5
cvs commit: jakarta-james/src/java/org/apache/james BaseConnectionHandler.java Constants.java James.java Main.java
pgoldstein2002/08/18 00:32:38
Modified:src/java/org/apache/james BaseConnectionHandler.java
Constants.java James.java Main.java
Log:
Added comments.
Fixed a minor threading bug.
Removed a few unused and undocumented constants.
Revision ChangesPath
1.9 +6 -0
jakarta-james/src/java/org/apache/james/BaseConnectionHandler.java
Index: BaseConnectionHandler.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/BaseConnectionHandler.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- BaseConnectionHandler.java17 Apr 2002 02:56:31 - 1.8
+++ BaseConnectionHandler.java18 Aug 2002 07:32:38 - 1.9
@@ -27,6 +27,12 @@
protected int timeout;
protected String helloName;
+/**
+ * Pass the codeConfiguration/code to the instance.
+ *
+ * @param configuration the class configurations.
+ * @throws ConfigurationException if an error occurs
+ */
public void configure( final Configuration configuration )
throws ConfigurationException {
1.5 +21 -9 jakarta-james/src/java/org/apache/james/Constants.java
Index: Constants.java
===
RCS file: /home/cvs/jakarta-james/src/java/org/apache/james/Constants.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- Constants.java25 Sep 2001 04:51:19 - 1.4
+++ Constants.java18 Aug 2002 07:32:38 - 1.5
@@ -19,21 +19,33 @@
*/
public class Constants {
+/**
+ * The version of James.
+ */
public static final String SOFTWARE_VERSION = @@VERSION@@;
+/**
+ * The name of the software (i.e. James).
+ */
public static final String SOFTWARE_NAME = @@NAME@@;
+/**
+ * Context key used to store the list of mail domains being
+ * serviced by this James instance in the context.
+ */
public static final String SERVER_NAMES = SERVER_NAMES;
-public static final String SPOOL_REPOSITORY = SPOOL_REPOSITORY;
-
-public static final String LOCAL_USERS = LOCAL_USERS;
-
+/**
+ * Context key used to store the postmaster address for
+ * this James instance in the context.
+ */
public static final String POSTMASTER = POSTMASTER;
-public static final int HEADERLIMIT = 2048;
-
+/**
+ * Key used to store the component manager for
+ * this James instance in a way accessible by
+ * Avalon aware Mailets.
+ */
public static final String AVALON_COMPONENT_MANAGER = AVALON_COMP_MGR;
-public static final String BUILD_DATE = @@DATE@@;
}
1.26 +57 -6 jakarta-james/src/java/org/apache/james/James.java
Index: James.java
===
RCS file: /home/cvs/jakarta-james/src/java/org/apache/james/James.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- James.java15 Aug 2002 07:07:21 - 1.25
+++ James.java18 Aug 2002 07:32:38 - 1.26
@@ -77,36 +77,83 @@
private String inboxRootURL;
private UsersRepository localusers;
private Collection serverNames;
+
+/**
+ * Whether to ignore case when looking up user names on this server
+ */
private boolean ignoreCase;
+
+/**
+ * Whether to enable aliasing for users on this server
+ */
private boolean enableAliases;
+
+/**
+ * Whether to enable forwarding for users on this server
+ */
private boolean enableForwarding;
-// this used to be long, but increment operations on long are not
-// thread safe. Changed to int. 'int' should be ok, because id generation
-// is based on System time and count
-private static int count;
+/**
+ * The number of mails generated. Access needs to be synchronized for
+ * thread safety and to ensure that all threads see the latest value.
+ */
+private static long count;
private MailAddress postmaster;
private Map mailboxes; //Not to be shared!
+
+/**
+ * A hash table of server attributes
+ */
private Hashtable attributes = new Hashtable();
+/**
+ * The Avalon context used by the instance
+ */
protected Context myContext;
+/**
+ * Pass the Context to the component.
+ * This method is called after the setLogger()
+ * method and before any other method.
+ *
+ * @param context the context
+ * @throws ContextException if context is invalid
+ */
public void contextualize(final
cvs commit: jakarta-james/src/conf sqlResources.xml
pgoldstein2002/08/18 00:57:34
Modified:src/conf sqlResources.xml
Log:
Removed tabs
Adjusted column lengths to match RFCs.
Thanks to Noel Bergman for the patch
Revision ChangesPath
1.12 +81 -83jakarta-james/src/conf/sqlResources.xml
Index: sqlResources.xml
===
RCS file: /home/cvs/jakarta-james/src/conf/sqlResources.xml,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- sqlResources.xml 27 Feb 2002 03:09:23 - 1.11
+++ sqlResources.xml 18 Aug 2002 07:57:34 - 1.12
@@ -54,9 +54,9 @@
WHERE username = ?
/sql
sql name=deleteDELETE FROM ${table} WHERE username = ?/sql
-sql name=createTableCREATE TABLE ${table} (username VARCHAR(50) NOT NULL,
pwdHash VARCHAR(50), pwdAlgorithm VARCHAR(20), useForwarding SMALLINT,
forwardDestination VARCHAR(250), useAlias SMALLINT, alias VARCHAR(250), PRIMARY
KEY(username))/sql
+sql name=createTableCREATE TABLE ${table} (username VARCHAR(64) NOT NULL,
pwdHash VARCHAR(50), pwdAlgorithm VARCHAR(20), useForwarding SMALLINT,
forwardDestination VARCHAR(255), useAlias SMALLINT, alias VARCHAR(255), PRIMARY
KEY(username))/sql
!-- An example of a database-specific sql statement
-sql name=createTable db=mssqlCREATE TABLE ${table} (uniqueId
UNIQUEIDENTIFIER, username VARCHAR(50) NOT NULL, pwdHash VARCHAR(50), pwdAlgorithm
VARCHAR(20), useForwarding SMALLINT, forwardDestination VARCHAR(250), useAlias
SMALLINT, alias VARCHAR(250), PRIMARY KEY(username))/sql
+sql name=createTable db=mssqlCREATE TABLE ${table} (uniqueId
UNIQUEIDENTIFIER, username VARCHAR(64) NOT NULL, pwdHash VARCHAR(50), pwdAlgorithm
VARCHAR(20), useForwarding SMALLINT, forwardDestination VARCHAR(255), useAlias
SMALLINT, alias VARCHAR(255), PRIMARY KEY(username))/sql
--
/sqlDefs
@@ -75,7 +75,7 @@
WHERE username = ?
/sql
sql name=deleteDELETE FROM ${table} WHERE username = ?/sql
-sql name=createTableCREATE TABLE ${table} (username VARCHAR(50) NOT NULL,
pwdHash VARCHAR(50), pwdAlgorithm VARCHAR(20), PRIMARY KEY(username))/sql
+sql name=createTableCREATE TABLE ${table} (username VARCHAR(64) NOT NULL,
pwdHash VARCHAR(50), pwdAlgorithm VARCHAR(20), PRIMARY KEY(username))/sql
/sqlDefs
!-- SQL statements for the ListUsersJdbcRepository
@@ -101,7 +101,7 @@
sql name=deleteDELETE FROM ${table}
WHERE listSubscriber = ? AND listName = '${key}'
/sql
-sql name=createTableCREATE TABLE ${table} (listName VARCHAR(50) NOT NULL,
listSubscriber VARCHAR(50) NOT NULL)/sql
+sql name=createTableCREATE TABLE ${table} (listName VARCHAR(64) NOT NULL,
listSubscriber VARCHAR(255) NOT NULL)/sql
/sqlDefs
!-- SQL statements for the JdbcMailRepository --
@@ -118,47 +118,46 @@
sql name=listMessagesSQLSELECT message_name, message_state, last_updated
FROM ${table} WHERE repository_name = ? ORDER BY last_updated ASC/sql
sql name=createTable db=mysql
CREATE TABLE ${table} (
- message_name varchar (200) NOT NULL,
- repository_name varchar (200) NOT NULL,
- message_state varchar (30) NOT NULL ,
- error_message varchar (200) NULL ,
- sender varchar (200) 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)
+message_name varchar (200) NOT NULL,
+repository_name varchar (255) NOT NULL,
+message_state varchar (30) NOT NULL ,
+error_message varchar (200) NULL ,
+sender varchar (255) NULL ,
+recipients text NOT NULL ,
+remote_host varchar (255) NOT NULL ,
+remote_addr varchar (20) NOT NULL ,
+message_body longblob NOT NULL ,
+last_updated datetime NOT NULL,
+PRIMARY KEY (message_name, repository_name)
)
/sql
sql name=createTable db=mssql
CREATE TABLE [${table}] (
- [message_name] [varchar] (200) NOT NULL,
- [repository_name] [varchar] (200) NOT NULL,
- [message_state] [varchar] (30) NOT NULL ,
- [error_message] [varchar] (1000) NULL ,
- [sender] [varchar] (200) NULL ,
- [recipients] [text] NOT NULL ,
- [remote_host] [varchar] (100) NOT NULL ,
- [remote_addr] [varchar] (20) NOT NULL ,
- [message_body] [image] NOT NULL ,
- [last_updated] [datetime] NOT NULL
-)
- ALTER TABLE [${table}] WITH NOCHECK ADD
cvs commit: jakarta-james/src/java/org/apache/james/transport/mailets Forward.java
pgoldstein2002/08/18 01:55:33
Modified:src/java/org/apache/james/transport/mailets Forward.java
Log:
Check for valid sender address before forwarding.
Thanks to Noel Bergman for the patch
Revision ChangesPath
1.4 +20 -2
jakarta-james/src/java/org/apache/james/transport/mailets/Forward.java
Index: Forward.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/transport/mailets/Forward.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- Forward.java 18 Jun 2002 21:39:52 - 1.3
+++ Forward.java 18 Aug 2002 08:55:33 - 1.4
@@ -17,7 +17,7 @@
import java.util.StringTokenizer;
/**
- * Replace incoming recipient with specified ones.
+ * Replaces incoming recipients with those specified.
*
* @author Federico Barbieri [EMAIL PROTECTED]
* @author Serge Knystautas [EMAIL PROTECTED]
@@ -35,7 +35,25 @@
}
public void service(Mail mail) throws MessagingException {
-getMailetContext().sendMail(mail.getSender(), newRecipients,
mail.getMessage());
+ if (mail.getSender() == null ||
getMailetContext().getMailServers(mail.getSender().getHost()).size() != 0) {
+ // If we do not do this check, and somone uses Forward in a
+ // processor initiated by SenderInFakeDomain, then a fake
+ // sender domain will cause an infinite loop (the forwarded
+ // e-mail still appears to come from a fake domain).
+ // Although this can be viewed as a configuration error, the
+ // consequences of such a mis-configuration are severe enough
+ // to warrant protecting against the infinite loop.
+ getMailetContext().sendMail(mail.getSender(), newRecipients,
mail.getMessage());
+ }
+ else {
+ StringBuffer logBuffer = new StringBuffer(256)
+ .append(Forward mailet cannot forward )
+ .append(mail)
+ .append(. Invalid sender domain for )
+ .append(mail.getSender())
+ .append(. Consider using the Redirect mailet.);
+ log(logBuffer.toString());
+ }
if(! (new Boolean(getInitParameter(passThrough))).booleanValue()) {
mail.setState(Mail.GHOST);
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: IMAP LIST command
Andrew C. Oliver wrote: (oops I sent this to the wrong newsgroup) Hi Jamesers(jamesies?) -- In my quest to get my mailserver up and running I've stumbled upon james nicethanks. However, it looks like its a few parsecs short of an imap server and I find that kind of thing kinda fun. Hi Andrew, IMAP development has been stopped for some time but has regained interest recently, thanks to several new developers. So keep your comments coming, and don't hesitate to submit code. -- !try; do() -- Vincent Keunen, Ir, http://vincent.keunen.net Manex, rue Wagner 93, BE-4100 Boncelles, Belgium Our site: http://www.manex.be -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
about javadocs (was: Re: FW: What do we need to release 2.1?)
Thanks Peter, for your message that makes things move forward. I'm adding some comments about the specific item of javadocs. First, I must say that I agree with 2 comments from Noel: Internal Documentation Absolutely necessary. But NOT to hold up the 2.1 release. We can continue to upgrade the web site with new documentation, and any serious developer should be working from the CVS and At least get the javadoc complete. javadocs are for developers. I view 2.1 as a RELEASE build for users. Yes, we need to work on the javadocs, but I would not wait for them before putting out a stable release build if we can do so. Peter M. Goldstein wrote: Internal Documentation I know some people tend to dismiss internal documentation, but I don't see how a project that is seeking to attract developers can function without it. As such I tend to include it in the exit criteria for a particular release. 1) All methods and instance variables should be documented. All classes should be documented. The documentation doesn't need to be extensive, but it should be present. It should include issues such as class/method contracts and threading restrictions where appropriate. 2) All public and protected classes, methods, and variables need to be documented using Javadoc style to ensure appropriate Javadoc 3) The Javadoc should build without warnings 4) All packages should have package documentation Peter, I'd like to modify a bit your suggestion. From my experience (15 years of OO software developement), doc should be reduced to the minimum (and I find XP discussions about documenting the code quite appropriate to modern developments). Some ideas: * code is the only thing that really lives; it changes often (writing docs is time consuming and is very difficult to keep in sync with the code; and out of sync doc is useless, and may even lead you to wrong assumptions...) * the code (at the class/method level) should be self explicit: if you need doc to explain code, think about rewriting code to make it more explicit; also, good developers read code almost as easily as the doc (if the code is good, of course) * doc is very useful at the package level: what does this package contain, where to look first (important classes and methods should be mentionned) * important classes/methods may need some doc * important here meaning part of an API, important for external developers or part of the basic building blocks of the system, that all developers should be comfortable with I really don't want to start a lengthy discussion on the pros and cons of documentation (see the forum related to that), but I believe that docs should not get in the way of developing fast (especially on a volunteer basis, with restrained resources). And I am convinced that it won't hurt the project's perennity... Just my 2 cents (and I hope I did not offense you, Peter). -- !try; do() -- Vincent Keunen, Ir, http://vincent.keunen.net Manex, rue Wagner 93, BE-4100 Boncelles, Belgium Our site: http://www.manex.be
Re: about javadocs (was: Re: FW: What do we need to release 2.1?)
Vincent Keunen wrote: Thanks Peter, for your message that makes things move forward. I'm adding some comments about the specific item of javadocs. First, I must say that I agree with 2 comments from Noel: Internal Documentation Absolutely necessary. But NOT to hold up the 2.1 release. We can continue to upgrade the web site with new documentation, and any serious developer should be working from the CVS I disagree. You wouldn't release Documentation with no code would you? Why would you release code with no documentation? If documentation isn't a condition for release, you'll never do it. So say what you mean Absolutely someone else...the mythical someone else..should document JAMES, but quality is not important to me so I'd rather get it out the door undocumented and hope the mythical someone else comes along javadocs are for developers. I view 2.1 as a RELEASE build for users. Yes, we need to work on the javadocs, but I would not wait for them before putting out a stable release build if we can do so. retranslate: Code quality is not important Peter M. Goldstein wrote: Internal Documentation I know some people tend to dismiss internal documentation, but I don't see how a project that is seeking to attract developers can function without it. As such I tend to include it in the exit criteria for a particular release. 1) All methods and instance variables should be documented. All classes should be documented. The documentation doesn't need to be extensive, but it should be present. It should include issues such as class/method contracts and threading restrictions where appropriate. 2) All public and protected classes, methods, and variables need to be documented using Javadoc style to ensure appropriate Javadoc 3) The Javadoc should build without warnings 4) All packages should have package documentation Peter, I'd like to modify a bit your suggestion. From my experience (15 years of OO software developement), doc should be reduced to the minimum (and I find XP discussions about documenting the code quite appropriate to modern developments). Some ideas: * code is the only thing that really lives; it changes often (writing docs is time consuming and is very difficult to keep in sync with the code; and out of sync doc is useless, and may even lead you to wrong assumptions...) * the code (at the class/method level) should be self explicit: if you need doc to explain code, think about rewriting code to make it more explicit; also, good developers read code almost as easily as the doc (if the code is good, of course) * doc is very useful at the package level: what does this package contain, where to look first (important classes and methods should be mentionned) * important classes/methods may need some doc * important here meaning part of an API, important for external developers or part of the basic building blocks of the system, that all developers should be comfortable with I really don't want to start a lengthy discussion on the pros and cons of documentation (see the forum related to that), but I believe that docs should not get in the way of developing fast (especially on a volunteer basis, with restrained resources). And I am convinced that it won't hurt the project's perennity... Just my 2 cents (and I hope I did not offense you, Peter). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: about javadocs (was: Re: FW: What do we need to release 2.1?)
Vincent, I'm not offended, although I disagree almost entirely with your points. :) Basically I feel that on distributed, volunteer projects extensive and appropriate documentation is even more important than on projects being done by a full-time, localized development team. And I feel that it is extremely important even in the latter case. While XP is an interesting methodology, James is in no way an XP project. We are using none of the XP techniques (pair programming, rapid rotation of developers to different parts of the code base, aggressive refactoring of unclear code etc.) that make internal documentation far less important. And as observation of the changelog indicates, leaving javadoc out vs. adding javadoc has not made the development any faster. I believe that one of the essential things an open source project must do is attract developers. You do that by making the projects interesting, and the code easy to understand. To me, that means internal documentation. That's what allows a new developer to come up to speed in a very short time and participate productively in the project. And on this point at least the Apache code standards seem to agree with me. :) I also suggested that the internal documentation be tied to a release because: i) That way it actually gets done ii) When the release announcement spurs a few developers to take a look at the code base, they'll find a well-documented, inviting code base. I'd be happy to continue this discussion offline, but I stand by my original wish list entry. --Peter -Original Message- From: Vincent Keunen [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 18, 2002 7:13 AM To: James Developers List Subject: about javadocs (was: Re: FW: What do we need to release 2.1?) Thanks Peter, for your message that makes things move forward. I'm adding some comments about the specific item of javadocs. First, I must say that I agree with 2 comments from Noel: Internal Documentation Absolutely necessary. But NOT to hold up the 2.1 release. We can continue to upgrade the web site with new documentation, and any serious developer should be working from the CVS and At least get the javadoc complete. javadocs are for developers. I view 2.1 as a RELEASE build for users. Yes, we need to work on the javadocs, but I would not wait for them before putting out a stable release build if we can do so. Peter M. Goldstein wrote: Internal Documentation I know some people tend to dismiss internal documentation, but I don't see how a project that is seeking to attract developers can function without it. As such I tend to include it in the exit criteria for a particular release. 1) All methods and instance variables should be documented. All classes should be documented. The documentation doesn't need to be extensive, but it should be present. It should include issues such as class/method contracts and threading restrictions where appropriate. 2) All public and protected classes, methods, and variables need to be documented using Javadoc style to ensure appropriate Javadoc 3) The Javadoc should build without warnings 4) All packages should have package documentation Peter, I'd like to modify a bit your suggestion. From my experience (15 years of OO software developement), doc should be reduced to the minimum (and I find XP discussions about documenting the code quite appropriate to modern developments). Some ideas: * code is the only thing that really lives; it changes often (writing docs is time consuming and is very difficult to keep in sync with the code; and out of sync doc is useless, and may even lead you to wrong assumptions...) * the code (at the class/method level) should be self explicit: if you need doc to explain code, think about rewriting code to make it more explicit; also, good developers read code almost as easily as the doc (if the code is good, of course) * doc is very useful at the package level: what does this package contain, where to look first (important classes and methods should be mentionned) * important classes/methods may need some doc * important here meaning part of an API, important for external developers or part of the basic building blocks of the system, that all developers should be comfortable with I really don't want to start a lengthy discussion on the pros and cons of documentation (see the forum related to that), but I believe that docs should not get in the way of developing fast (especially on a volunteer basis, with restrained resources). And I am convinced that it won't hurt the project's perennity... Just my 2 cents (and I hope I did not offense you, Peter). -- !try; do() -- Vincent Keunen, Ir, http://vincent.keunen.net Manex, rue Wagner 93, BE-4100 Boncelles, Belgium Our site: http://www.manex.be -- To unsubscribe,
RE: address-literal addressing not working
Danny et al, I'm leaning towards Noel's reading of this. How strong are your objections? I don't want to commit anything before we have a consensus. --Peter -Original Message- From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] Sent: Saturday, August 17, 2002 3:47 PM To: James Developers List Subject: Re: address-literal addressing not working Danny, I can't see why this needs to be fixed it may be that you don't actually want to handle mail delivered using IP addresses ... Section 4.1.3 of RFC 2821 (http://www.ietf.org/rfc/rfc2821.txt): Sometimes a host is not known to the domain name system and communication (and, in particular, communication to report and repair the error) is blocked. To bypass this barrier a special literal form of the address is allowed as an alternative to a domain name. I read that as saying that the special literal form IS allowed, not that it MAY BE allowed. For example, if I normally count on domain names and your DNS server goes out, I can use the address-literal form to reach you. I do understand your differing understanding, and see a bit of US-centric political humor in that we are saying that it depends upon what the definition of 'is' is. As for maintaining it by hand, not only don't I read it as optional, but for those of us dealing with virtual hosting, there can be quite a few IP addresses as well as domain names. I'd like the DNS to deal with that, not have to do it by hand. For example, within the next week or so, we're moving to a new ARIN block. When there is a DNS change, I'd like to make change in the DNS, not have to keep disjoint applications in synch. --- Noel -Original Message- From: Danny Angus [mailto:[EMAIL PROTECTED]] Sent: Saturday, August 17, 2002 18:12 To: James Developers List Subject: RE: DO NOT REPLY [Bug 11795] New: - address-literal addressing not working Oh, now I see what this is about, Yes you have to specify that James will handle mail for the address literals as well as domain names, then it works. I can't see why this needs to be fixed it may be that you don't actually want to handle mail delivered using IP addresses, only FQDN's, for any number of reasons. Specifying ip address literals to be handled in the servernames section seems reasonable to me. My fix would be to simply document this requirement, and point out the reasoning. What do you think? d. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 17 August 2002 21:41 To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 11795] New: - address-literal addressing not working DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11795. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11795 address-literal addressing not working Summary: address-literal addressing not working Product: James Version: unspecified Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: James Core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 2.1a1 doesn't appear to support user@address-literal addressing as required by the SMTP RFC. James.isServerLocal() does a simple String lookup in a serverName collection, so unless the IP addresses are in the collection, they won't be matched. There are some reports that this is a regression, since it worked with 2.0a3. That should be tested. There was also an Open Relay defect in 2.0a3 that might have masked this problem, depending upon the test. A patch for this defect has been submitted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:james-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:james-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:james-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:james-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:james-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-james build.bat
pgoldstein2002/08/18 10:42:45 Modified:.build.bat Log: Changing build.bat to a DOS style linefeed file. It's a Windows only file, and the build changes it to this linefeed style on first run. Revision ChangesPath 1.6 +18 -18jakarta-james/build.bat Index: build.bat === RCS file: /home/cvs/jakarta-james/build.bat,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- build.bat 13 Aug 2002 22:57:57 - 1.5 +++ build.bat 18 Aug 2002 17:42:45 - 1.6 @@ -1,18 +1,18 @@ -@echo off - -echo. -echo James Build System -echo --- - -set OLD_ANT_HOME=%ANT_HOME% -set ANT_HOME=tools - -set OLD_CLASSPATH=%CLASSPATH% -set CLASSPATH=phoenix-bin\lib\xercesImpl-2.0.2.jar;phoenix-bin\lib\xml-apis.jar;tools\lib\velocity-1.3-dev.jar;tools\lib\jdom-b7.jar - -%ANT_HOME%\bin\ant.bat -emacs %1 %2 %3 %4 %5 %6 %7 %8 -goto cleanup - -:cleanup -set ANT_HOME=%OLD_ANT_HOME% -set CLASSPATH=%OLD_CLASSPATH% +@echo off + +echo. +echo James Build System +echo --- + +set OLD_ANT_HOME=%ANT_HOME% +set ANT_HOME=tools + +set OLD_CLASSPATH=%CLASSPATH% +set CLASSPATH=phoenix-bin\lib\xercesImpl-2.0.2.jar;phoenix-bin\lib\xml-apis.jar;tools\lib\velocity-1.3-dev.jar;tools\lib\jdom-b7.jar + +%ANT_HOME%\bin\ant.bat -emacs %1 %2 %3 %4 %5 %6 %7 %8 +goto cleanup + +:cleanup +set ANT_HOME=%OLD_ANT_HOME% +set CLASSPATH=%OLD_CLASSPATH% -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: about javadocs (was: Re: FW: What do we need to release 2.1?)
Well said Peter. If your on Advogoto I'd love to upgrade you. -Andy PS... very offtopic Furthermore de-emphasizing documentation is one of my key beefs with XP. While I hate 300 page specs, I hate 0 page ones too. Peter M. Goldstein wrote: Vincent, I'm not offended, although I disagree almost entirely with your points. :) Basically I feel that on distributed, volunteer projects extensive and appropriate documentation is even more important than on projects being done by a full-time, localized development team. And I feel that it is extremely important even in the latter case. While XP is an interesting methodology, James is in no way an XP project. We are using none of the XP techniques (pair programming, rapid rotation of developers to different parts of the code base, aggressive refactoring of unclear code etc.) that make internal documentation far less important. And as observation of the changelog indicates, leaving javadoc out vs. adding javadoc has not made the development any faster. I believe that one of the essential things an open source project must do is attract developers. You do that by making the projects interesting, and the code easy to understand. To me, that means internal documentation. That's what allows a new developer to come up to speed in a very short time and participate productively in the project. And on this point at least the Apache code standards seem to agree with me. :) I also suggested that the internal documentation be tied to a release because: i) That way it actually gets done ii) When the release announcement spurs a few developers to take a look at the code base, they'll find a well-documented, inviting code base. I'd be happy to continue this discussion offline, but I stand by my original wish list entry. --Peter -Original Message- From: Vincent Keunen [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 18, 2002 7:13 AM To: James Developers List Subject: about javadocs (was: Re: FW: What do we need to release 2.1?) Thanks Peter, for your message that makes things move forward. I'm adding some comments about the specific item of javadocs. First, I must say that I agree with 2 comments from Noel: Internal Documentation Absolutely necessary. But NOT to hold up the 2.1 release. We can continue to upgrade the web site with new documentation, and any serious developer should be working from the CVS and At least get the javadoc complete. javadocs are for developers. I view 2.1 as a RELEASE build for users. Yes, we need to work on the javadocs, but I would not wait for them before putting out a stable release build if we can do so. Peter M. Goldstein wrote: Internal Documentation I know some people tend to dismiss internal documentation, but I don't see how a project that is seeking to attract developers can function without it. As such I tend to include it in the exit criteria for a particular release. 1) All methods and instance variables should be documented. All classes should be documented. The documentation doesn't need to be extensive, but it should be present. It should include issues such as class/method contracts and threading restrictions where appropriate. 2) All public and protected classes, methods, and variables need to be documented using Javadoc style to ensure appropriate Javadoc 3) The Javadoc should build without warnings 4) All packages should have package documentation Peter, I'd like to modify a bit your suggestion. From my experience (15 years of OO software developement), doc should be reduced to the minimum (and I find XP discussions about documenting the code quite appropriate to modern developments). Some ideas: * code is the only thing that really lives; it changes often (writing docs is time consuming and is very difficult to keep in sync with the code; and out of sync doc is useless, and may even lead you to wrong assumptions...) * the code (at the class/method level) should be self explicit: if you need doc to explain code, think about rewriting code to make it more explicit; also, good developers read code almost as easily as the doc (if the code is good, of course) * doc is very useful at the package level: what does this package contain, where to look first (important classes and methods should be mentionned) * important classes/methods may need some doc * important here meaning part of an API, important for external developers or part of the basic building blocks of the system, that all developers should be comfortable with I really don't want to start a lengthy discussion on the pros and cons of documentation (see the forum related to that), but I believe that docs should not get in the way of developing fast (especially on a volunteer basis, with restrained resources). And I am convinced that it won't
cvs commit: jakarta-james/src/java/org/apache/james/transport/mailets Redirect.java
pgoldstein2002/08/18 11:19:54
Modified:src/java/org/apache/james/transport/mailets Redirect.java
Log:
Removed redundant pass-through, added xml:space preserve to internal docs.
Reformatted some of the Javadoc comments for consistency.
Thanks to Noel Bergman
Revision ChangesPath
1.9 +60 -45
jakarta-james/src/java/org/apache/james/transport/mailets/Redirect.java
Index: Redirect.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/transport/mailets/Redirect.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- Redirect.java 7 Aug 2002 23:26:38 - 1.8
+++ Redirect.java 18 Aug 2002 18:19:54 - 1.9
@@ -166,17 +166,16 @@
*lt;inlinegt;unalteredlt;/inlinegt;BR
*lt;passThroughgt;FALSElt;/passThroughgt;BR
*lt;replytogt;postmasterlt;/replytogt;BR
-+*lt;prefix xml:space=preservegt;[test mailing] lt;/prefixgt;BR
-+*lt;!-- note the xml:space=preserve to preserve whitespace --gt;BR
+*lt;prefix xml:space=preservegt;[test mailing] lt;/prefixgt;BR
+*lt;!-- note the xml:space=preserve to preserve whitespace --gt;BR
*lt;staticgt;TRUElt;/staticgt;BR
-*lt;passThroughgt;FALSElt;/passThroughgt;BR
*lt;/mailetgt;BR
*/P
*Pand:/P
*P lt;mailet match=quot;Allquot; class=quot;Redirectquot;gt;BR
*lt;recipientsgt;x@localhostlt;/recipientsgt;BR
*lt;sendergt;postmasterlt;/sendergt;BR
-*lt;messagegt;Message marked as spam:BR
+*lt;message xml:space=preservegt;Message marked as spam:BR
*lt;/messagegt;BR
*lt;inlinegt;headslt;/inlinegt;BR
*lt;attachmentgt;messagelt;/attachmentgt;BR
@@ -192,12 +191,22 @@
*
*/
public class Redirect extends GenericMailet {
+
+// The values that indicate how to attach the original mail
+// to the redirected mail.
+
private static final int UNALTERED = 0;
+
private static final int HEADS = 1;
+
private static final int BODY= 2;
+
private static final int ALL = 3;
+
private static final int NONE= 4;
+
private static final int MESSAGE = 5;
+
private InternetAddress[] apparentlyTo;
private String messageText;
private Collection recipients;
@@ -226,15 +235,15 @@
}
/**
-* returns one of these values to indicate how to append the original message
-*ul
-*liUNALTERED : original message is the new message body/li
-*liBODY : original message body is appended to the new message/li
-*liHEADS : original message headers are appended to the new message/li
-*liALL : original is appended with all headers/li
-*liNONE : original is not appended/li
-*/ul
-*/
+ * returns one of these values to indicate how to append the original message
+ *ul
+ *liUNALTERED : original message is the new message body/li
+ *liBODY : original message body is appended to the new message/li
+ *liHEADS : original message headers are appended to the new message/li
+ *liALL : original is appended with all headers/li
+ *liNONE : original is not appended/li
+ */ul
+ */
public int getInLineType() {
if(getInitParameter(inline) == null) {
return BODY;
@@ -253,8 +262,8 @@
}
/**
-* must return either an empty string, or a message to which the redirect can be
attached/appended
-*/
+ * must return either an empty string, or a message to which the redirect can
be attached/appended
+ */
public String getMessage() {
if(getInitParameter(message) == null) {
return ;
@@ -264,8 +273,8 @@
}
/**
-* return true to allow thie original message to continue through the processor,
false to GHOST it
-*/
+ * return true to allow thie original message to continue through the
processor, false to GHOST it
+ */
public boolean getPassThrough() {
if(getInitParameter(passThrough) == null) {
return false;
@@ -275,8 +284,8 @@
}
/**
-* must return a Collection of recipient MailAddress'es
-*/
+ * must return a Collection of recipient MailAddresses
+ */
public Collection getRecipients() {
Collection newRecipients = new HashSet();
String addressList = (getInitParameter(recipients) ==
null)
@@ -294,8 +303,10 @@
}
/**
-* return the reply to address as a string
-*/
+ * Returns the reply to address as a string.
+ *
+ * @return the replyto address for the mail as a string
+ */
public MailAddress getReplyTo() {
String sr = getInitParameter(replyto);
if(sr != null) {
@@ -318,8 +329,8 @@
}
/**
RE: address-literal addressing not working
Medium :) Because to do it right you'd need to make sure you could match all the IP addresses a machine is accepting, and in both forms (with and without []) I don't think it is such simple matter to correctly identify all the addresses, whereas it is common practice to configure server daemons with lists of addresses to accept (see httpd for example). d. I'm leaning towards Noel's reading of this. How strong are your objections? I don't want to commit anything before we have a consensus. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-james build.bat
tricky call, the linefeed standard has more to do with the apache repository systems than the intended audience, but I guess there won't be many complaints. d. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 18 August 2002 18:43 To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-james build.bat pgoldstein2002/08/18 10:42:45 Modified:.build.bat Log: Changing build.bat to a DOS style linefeed file. It's a Windows only file, and the build changes it to this linefeed style on first run. Revision ChangesPath 1.6 +18 -18jakarta-james/build.bat Index: build.bat === RCS file: /home/cvs/jakarta-james/build.bat,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- build.bat 13 Aug 2002 22:57:57 - 1.5 +++ build.bat 18 Aug 2002 17:42:45 - 1.6 @@ -1,18 +1,18 @@ -@echo off - -echo. -echo James Build System -echo --- - -set OLD_ANT_HOME=%ANT_HOME% -set ANT_HOME=tools - -set OLD_CLASSPATH=%CLASSPATH% -set CLASSPATH=phoenix-bin\lib\xercesImpl-2.0.2.jar;phoenix-bin\lib\xml -apis.jar;tools\lib\velocity-1.3-dev.jar;tools\lib\jdom-b7.jar - -%ANT_HOME%\bin\ant.bat -emacs %1 %2 %3 %4 %5 %6 %7 %8 -goto cleanup - -:cleanup -set ANT_HOME=%OLD_ANT_HOME% -set CLASSPATH=%OLD_CLASSPATH% +@echo off + +echo. +echo James Build System +echo --- + +set OLD_ANT_HOME=%ANT_HOME% +set ANT_HOME=tools + +set OLD_CLASSPATH=%CLASSPATH% +set CLASSPATH=phoenix-bin\lib\xercesImpl-2.0.2.jar;phoenix-bin\lib\xml -apis.jar;tools\lib\velocity-1.3-dev.jar;tools\lib\jdom-b7.jar + +%ANT_HOME%\bin\ant.bat -emacs %1 %2 %3 %4 %5 %6 %7 %8 +goto cleanup + +:cleanup +set ANT_HOME=%OLD_ANT_HOME% +set CLASSPATH=%OLD_CLASSPATH% -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: address-literal addressing not working
Danny, Medium :) Because to do it right you'd need to make sure you could match all the IP addresses a machine is accepting, and in both forms (with and without []) I don't think it is such simple matter to correctly identify all the addresses, whereas it is common practice to configure server daemons with lists of addresses to accept (see httpd for example). I concur with you about the difficulty of matching all the IP addresses. That should be much easier once we migrate to Java 1.4 (using the NetworkAddress class), but for now it's definitely a problem for complex IP setups. However for simple IP setups I think this change would make life substantially easier. I'm not sure why we'd have to support both forms. From my reading of the RFC, only the bracketed form is strictly correct for IP addresses. How about we make it an optional behavior with a config param? --Peter -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-james build.xml
pgoldstein2002/08/18 12:17:27
Modified:.build.xml
Log:
Removed tabs from build.xml
Revision ChangesPath
1.103 +21 -21jakarta-james/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-james/build.xml,v
retrieving revision 1.102
retrieving revision 1.103
diff -u -r1.102 -r1.103
--- build.xml 15 Aug 2002 07:07:21 - 1.102
+++ build.xml 18 Aug 2002 19:17:27 - 1.103
@@ -177,7 +177,7 @@
/target
!--
===
-jdbc3
+ jdbc3
===
--
target name=prepare-jdbc3 depends=prepare if=jdbc3.present
@@ -229,12 +229,12 @@
param name=-version/
param name=-breakiterator/
param name=-use/
- param name=-link
value=http://java.sun.com/j2se/1.4/docs/api/
- param name=-link
value=http://java.sun.com/j2ee/sdk_1.3/techdocs/api/
- param name=-link
value=http://jakarta.apache.org/avalon/api/
- param name=-link
value=http://jakarta.apache.org/avalon/phoenix/api/
- param name=-link
value=http://jakarta.apache.org/avalon/cornerstone/api/
- param name=-link
value=http://jakarta.apache.org/avalon/logkit/api/
+param name=-link value=http://java.sun.com/j2se/1.4/docs/api/
+param name=-link
value=http://java.sun.com/j2ee/sdk_1.3/techdocs/api/
+param name=-link value=http://jakarta.apache.org/avalon/api/
+param name=-link
value=http://jakarta.apache.org/avalon/phoenix/api/
+param name=-link
value=http://jakarta.apache.org/avalon/cornerstone/api/
+param name=-link
value=http://jakarta.apache.org/avalon/logkit/api/
param name=-doctitle value=${Name} ${version}/
param name=-windowtitle value=${Name} API/
param name=-bottom value=quot;Copyright #169; 2001 Apache
Jakarta Project. All Rights Reserved.quot;/
@@ -248,12 +248,12 @@
param name=-version/
param name=-breakiterator/
param name=-use/
- param name=-link
value=http://java.sun.com/j2se/1.4/docs/api/
- param name=-link
value=http://java.sun.com/j2ee/sdk_1.3/techdocs/api/
- param name=-link
value=http://jakarta.apache.org/avalon/api/
- param name=-link
value=http://jakarta.apache.org/avalon/phoenix/api/
- param name=-link
value=http://jakarta.apache.org/avalon/cornerstone/api/
- param name=-link
value=http://jakarta.apache.org/avalon/logkit/api/
+param name=-link value=http://java.sun.com/j2se/1.4/docs/api/
+param name=-link
value=http://java.sun.com/j2ee/sdk_1.3/techdocs/api/
+param name=-link value=http://jakarta.apache.org/avalon/api/
+param name=-link
value=http://jakarta.apache.org/avalon/phoenix/api/
+param name=-link
value=http://jakarta.apache.org/avalon/cornerstone/api/
+param name=-link
value=http://jakarta.apache.org/avalon/logkit/api/
param name=-doctitle value=Apache Jakarta Mailet API/
param name=-windowtitle value=Apache Jakarta Mailet API/
param name=-bottom value=quot;Copyright #169; 2002 Apache
Jakarta Project. All Rights Reserved.quot;/
@@ -266,15 +266,15 @@
===
--
target name=xdocs depends=prepare,prepare-jdbc3
- style style=${docs.src}/stylesheets/site.xsl
+style style=${docs.src}/stylesheets/site.xsl
basedir=${docs.src}/
- destdir=${build.docs}/
- includes=**/*.xml
- /style
+destdir=${build.docs}/
+includes=**/*.xml
+/style
copy todir=${build.docs} filtering=no
- fileset dir=${docs.src}
+fileset dir=${docs.src}
include name=**/*.css/
- /fileset
+/fileset
/copy
copy todir=${build.docs}/images filtering=no
fileset
cvs commit: jakarta-james/src/java/org/apache/james/transport/mailets Redirect.java
pgoldstein2002/08/18 12:19:32 Modified:src/java/org/apache/james/transport/mailets Redirect.java Log: Missed a redundant passthrough on last checkin Revision ChangesPath 1.10 +0 -1 jakarta-james/src/java/org/apache/james/transport/mailets/Redirect.java Index: Redirect.java === RCS file: /home/cvs/jakarta-james/src/java/org/apache/james/transport/mailets/Redirect.java,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- Redirect.java 18 Aug 2002 18:19:54 - 1.9 +++ Redirect.java 18 Aug 2002 19:19:32 - 1.10 @@ -184,7 +184,6 @@ *lt;replytogt;postmasterlt;/replytogt;BR *lt;prefixgt;[spam notification]lt;/prefixgt;BR *lt;staticgt;TRUElt;/staticgt;BR -*lt;passThroughgt;FALSElt;/passThroughgt;BR *lt;/mailetgt;/P * * @author Danny Angus [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: address-literal addressing not working
How about we make it an optional behavior with a config param? Ok, a fine compromise, if we add (and document) a section serveraddresses equivalent to servernames with an autodetect element/parameter, as for servernames that should allow simple situations to be detected, complex situations to override it, and the chosen behaviour to be clearly seen in the configuration. I think it should be composed of addressxxx.xxx.xxx.xxx/address elements which are added in [] to the servernames collection. Yes? I did attempt to implement this compromise position. The patch I submitted does add such an autodetect parameter. It tells James to autodetect IP addresses for the mail hosts it supports. The parameter is addIPAddresses, although it can be renamed to whatever anyone wants. I consider a separate serveraddresses section to be unnecessary. It is perfectly permissible today to add elements of the form: servernamexxx.xxx.xxx.xxx/servername to the servernames element today. If truely desired, we could accept: servername[xxx.xxx.xxx.xxx]/servername and strip the brackets. The brackets must be stripped because the comparison is made against MailAddress.getHost(), and getHost() must return a valid host (which is why getHost() strips the brackets when it provides the host). --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11808] New: - 8bitmime capabilities missing
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11808. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11808 8bitmime capabilities missing Summary: 8bitmime capabilities missing Product: James Version: 2.0a3 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: SMTPServer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am using an IIS front end server which forwards email to the james backend server. The front server accepts 8bitmime messages but then cannot forward them to the james server, resulting in an error message being sent to the admininstrator(me). It should be a simple matter to add support for 8 bit and it may even be supported intrinsicly, but the james server does nont advertise it via the EHLO commannd. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: about javadocs (was: Re: FW: What do we need to release 2.1?)
Vincent Keunen wrote: First, I must say that I agree with 2 comments from Noel: Internal Documentation Absolutely necessary. But NOT to hold up the 2.1 release. We can continue to upgrade the web site with new documentation, and any serious developer should be working from the CVS You wouldn't release Documentation with no code would you? Why would you release code with no documentation? If documentation isn't a condition for release, you'll never do it. Everyone is agreeing that the documentation is necessary. But javadocs for developers is not a reason to hold end users hostage. The psychology is backwards. The documentation is getting done, but telling developers who can get the current code from the CVS that there won't be a user release until there is developer documentation is not going to incent them to do javadocs. If they don't care, they don't care, and they aren't the ones being held hostage by this false incentive. Fortunately, Peter has both time and interest, and he is doing a great job of updating the internal documentation. javadocs are for developers. I view 2.1 as a RELEASE build for users. Yes, we need to work on the javadocs, but I would not wait for them before putting out a stable release build if we can do so. retranslate: Code quality is not important Overly simplistic software cliche. 2.1 is superior in all ways to 2.0a3, including javadocs (albiet incomplete). Ironically, I just answered a question from someone who downloaded 2.0a3 over a week ago, and ran into the erroneous end user documentation. Releasing 2.1, which has CORRECT documentation would have saved that person 10 days of grief. Sure, it would have saved me the 30 seconds it took to reply, but it would have saved him 10 days. At the least, I do not see any reason not to replace 2.1a1 with a 2.1a2 Milestone Build based upon what we have now, and invite end users to help out with the user documentation. The CVS HEAD currently fills all the criteria necessary for a Milestone Build. --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: about javadocs (was: Re: FW: What do we need to release 2.1?)
Peter, I agree with almost all of your points. The only ones that I disagree with are: observation of the changelog indicates, leaving javadoc out vs. adding javadoc has not made the development any faster. I disagree, in a way that you'll like. I think that accurate javadocs facilitates development. I also suggested that the internal documentation be tied to a release because: i) That way it actually gets done Only because you want to get it done. Practically, it just doesn't work that way. Developers already have access to the current code, so if they don't care about the javadocs, holding a release up isn't an incentive for them to do it. And you don't need the incentive, you are doing it anyway. ii) When the release announcement spurs a few developers to take a look at the code base, they'll find a well-documented, inviting code base. I support that goal. As I said in another e-mail, let's put out a 2.1a2 Milestone Build to replace the ancient May 30 2.1a1 Milestone, and I'll feel much better for our end users. --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: about javadocs (was: Re: FW: What do we need to release 2.1?)
I totally disagree with just about everything Noel said except for the end. Development builds milestone builds or whatever, should not be delayed for quality concerns. It just can't be blessed as a release. As long as everyone understands that documentation is as important as code and that poorly documented code is just pure rat dung. IF you don't Javadoc, you are a crappy no good developer. Code complete, means docs too. Noel, you're wrong, once releases are the gold standard developers care. What good is a release to a user if he can't make hide nor hair of it? If I weren't a semi-decent Java developer I couldn't even set up JAMES. That puts JAMES a bit behind most other mail servers. If a developer doesn't care about that, then there isn't much he could care about. I've seen projects where the documentation was tied to the *real* release and the developers DID care. -Andy Noel J. Bergman wrote: Peter, I agree with almost all of your points. The only ones that I disagree with are: observation of the changelog indicates, leaving javadoc out vs. adding javadoc has not made the development any faster. I disagree, in a way that you'll like. I think that accurate javadocs facilitates development. I also suggested that the internal documentation be tied to a release because: i) That way it actually gets done Only because you want to get it done. Practically, it just doesn't work that way. Developers already have access to the current code, so if they don't care about the javadocs, holding a release up isn't an incentive for them to do it. And you don't need the incentive, you are doing it anyway. ii) When the release announcement spurs a few developers to take a look at the code base, they'll find a well-documented, inviting code base. I support that goal. As I said in another e-mail, let's put out a 2.1a2 Milestone Build to replace the ancient May 30 2.1a1 Milestone, and I'll feel much better for our end users. --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Jakarta James Nightly Build
To more knowledgeable heads than I, Noel and I have been looking at the nightly build process and are a little disturbed by the fact that: i) It is failing ii) It is failing without notifying james-dev See the nightly build report here: http://jakarta.apache.org/builds/gump/latest/jakarta-james.html After examining the definition file here, http://jakarta.apache.org/builds/gump/latest/module_jakarta-james.html it is very clear that this definition is pretty far out of date. Among other things, the file refers to a James.bar, which if I recall correctly was the predecessor to the current James.sar. So the file needs to be updated. The build is currently failing because of unnecessary dependencies - James builds off snapshots of the assorted Avalon subprojects and hence does not need those project builds to succeed. So the dependency entries need to be updated. I'm willing to volunteer to do the jakarta-james.xml file update. My big problem is that I don't know where the file is, and I don't think I have write-access to it. I'd like to get one of the Apache elders to give me a hand with this. As Peter Donald is listed in the nag tag, I'm cc'ing him on this email. Any help would be greatly appreciated. --Peter -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: about javadocs (was: Re: FW: What do we need to release 2.1?)
On Sun, 18 Aug 2002 20:40:35 -0400 Noel J. Bergman [EMAIL PROTECTED] wrote: Everyone is agreeing that the documentation is necessary. But javadocs for developers is not a reason to hold end users hostage. I love this sentence, But javadocs for developers is not a reason to hold end users hostage. I think documentation is VERY important, however, in my position just exernal documents (for users) not necessarily internal ones (javadocs). Sorry for the interruption. -- Tetsuya Kitahata [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: about javadocs (was: Re: FW: What do we need to release 2.1?)
No, I'm pragmatic and you just don't like it. This isn't about some ivory tower notion of what makes good code. This is about lots of James users who are stuck using buggy code and bad documention while we sit here using the good stuff and arguing over when to deliver it to them. What good is a release to a user if he can't make hide nor hair of it? If I weren't a semi-decent Java developer I couldn't even set up JAMES. I agree with you, but what does this have to do with javadocs, Andy? Talk about end user documentation and we'd be agreeing, because what good are javadocs to the average user? Its the whole package. Code complete. You're not pragmatic. Undocumented non-quality code is NOT pragmatic... in fact: http://www.pragmaticprogrammer.com/cgi-local/pragprog?FailureHowTo Fine to release a development build, but don't lie and call something a release, you do everyone a disservice. -Andy --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: about javadocs (was: Re: FW: What do we need to release 2.1?)
To be honest Tetsuya, it makes me scared to use it. Javadoc to me is so basic and takes so little time, to actually argue against it... To me this is the same as an argument to write variables a1, a2, a3... Its code quality. This is an active argument for poor code quality and I can't believe this is controversial! Tetsuya Kitahata wrote: On Sun, 18 Aug 2002 20:40:35 -0400 Noel J. Bergman [EMAIL PROTECTED] wrote: Everyone is agreeing that the documentation is necessary. But javadocs for developers is not a reason to hold end users hostage. I love this sentence, But javadocs for developers is not a reason to hold end users hostage. I think documentation is VERY important, however, in my position just exernal documents (for users) not necessarily internal ones (javadocs). Sorry for the interruption. -- Tetsuya Kitahata [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: about javadocs (was: Re: FW: What do we need to release 2.1?)
Andrew, If you feel there's something glaringly wrong that should be improved, patches are always greatly welcome. For my money, the only thing that should hold up a release is a volunteer saying they will fix something but won't have it ready until date X. Beyond that, changelogs go out with all the contributors and committers names on them... believe me, they're not looking to put out a bad product and just are trying to find a balance. Serge Knystautas Loki Technologies http://www.lokitech.com/ - Original Message - From: Andrew C. Oliver [EMAIL PROTECTED] Newsgroups: gmane.comp.jakarta.james.devel To: [EMAIL PROTECTED] Sent: Sunday, August 18, 2002 11:21 PM Subject: Re: about javadocs (was: Re: FW: What do we need to release 2.1?) To be honest Tetsuya, it makes me scared to use it. Javadoc to me is so basic and takes so little time, to actually argue against it... To me this is the same as an argument to write variables a1, a2, a3... Its code quality. This is an active argument for poor code quality and I can't believe this is controversial! Tetsuya Kitahata wrote: On Sun, 18 Aug 2002 20:40:35 -0400 Noel J. Bergman [EMAIL PROTECTED] wrote: Everyone is agreeing that the documentation is necessary. But javadocs for developers is not a reason to hold end users hostage. I love this sentence, But javadocs for developers is not a reason to hold end users hostage. I think documentation is VERY important, however, in my position just exernal documents (for users) not necessarily internal ones (javadocs). Sorry for the interruption. -- Tetsuya Kitahata [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: about javadocs (was: Re: FW: What do we need to release 2.1?)
Hi, Andy and all. On Sun, 18 Aug 2002 23:21:42 -0400 Andrew C. Oliver [EMAIL PROTECTED] wrote: To be honest Tetsuya, it makes me scared to use it. Javadoc to me is so basic and takes so little time, to actually argue against it... To me this is the same as an argument to write variables a1, a2, a3... Its code quality. This is an active argument for poor code quality and I can't believe this is controversial! I know your feelings, but it seems that it is the difference of where and when to put our milestones things. For example, our objectives at version 2.1 are not necessary complete javadocs, but at version 3.0, complete javadocs are necessary ... I think (for example) this is possible. -- I agreed with Noel's opinion, But javadocs for developers is not a reason to hold end users hostage, because this matter also applies to the translation. To catch up with frequently changed javadocs (to keep in sync) is very difficult and almost impossible things. The difference between this two Japanese Translation Groups(?) http://www.terra-intl.com/jakarta/ http://www.ingrid.org/jajakarta/ is apparent. I (the former one) clearly declared I will not translate Javadocs because external documents are very important for the PROMOTION of jakarta-projects but javadocs are different. That's why I can speed it up to translate 9 jakarta-projects (including JAMES) and the latter could not, it seems. That's why I love the Noel's sentence. Regards, -- Tetsuya Kitahata [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
First pass Token Counter mailet for ANTI SPAM mailet
Hi, This is my first attempt at developing a mailet...so if I've made a mistake about how best to implement this...or if I've just done something dumb in my code (cos I'm no Java guru either) please let me know. I'm following through with a posting I saw on /. regarding using word occurance statistics to be able to filter out SPAM from legit messages. Here's the original article: http://www.paulgraham.com/spam.html I saw this as a two part development. Part 1: Routines for building good/bad word-token statistics. Part 2: Using the statistics to route or flag new messages as SPAM or not. Attached is my first pass at the code for Part 1. As I decided to get familiar with JDBC with James at the same time, I've coded this to use JDBC as the repository...that may not be the best approach as it introduces a time lag at start up (as it loads the existing words/occurances) and at shutdown, as it persists the new statistics back into the database. Let me know what you guys think of my approach...etc. P.S. Hopefully, there's something I don't understand about how to develope under James. I'm using JBuilder 4 to compile my code, then I've got to update the James.bar (which JBuilder doesn't recognize as a jar repository) with the new class file, then restart James. I realize there's probably no easy way around restarting James, but it would be nice to skip updating the .bar all the time...is there a way to do this? Thanks. -Chris JDBCTokenCounter.java Description: JavaScript source database.sql Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
config.xml : RE: First pass Token Counter mailet for ANTI SPAM mailet
I forgot to add sample configuration necessary in config.xml: mailet match=[EMAIL PROTECTED] class=ToProcessor processor notSpam /processor /mailet processor name=notSpam mailet match=All class=JDBCTokenCounter repositoryPath db://maildb/filter_goodwords /repositoryPath statisticPath filter_statistics/goodmessages /statisticPath /mailet /processor -Chris -Original Message- From: Chris Means [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 18, 2002 11:11 PM To: [EMAIL PROTECTED] Subject: First pass Token Counter mailet for ANTI SPAM mailet Hi, This is my first attempt at developing a mailet...so if I've made a mistake about how best to implement this...or if I've just done something dumb in my code (cos I'm no Java guru either) please let me know. I'm following through with a posting I saw on /. regarding using word occurance statistics to be able to filter out SPAM from legit messages. Here's the original article: http://www.paulgraham.com/spam.html I saw this as a two part development. Part 1: Routines for building good/bad word-token statistics. Part 2: Using the statistics to route or flag new messages as SPAM or not. Attached is my first pass at the code for Part 1. As I decided to get familiar with JDBC with James at the same time, I've coded this to use JDBC as the repository...that may not be the best approach as it introduces a time lag at start up (as it loads the existing words/occurances) and at shutdown, as it persists the new statistics back into the database. Let me know what you guys think of my approach...etc. P.S. Hopefully, there's something I don't understand about how to develope under James. I'm using JBuilder 4 to compile my code, then I've got to update the James.bar (which JBuilder doesn't recognize as a jar repository) with the new class file, then restart James. I realize there's probably no easy way around restarting James, but it would be nice to skip updating the .bar all the time...is there a way to do this? Thanks. -Chris -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta James Nightly Build
Peter M. Goldstein wrote: To more knowledgeable heads than I, Noel and I have been looking at the nightly build process and are a little disturbed by the fact that: i) It is failing ii) It is failing without notifying james-dev This explains a lot. With no notification of failures, the Avalon Community have been moving along in ignorant bliss (relative to the James Commnity). Over the last few days that has been discussion concerning inconsitencies in Cornerstone jar brough about by some recent testing I've been doing of James using the Avalon CVS builds of Cornerstone. With gump working we would have spotted the issue months ago. Getting this back in place would be really good becuse you can validate that the Avalon Community are not braking anything as a result of maintainance and service development. See the nightly build report here: http://jakarta.apache.org/builds/gump/latest/jakarta-james.html After examining the definition file here, http://jakarta.apache.org/builds/gump/latest/module_jakarta-james.html it is very clear that this definition is pretty far out of date. Among other things, the file refers to a James.bar, which if I recall correctly was the predecessor to the current James.sar. So the file needs to be updated. Its also out-of-date relative some restructuring that took place of the Excalibur project. The build is currently failing because of unnecessary dependencies - James builds off snapshots of the assorted Avalon subprojects and hence does not need those project builds to succeed. So the dependency entries need to be updated. I'm willing to volunteer to do the jakarta-james.xml file update. My big problem is that I don't know where the file is, and I don't think I have write-access to it. I'd like to get one of the Apache elders to give me a hand with this. As Peter Donald is listed in the nag tag, I'm cc'ing him on this email. Any help would be greatly appreciated. Pete the right person to talk to - he knows this stuff inside out. Cheers, Steve. -- Stephen J. McConnell OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: NNTP auth issues
Noel J. Bergman wrote: Shouldn't be any different. Did you make any progress on this? You might want to ask Paul Hammant to take a look at it. For example, I don't know what the relationship is between the .xinfo files and things like the assembly file, but the .xinfo for the nntp server doesn't have an entry for the UsersStore, which is present in the .xinfo for other services. --- Noel -Original Message- From: Jason Webb [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 15, 2002 6:30 To: 'James Developers List' Subject: NNTP auth issues I'm trying to link our database into the NNTP auth mechanism as we provide an MLM that has a lot of NNTP style features. However, when I ask for a DataSource from the ComponentManager, I get an exception thrown at me: org.apache.avalon.framework.component.ComponentException: Unable to provide implementation for org.apache.avalon.cornerstone.services.datasource.DataSourceSelector at org.apache.avalon.framework.component.DefaultComponentManager.lookup DefaultComponentManager.java:70) at org.apache.james.nntpserver.AuthServiceImpl.isAuthenticated(AuthServiceI mpl.java:84) at org.apache.james.nntpserver.AuthServiceImpl.isAuthorized(AuthServiceImpl .java:53) Etc Could you post the Etc. It as just getting interesting ;-) Steve. It all works fine in the mailet we use for our MLM. Is NNTP special with regards to DataSources? Help! -- Jason -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Stephen J. McConnell OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: First pass Token Counter mailet for ANTI SPAM mailet
Chris Means wrote: Hi, This is my first attempt at developing a mailet...so if I've made a mistake about how best to implement this...or if I've just done something dumb in my code (cos I'm no Java guru either) please let me know. I'm following through with a posting I saw on /. regarding using word occurance statistics to be able to filter out SPAM from legit messages. Here's the original article: http://www.paulgraham.com/spam.html I saw this as a two part development. Part 1: Routines for building good/bad word-token statistics. Part 2: Using the statistics to route or flag new messages as SPAM or not. Attached is my first pass at the code for Part 1. As I decided to get familiar with JDBC with James at the same time, I've coded this to use JDBC as the repository...that may not be the best approach as it introduces a time lag at start up (as it loads the existing words/occurances) and at shutdown, as it persists the new statistics back into the database. Let me know what you guys think of my approach...etc. P.S. Hopefully, there's something I don't understand about how to develope under James. I'm using JBuilder 4 to compile my code, then I've got to update the James.bar (which JBuilder doesn't recognize as a jar repository) with the new class file, then restart James. I realize there's probably no easy way around restarting James, but it would be nice to skip updating the .bar all the time...is there a way to do this? You can safely rename a .bar files to x.jar. The .bar file was an old format supported by Phoenix - it basically represebnted a Block packaged as a jar file. Phoneix today does not do anytihg special with respect to .bar files. Cheers, Steve. -- Stephen J. McConnell OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jakarta James Nightly Build
This explains a lot. With no notification of failures, the Avalon Community have been moving along in ignorant bliss (relative to the James Commnity). There are Avalon developers here on this mailing list aware of what is going on. Some months ago, Paul Hammant kindly offered to keep James going well with Phoenix, and to be responsible for changing the James infrastructure to match changes in Phoenix; he was made a James committer for this purpose. James has its own snapshot of Phoenix, allowing James and Phoenix to evolve at their own pace. Apparently, there was a decision made half a year ago to eliminate the Component interface in favor of A-Better-Way. Because of some ... shall we say anemia ... in the Mailet v1 API, there are Mailets that must get at non-Mailet API functionality. They do that by requesting the ComponentManager via MailetContext.getAttribute(), and going on from there. It is not a problem to migrate the James code, but Paul has expressed concern about third-party mailets (outside of the scope of the CVS). My proposal is that Paul remove dependency upon the Component interface within Jame's code, and support foreign matchers/mailets as follows. The only documented way for a matcher/mailet to get the component manager is via a specific mechanism, and the set of components is limited. We can provide our own Component code that lies (and wraps) as necessary, until we can drop that code entirely. James' stock matchers/mailets would show how to make the transition. Personally, I have no problem with Phoenix continuing to evolve, given that they've accepted responsibility for converting James along. Again, personally, I would not want James to build against the Phoenix nightly builds. I'd prefer that it build against the snapshot that is part of James. --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta James Nightly Build
Stephen, To more knowledgeable heads than I, Noel and I have been looking at the nightly build process and are a little disturbed by the fact that: i) It is failing ii) It is failing without notifying james-dev This explains a lot. With no notification of failures, the Avalon Community have been moving along in ignorant bliss (relative to the James Commnity). Over the last few days that has been discussion concerning inconsitencies in Cornerstone jar brough about by some recent testing I've been doing of James using the Avalon CVS builds of Cornerstone. With gump working we would have spotted the issue months ago. Getting this back in place would be really good becuse you can validate that the Avalon Community are not braking anything as a result of maintainance and service development. Err not true dude. The problem exists because casting (I think) which neither gump nor a guy doing 'ant clean, ant dist' can test for. See the nightly build report here: http://jakarta.apache.org/builds/gump/latest/jakarta-james.html After examining the definition file here, http://jakarta.apache.org/builds/gump/latest/module_jakarta-james.html it is very clear that this definition is pretty far out of date. Among other things, the file refers to a James.bar, which if I recall correctly was the predecessor to the current James.sar. So the file needs to be updated. Pete the right person to talk to - he knows this stuff inside out. Indeed he is. Confuses the hell out me me. - Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: NNTP auth issues
Noel, Jason, Shouldn't be any different. Did you make any progress on this? You might want to ask Paul Hammant to take a look at it. For example, I don't know what the relationship is between the .xinfo files and things like the assembly file, but the .xinfo for the nntp server doesn't have an entry for the UsersStore, which is present in the .xinfo for other services. There is a strong relationship is Noel suspects. You will have to fork the root NNTP block to declare its need for and get DataSource from ComponentManager in its compose method. At least until we find a way of eliminating the dar I suggest insecure anti-pattern of Mailets getting free reign of the ComponentManager. - Paul --- Noel -Original Message- From: Jason Webb [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 15, 2002 6:30 To: 'James Developers List' Subject: NNTP auth issues I'm trying to link our database into the NNTP auth mechanism as we provide an MLM that has a lot of NNTP style features. However, when I ask for a DataSource from the ComponentManager, I get an exception thrown at me: org.apache.avalon.framework.component.ComponentException: Unable to provide implementation for org.apache.avalon.cornerstone.services.datasource.DataSourceSelector at org.apache.avalon.framework.component.DefaultComponentManager.lookup DefaultComponentManager.java:70) at org.apache.james.nntpserver.AuthServiceImpl.isAuthenticated(AuthServiceI mpl.java:84) at org.apache.james.nntpserver.AuthServiceImpl.isAuthorized(AuthServiceImpl .java:53) Etc It all works fine in the mailet we use for our MLM. Is NNTP special with regards to DataSources? Help! -- Jason -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
