[jira] Commented: (JAMES-343) James does not compile using Sun JDK 5.0
[ http://issues.apache.org/jira/browse/JAMES-343?page=comments#action_57500 ] Vincenzo Gianferrari Pini commented on JAMES-343: - In currrent SVN branch_2_1_fcs, a registration of the org.bouncycastle.jce.provider.BouncyCastleProvider provider is automatically done by org.apache.james.security.KeyHolder when the SMIMESign mailet is initialized. The BouncyCastleProvider provider is needed as such mailet needs some SMIME functionalities wich are not available with the SunJCE provider (at least using jre 1.3x and 1.4x). The registration is done this way for convenience, but it could also be done "statically" adding a "security.provider.n=org.bouncycastle.jce.provider.BouncyCastleProvider" line to the appropriate (JRE or JSDK) /lib/security/java.security file. But this is specific to SMIMESign mailet; SSL does not need BouncyCastle. Let's explain. There are two separate actions/things to deal with: a) The appropriate/needed security provider(s) must be "registered" either statically in the java.security file or dinamically through a java.security.Security.addProvider() call (see org.apache.james.security.KeyHolder.InitJCE.init() as an example, where the call is done in a static method - don't confuse between static and dynamic here). b) When the registration(s) is/are done, the related jars must be found somewhere. Now the situation is as follows: 1) SSL support needs a security provider. It can be SunJCE or some other (BouncyCastle works quite well). 2) SMIMESign needs BouncyCastle (because of some SMIME functionality). 3) Both JSDK and JRE 1.4x (and I suppose also 1.5) come by default with appropriate security.provider.n static registration entries in the /lib/security/java.security file for the Sun provider. 4) Both JSDK and JRE 1.4x (and I suppose also 1.5) have the appropriate Sun security provider jars in the /lib directory. 5) Avalon registers dynamically (see JAMES-348) the Sun providers; probably it was needeed for jre 1.3. 6) In the current SVN branch_2_1_fcs, hence in the next coming James release, org.apache.james.security.KeyHolder registers the BouncyCastle provider when the SMIMESign mailet is started. 7) Avalon *loads* (it's a fact) from /lib, not from /lib, so the jars needed mus be placed in /lib. I mean /lib, not /apps/james/SAR-INF/lib. 8) No one (as far as I know - am I wrong?) including ASF, is allowed to distribute java run-time code from Sun in its own installations, so no Sun security provider jars are by default in the /lib, and should be put there only manually. 9) In the current SVN branch_2_1_fcs, hence in the next coming James release, the BouncyCastle provider jars are put in /lib by the James install process, with the appropriate BC license file. The jars are choosen in order to have both jre 1.3x and 1.4x compatibility; 1.5 has never been tested. -- Now the options: A. If you are using the latest SVN branch_2_1_fcs release: A.1 If you want to use SMIMESign, just put the appropriate entry in config.xml. A.2 If you want to use SSL, put the appropriate entries in config.xml and: A.2.1 If you have activated SMIMESign, SSL will work using the BouncyCastle provider. This is my own setup. A.2.2 If you don't activate SMIMESign, either: A.2.3 Copy the appropriate Sun provider jars to /lib, or A.2.4 Do a dynamic registration of the BC provider somewhere, for example issuing a call to org.apache.james.security.KeyHolder.InitJCE.init() from org.apache.james.James.initialize(). B. If you are using James 2.2.0- release, and want to use SSL: B.1 Copy the appropriate Sun provider jars to /lib, or B.2 Copy some other provider jars to /lib, and do s static or dynamic registration. I think that all this applies also to jre 1.5, but it should be tested anyhow. Check the security.provider.n static registration entries in the /lib/security/java.security file: the names may have changed(?). This comment came out very monotonous, but hopefully is clear. > James does not compile using Sun JDK 5.0 > > > Key: JAMES-343 > URL: http://issues.apache.org/jira/browse/JAMES-343 > Project: James > Type: Bug > Versions: 2.2.1 > Environment: Sun JDK 5.0 > Ant 1.6.2 > Reporter: Jeff Keyser > Priority: Trivial > > Several of the source files use a variable called "enum" for Enumerators. > This is a new keyword in Java 1.5, and the Sun JDK 5.0 compiler fails when it > sees these variables. > Please add "source='1.4'" (or whichever language version is officially > supported) to the "javac" task in build.xml. > Changing the names of these variables would also work, but the "source" > attribute provides better forward compatability as the Java language evolves. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: htt
[jira] Assigned: (JAMES-361) DSNBounce often report the dsn Status 5.5.0 incorrectly
[ http://issues.apache.org/jira/browse/JAMES-361?page=history ] Vincenzo Gianferrari Pini reassigned JAMES-361: --- Assign To: Vincenzo Gianferrari Pini > DSNBounce often report the dsn Status 5.5.0 incorrectly > --- > > Key: JAMES-361 > URL: http://issues.apache.org/jira/browse/JAMES-361 > Project: James > Type: Bug > Components: Matchers/Mailets (bundled) > Versions: 2.2.0 > Reporter: Stefano Bagnara > Assignee: Vincenzo Gianferrari Pini > Priority: Minor > > DSNBounce should guess the DSN code from the SMTP/ESMTP code received during > the SMTP session. Other MTA does this. Converted to hames DSNStatus: > // Req mail action not taken: mailbox unavailable > case 450: return DSNStatus.getStatus(DSNStatus.TRANSIENT, > DSNStatus.MAILBOX_OTHER); > // Req action aborted: local error in processing > case 451: return DSNStatus.getStatus(DSNStatus.TRANSIENT, > DSNStatus.SYSTEM_OTHER); > // Req action not taken: insufficient sys storage > case 452: return DSNStatus.getStatus(DSNStatus.TRANSIENT, > DSNStatus.SYSTEM_FULL); > // Syntax error, command unrecognized > case 500: return DSNStatus.getStatus(DSNStatus.PERMANENT, > DSNStatus.DELIVERY_SYNTAX); > // Syntax error in parameters or arguments > case 501: return DSNStatus.getStatus(DSNStatus.PERMANENT, > DSNStatus.DELIVERY_INVALID_ARG); > // Command not implemented > case 502: return DSNStatus.getStatus(DSNStatus.PERMANENT, > DSNStatus.DELIVERY_INVALID_CMD); > // Bad sequence of commands > case 503: return DSNStatus.getStatus(DSNStatus.PERMANENT, > DSNStatus.DELIVERY_INVALID_CMD); > // Command parameter not implemented > case 504: return DSNStatus.getStatus(DSNStatus.PERMANENT, > DSNStatus.DELIVERY_INVALID_ARG); > // Req mail action not taken: mailbox unavailable > case 550: return DSNStatus.getStatus(DSNStatus.PERMANENT, > DSNStatus.MAILBOX_OTHER); > // User not local; please try <...> > case 551: return DSNStatus.getStatus(DSNStatus.PERMANENT, > DSNStatus.ADDRESS_MOVED); > // Req mail action aborted: exceeded storage alloc > case 552: return DSNStatus.getStatus(DSNStatus.PERMANENT, > DSNStatus.MAILBOX_FULL); > // Req action not taken: mailbox name not allowed > case 553: return DSNStatus.getStatus(DSNStatus.PERMANENT, > DSNStatus.ADDRESS_OTHER); > // Transaction failed > case 554: return DSNStatus.getStatus(DSNStatus.PERMANENT, > DSNStatus.UNDEFINED_STATUS); > I already patched my DSNBounce but I made also many other changes/fix to this > class and I don't know if someone (committer) is reading bug submissions. > Please contact me for an updated DSNBounce when you will be ready to apply > patches. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JAMES-365) DSNBounce has inconsistencies with other AbstractRedirect hierarchy mailets
DSNBounce has inconsistencies with other AbstractRedirect hierarchy mailets --- Key: JAMES-365 URL: http://issues.apache.org/jira/browse/JAMES-365 Project: James Type: Improvement Components: Matchers/Mailets (bundled) Versions: 2.2.0 Reporter: Vincenzo Gianferrari Pini Assigned to: Vincenzo Gianferrari Pini Priority: Minor Fix For: 2.2.1 There are inconsistencies between DSNBounce and other AbstractRedirect hierarchy mailets. For example, it accepts a "messageString" parameter and not "message" nor "notice" like the other mailets, and "inline" is missing. Moreover, the service(Mail) method could perhaps be refactored to better use the hierarchy. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (JAMES-362) DSNBounce/RemoteDelivery/LocalDelivery should support Success/Delay DSN notifies
[ http://issues.apache.org/jira/browse/JAMES-362?page=history ] Vincenzo Gianferrari Pini reassigned JAMES-362: --- Assign To: Vincenzo Gianferrari Pini > DSNBounce/RemoteDelivery/LocalDelivery should support Success/Delay DSN > notifies > > > Key: JAMES-362 > URL: http://issues.apache.org/jira/browse/JAMES-362 > Project: James > Type: Improvement > Components: Matchers/Mailets (bundled) > Versions: 2.2.0 > Reporter: Stefano Bagnara > Assignee: Vincenzo Gianferrari Pini > Priority: Minor > > I'm adding this feature to the DSNBounce. > It will send correct notifies when the header > "org.apache.james.smtp.dsn.notify" is set to the given status as per javamail > spec: > mail.smtp.dsn.notify String The NOTIFY option to the RCPT command. Either > NEVER, or some combination of SUCCESS, FAILURE, and DELAY (separated by > commas). > mail.smtp.dsn.ret String The RET option to the MAIL command. Either FULL > or HDRS. > If anyone is interested in sharing this code please contact me and we will > discuss on the better way to implement this. I already have a working > implementation involving changes to many mailets: I'm not sure this is the > better way to handle this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (JAMES-311) Nntp very picky with clients
[ http://issues.apache.org/jira/browse/JAMES-311?page=history ] Vincenzo Gianferrari Pini reassigned JAMES-311: --- Assign To: Vincenzo Gianferrari Pini > Nntp very picky with clients > > > Key: JAMES-311 > URL: http://issues.apache.org/jira/browse/JAMES-311 > Project: James > Type: Bug > Components: NNTPServer & Repository > Versions: 2.2.0 > Environment: Tested on Windows xp Pro and Netware 6.5SP@ with Java 1.4.2_04 > Reporter: Rodney Crossman > Assignee: Vincenzo Gianferrari Pini > > Cannot read messages posted by some NNTP clients. > For example, if a message is posted with Mozilla Firefox .72 or Groupwise > client 6.5 and someone tries to read them, the client just hands and times > out. Messages posted with Outlook express work perfectly fine. > This is only an issue if there is a message body. If the message consist of > only the subject, then it doesn't seem to cause any problems. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JAMES-311) Nntp very picky with clients
[ http://issues.apache.org/jira/browse/JAMES-311?page=history ] Vincenzo Gianferrari Pini resolved JAMES-311: - Resolution: Fixed Fix Version: 2.2.1 Daniel Perry's patch applied. > Nntp very picky with clients > > > Key: JAMES-311 > URL: http://issues.apache.org/jira/browse/JAMES-311 > Project: James > Type: Bug > Components: NNTPServer & Repository > Versions: 2.2.0 > Environment: Tested on Windows xp Pro and Netware 6.5SP@ with Java 1.4.2_04 > Reporter: Rodney Crossman > Assignee: Vincenzo Gianferrari Pini > Fix For: 2.2.1 > > Cannot read messages posted by some NNTP clients. > For example, if a message is posted with Mozilla Firefox .72 or Groupwise > client 6.5 and someone tries to read them, the client just hands and times > out. Messages posted with Outlook express work perfectly fine. > This is only an issue if there is a message body. If the message consist of > only the subject, then it doesn't seem to cause any problems. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JAMES-369) Always announce AUTH capability to clients
Always announce AUTH capability to clients -- Key: JAMES-369 URL: http://issues.apache.org/jira/browse/JAMES-369 Project: James Type: Improvement Versions: 2.2.0 Reporter: Vincenzo Gianferrari Pini Assigned to: Vincenzo Gianferrari Pini Priority: Minor Fix For: 2.2.1 It would be useful to have James always announce its ability to handle the AUTH commands, even when it is not required to authenticate, in order to have the sender optionally authenticate if able to do it. This way, if the sender MUA (or MTA) authenticates, the James server is able to SMIMESign the message because the sender user is known, independently of being or not in an authorized subnet and from becoming authorized to relay or not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JAMES-369) Always announce AUTH capability to clients
[ http://issues.apache.org/jira/browse/JAMES-369?page=history ] Vincenzo Gianferrari Pini resolved JAMES-369: - Resolution: Fixed Modified SMTPHandler. > Always announce AUTH capability to clients > -- > > Key: JAMES-369 > URL: http://issues.apache.org/jira/browse/JAMES-369 > Project: James > Type: Improvement > Versions: 2.2.0 > Reporter: Vincenzo Gianferrari Pini > Assignee: Vincenzo Gianferrari Pini > Priority: Minor > Fix For: 2.2.1 > > It would be useful to have James always announce its ability to handle the > AUTH commands, even when it is not required to authenticate, in order to have > the sender optionally authenticate if able to do it. > This way, if the sender MUA (or MTA) authenticates, the James server is able > to SMIMESign the message because the sender user is known, independently of > being or not in an authorized subnet and from becoming authorized to relay or > not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-327) Mailet overview not complete
[ http://issues.apache.org/jira/browse/JAMES-327?page=comments#action_63148 ] Vincenzo Gianferrari Pini commented on JAMES-327: - The documentation in branch_2_1_fcs/src/xdocs/provided_mailets_2_1.xml is *not* up-to-date (many more mailets and matchers are missing), so first of all it has to be updated before updating the version in trunk. > Mailet overview not complete > > > Key: JAMES-327 > URL: http://issues.apache.org/jira/browse/JAMES-327 > Project: James > Type: Bug > Components: Documentation > Versions: 2.2.1 > Environment: All, web site > Reporter: Hes Siemelink > Attachments: diff.txt > > The overview of mailets is not complete. For example, the FromRepository > mailet is missing. > See http://james.apache.org/provided_mailets_2_1.html and compare with the > mailets in the package org.apache.james.transport.mailets > Thanks, >Hes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JAMES-321) Comments on configuri
[ http://issues.apache.org/jira/browse/JAMES-321?page=all ] Vincenzo Gianferrari Pini resolved JAMES-321: - Assign To: Vincenzo Gianferrari Pini Resolution: Fixed Fix Version: 2.2.1 > Comments on configuri > - > > Key: JAMES-321 > URL: http://issues.apache.org/jira/browse/JAMES-321 > Project: James > Type: Improvement > Components: Documentation > Versions: 2.2.0 > Reporter: Hes Siemelink > Assignee: Vincenzo Gianferrari Pini > Priority: Minor > Fix For: 2.2.1 > > In the james-config.file in the section Connection Manager Block, there is a > comment about configuring the max-connections parameter. It suggests that > setting it to 0 means unlimited connections. > In practice however, it turns out that setting the value to 0 effectively > creates a maximum of 1 connection. > (Due to the use of the HardResourceLimiting thread pool by the > ServerConnection class, which defaults to a size of 1 if a size of 0 is > specified.) > I would suggest to remove the comment in question to prevent confusion. > > ... > > > > > > > > > > 30 > 30 > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-134) Large emails in the spool cause SpoolManager to throw OutOfMemoryError
[ http://issues.apache.org/jira/browse/JAMES-134?page=comments#action_63590 ] Vincenzo Gianferrari Pini commented on JAMES-134: - First of all, reasonable maximum message sizes for an SMTP server should be quite below the values we are talking about here: SMTP != FTP. IMHO talking about 1 GB message size (or even 100 MB) is out of reality (remember to add about 33% to the attachment size to get the real message size). Secondly, DON'T USE INCREMENTAL GARBAGE COLLECTION (-Xincgc) with James (at least with jre 1.4.2_07 under linux, and file), as the effect in a real system is to slowly increase the average used memory, with an increasing "sawtooth" pattern, that will get in few hours to an OutOfMemory error. And this happens with a maximum message size limit set to values around 40MB. Instead, without -Xincgc, the behaviour is just an increase up to a reasonable horizontal asymptote. This does not mean that there may not be a memory leak somewhere in James: I recall (not sure though) something said by Noel about that when using the file protocol. > Large emails in the spool cause SpoolManager to throw OutOfMemoryError > -- > > Key: JAMES-134 > URL: http://issues.apache.org/jira/browse/JAMES-134 > Project: James > Type: Bug > Components: SpoolManager & Processors > Versions: 2.2.0, 2.0a3, 2.1.3, 2.1 > Environment: Operating System: MacOS X > Platform: Macintosh > Reporter: Matt Bishop > Attachments: TestMemRec.java > > Steps to repro: > 1. Send yourself a very large email (16 megs works for me) > 2. check the SpoolManager log and see this over and over: > ERROR spoolmanager: Exception in JamesSpoolManager.run null > java.lang.OutOfMemoryError > What makes this problem particularly bad is that the spoolmanager doesn't > move on to other > messages but keeps pegging the CPU trying to process this email. To fix it, > I have to shut down > james, delete the email files out of spool and restart. > EXPECTED: email should spool to the user as expected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (JAMES-369) Always announce AUTH capability to clients
[ http://issues.apache.org/jira/browse/JAMES-369?page=all ] Vincenzo Gianferrari Pini reopened JAMES-369: - The new approach taken, to always announce the SMTP auth capability, *breaks the behaviour of some webmail MUAs*. A safer approach is to have an extra config.xml parameter added: . When false, the behaviour would be as always (depend on ); when true, would offer SMTP auth to every client, including the ones in the authorized subnets. A question though arises: would it make sense to have both false and true? If not, it would be better to just add a new possible value to : announce, that implies true. In the meantime, I will revert to the original behaviour to avoid problems. > Always announce AUTH capability to clients > -- > > Key: JAMES-369 > URL: http://issues.apache.org/jira/browse/JAMES-369 > Project: James > Type: Improvement > Versions: 2.2.0 > Reporter: Vincenzo Gianferrari Pini > Assignee: Vincenzo Gianferrari Pini > Priority: Minor > Fix For: 2.2.1 > > It would be useful to have James always announce its ability to handle the > AUTH commands, even when it is not required to authenticate, in order to have > the sender optionally authenticate if able to do it. > This way, if the sender MUA (or MTA) authenticates, the James server is able > to SMIMESign the message because the sender user is known, independently of > being or not in an authorized subnet and from becoming authorized to relay or > not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (JAMES-369) Always announce AUTH capability to clients
[ http://issues.apache.org/jira/browse/JAMES-369?page=all ] Vincenzo Gianferrari Pini closed JAMES-369: --- I'm satisfied :-) > Always announce AUTH capability to clients > -- > > Key: JAMES-369 > URL: http://issues.apache.org/jira/browse/JAMES-369 > Project: James > Type: Improvement > Versions: 2.2.0 > Reporter: Vincenzo Gianferrari Pini > Assignee: Vincenzo Gianferrari Pini > Priority: Minor > Fix For: 2.2.1 > Attachments: SMTPHandler.java.patch, SMTPServer.java.patch > > It would be useful to have James always announce its ability to handle the > AUTH commands, even when it is not required to authenticate, in order to have > the sender optionally authenticate if able to do it. > This way, if the sender MUA (or MTA) authenticates, the James server is able > to SMIMESign the message because the sender user is known, independently of > being or not in an authorized subnet and from becoming authorized to relay or > not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (JAMES-387) Exception in BayesianAnalysis
[ http://issues.apache.org/jira/browse/JAMES-387?page=all ] Vincenzo Gianferrari Pini reassigned JAMES-387: --- Assign To: Vincenzo Gianferrari Pini > Exception in BayesianAnalysis > - > > Key: JAMES-387 > URL: http://issues.apache.org/jira/browse/JAMES-387 > Project: James > Type: Bug > Components: Matchers/Mailets (bundled) > Versions: 3.0 > Environment: James from svn-trunk 2005-08-01. > MySQL 4.0 > Reporter: Stefano Bagnara > Assignee: Vincenzo Gianferrari Pini > Priority: Minor > > Got this exception for every incoming mail: > 02/08/05 00:39:25 INFO James.Mailet: BayesianAnalysis: Exception: > java.lang.Integer > java.lang.ClassCastException: java.lang.Integer > at > org.apache.james.util.BayesianAnalyzer.getTokenProbabilityStrengths(BayesianAnalyzer.java:591) > at > org.apache.james.util.BayesianAnalyzer.computeSpamProbability(BayesianAnalyzer.java:340) > at > org.apache.james.transport.mailets.BayesianAnalysis.service(BayesianAnalysis.java:289) > at > org.apache.james.transport.LinearProcessor.service(LinearProcessor.java:407) > at > org.apache.james.transport.JamesSpoolManager.process(JamesSpoolManager.java:460) > at > org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:369) > at java.lang.Thread.run(Unknown Source) > If I clean my spam/ham db the exceptions disappears but they start again when > the spam/ham db become large. > My bayesiananalysis_spam contains 20 rows. > The following are the spam tokens with higher "occurrences". > +---+-+ > | token | occurrences | > +---+-+ > | 3D| 82151 | > | a | 59953 | > | the | 45295 | > | FONT | 42771 | > | Content-Type | 39058 | > | to| 36626 | > | com | 32902 | > | http | 32886 | > | of| 32504 | > | font | 31803 | > | and | 31577 | > | Content-Transfer-Encoding | 31576 | > | p | 29746 | > | text | 29482 | > | in| 29418 | > | it| 28498 | > | br| 28037 | > | DIV | 27431 | -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-387) Exception in BayesianAnalysis
[ http://issues.apache.org/jira/browse/JAMES-387?page=comments#action_12322588 ] Vincenzo Gianferrari Pini commented on JAMES-387: - I gave a careful look to the code and couldn't find anything wrong. I have a spam table with more than 258000 rows and everything works fine for me. IMHO a possible explanation of Stefano's exceptions is the following: The ham/spam corpus hashmaps may take a lot of memory. Accordingly, I gave a lot of -Xmx memory to the JVM. I remember some time ago, in a java (non James) application, an unpredictable JVM behaviour (strange exceptions thrown) when the available heap was just about the needed heap. Decreasing a little bit the -Xmx size I was getting OutOfMemoryError, and increasing it everything was fine. Stefano, can you try with more memory? > Exception in BayesianAnalysis > - > > Key: JAMES-387 > URL: http://issues.apache.org/jira/browse/JAMES-387 > Project: James > Type: Bug > Components: Matchers/Mailets (bundled) > Versions: 3.0 > Environment: James from svn-trunk 2005-08-01. > MySQL 4.0 > Reporter: Stefano Bagnara > Assignee: Vincenzo Gianferrari Pini > Priority: Minor > > Got this exception for every incoming mail: > 02/08/05 00:39:25 INFO James.Mailet: BayesianAnalysis: Exception: > java.lang.Integer > java.lang.ClassCastException: java.lang.Integer > at > org.apache.james.util.BayesianAnalyzer.getTokenProbabilityStrengths(BayesianAnalyzer.java:591) > at > org.apache.james.util.BayesianAnalyzer.computeSpamProbability(BayesianAnalyzer.java:340) > at > org.apache.james.transport.mailets.BayesianAnalysis.service(BayesianAnalysis.java:289) > at > org.apache.james.transport.LinearProcessor.service(LinearProcessor.java:407) > at > org.apache.james.transport.JamesSpoolManager.process(JamesSpoolManager.java:460) > at > org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:369) > at java.lang.Thread.run(Unknown Source) > If I clean my spam/ham db the exceptions disappears but they start again when > the spam/ham db become large. > My bayesiananalysis_spam contains 20 rows. > The following are the spam tokens with higher "occurrences". > +---+-+ > | token | occurrences | > +---+-+ > | 3D| 82151 | > | a | 59953 | > | the | 45295 | > | FONT | 42771 | > | Content-Type | 39058 | > | to| 36626 | > | com | 32902 | > | http | 32886 | > | of| 32504 | > | font | 31803 | > | and | 31577 | > | Content-Transfer-Encoding | 31576 | > | p | 29746 | > | text | 29482 | > | in| 29418 | > | it| 28498 | > | br| 28037 | > | DIV | 27431 | -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-387) Exception in BayesianAnalysis
[ http://issues.apache.org/jira/browse/JAMES-387?page=comments#action_12358507 ] Vincenzo Gianferrari Pini commented on JAMES-387: - Bernd is right: buildCorpus() is in a synchronized block to avoid messing when new mails are fed (in a separate thread), but I forgot to handle synchronization problems between buildCorpus() and getTokenProbabilityStrengths(). I will refactor builCorpus() to avoid this dirty double use of corpus. Moreover corpus, hamTokenCounts and spamTokenCounts seem to be not cleared when loading/building an updated new corpus from the database. > Exception in BayesianAnalysis > - > > Key: JAMES-387 > URL: http://issues.apache.org/jira/browse/JAMES-387 > Project: James > Type: Bug > Components: Matchers/Mailets (bundled) > Versions: 3.0 > Environment: James from svn-trunk 2005-08-01. > MySQL 4.0 > Reporter: Stefano Bagnara > Assignee: Vincenzo Gianferrari Pini > Priority: Minor > > Got this exception for every incoming mail: > 02/08/05 00:39:25 INFO James.Mailet: BayesianAnalysis: Exception: > java.lang.Integer > java.lang.ClassCastException: java.lang.Integer > at > org.apache.james.util.BayesianAnalyzer.getTokenProbabilityStrengths(BayesianAnalyzer.java:591) > at > org.apache.james.util.BayesianAnalyzer.computeSpamProbability(BayesianAnalyzer.java:340) > at > org.apache.james.transport.mailets.BayesianAnalysis.service(BayesianAnalysis.java:289) > at > org.apache.james.transport.LinearProcessor.service(LinearProcessor.java:407) > at > org.apache.james.transport.JamesSpoolManager.process(JamesSpoolManager.java:460) > at > org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:369) > at java.lang.Thread.run(Unknown Source) > If I clean my spam/ham db the exceptions disappears but they start again when > the spam/ham db become large. > My bayesiananalysis_spam contains 20 rows. > The following are the spam tokens with higher "occurrences". > +---+-+ > | token | occurrences | > +---+-+ > | 3D| 82151 | > | a | 59953 | > | the | 45295 | > | FONT | 42771 | > | Content-Type | 39058 | > | to| 36626 | > | com | 32902 | > | http | 32886 | > | of| 32504 | > | font | 31803 | > | and | 31577 | > | Content-Transfer-Encoding | 31576 | > | p | 29746 | > | text | 29482 | > | in| 29418 | > | it| 28498 | > | br| 28037 | > | DIV | 27431 | -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JAMES-387) Exception in BayesianAnalysis
[ http://issues.apache.org/jira/browse/JAMES-387?page=all ] Vincenzo Gianferrari Pini resolved JAMES-387: - Fix Version: 2.3.0 Resolution: Fixed The corpus reload activity was possibly conflicting with any ongoing analysis of messages, and the corpus could screw up. Now such reload activity is done on a new hashmap, that at the end of the reload becomes the actual corpus. In the meantime any analysis is done on the old corpus and no conflict occurs. The old corpus will eventually be garbage collected. > Exception in BayesianAnalysis > - > > Key: JAMES-387 > URL: http://issues.apache.org/jira/browse/JAMES-387 > Project: James > Type: Bug > Components: Matchers/Mailets (bundled) > Versions: 3.0 > Environment: James from svn-trunk 2005-08-01. > MySQL 4.0 > Reporter: Stefano Bagnara > Assignee: Vincenzo Gianferrari Pini > Priority: Minor > Fix For: 2.3.0 > > Got this exception for every incoming mail: > 02/08/05 00:39:25 INFO James.Mailet: BayesianAnalysis: Exception: > java.lang.Integer > java.lang.ClassCastException: java.lang.Integer > at > org.apache.james.util.BayesianAnalyzer.getTokenProbabilityStrengths(BayesianAnalyzer.java:591) > at > org.apache.james.util.BayesianAnalyzer.computeSpamProbability(BayesianAnalyzer.java:340) > at > org.apache.james.transport.mailets.BayesianAnalysis.service(BayesianAnalysis.java:289) > at > org.apache.james.transport.LinearProcessor.service(LinearProcessor.java:407) > at > org.apache.james.transport.JamesSpoolManager.process(JamesSpoolManager.java:460) > at > org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:369) > at java.lang.Thread.run(Unknown Source) > If I clean my spam/ham db the exceptions disappears but they start again when > the spam/ham db become large. > My bayesiananalysis_spam contains 20 rows. > The following are the spam tokens with higher "occurrences". > +---+-+ > | token | occurrences | > +---+-+ > | 3D| 82151 | > | a | 59953 | > | the | 45295 | > | FONT | 42771 | > | Content-Type | 39058 | > | to| 36626 | > | com | 32902 | > | http | 32886 | > | of| 32504 | > | font | 31803 | > | and | 31577 | > | Content-Transfer-Encoding | 31576 | > | p | 29746 | > | text | 29482 | > | in| 29418 | > | it| 28498 | > | br| 28037 | > | DIV | 27431 | -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-310) Redirect mailet overwrtting To: in header
[ http://issues.apache.org/jira/browse/JAMES-310?page=comments#action_12362315 ] Vincenzo Gianferrari Pini commented on JAMES-310: - I still believe that the right behaviour is the current one. To get the behaviour expected by the reporter both the following entries could be used: [EMAIL PROTECTED] unaltered unaltered even better: [EMAIL PROTECTED] Btw, can be false (default value). > Redirect mailet overwrtting To: in header > - > > Key: JAMES-310 > URL: http://issues.apache.org/jira/browse/JAMES-310 > Project: James > Type: Bug > Components: Matchers/Mailets (bundled) > Versions: 2.2.0 > Environment: Win XP, java 1.4.1_05 > Reporter: John Hornsby > Assignee: Vincenzo Gianferrari Pini > > As reported in the users mailing list. > Mail sent to: > To: Fred > CC: Bob > with Bob mail redirected to Bob2 in the config file, causes the mail to end > up looking like this: > To: Bob2 > CC: Bob > Hence it appears that the Redirect mailet is overwriting the To: instead of > the CC: (in this case). > Same problem with Bob in the BCC field. > config structure: > > [EMAIL PROTECTED] > unaltered > false > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-511) Add quota support for mailboxes
[ http://issues.apache.org/jira/browse/JAMES-511?page=comments#action_12413389 ] Vincenzo Gianferrari Pini commented on JAMES-511: - What about the available AbstractQuotaMatcher, AbstractStorageQuota and RecipientIsOverFixedQuota matchers? > Add quota support for mailboxes > --- > > Key: JAMES-511 > URL: http://issues.apache.org/jira/browse/JAMES-511 > Project: James > Type: New Feature > Components: MailStore & MailRepository > Reporter: Norman Maurer > > We should add the support of quotas -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-522) Having the ClamAVScan mailet configured, but clamd unavailable when JAMES starts, keeps JAMES from starting.
[
http://issues.apache.org/jira/browse/JAMES-522?page=comments#action_12414751 ]
Vincenzo Gianferrari Pini commented on JAMES-522:
-
I would keep things as now, because this was the intended behaviour. If
n, with n > 0, the desired behaviour is to delay the
startup of James until clamd is up and running, *without allowing any message
to flow without an anti-virus check*. Such situation could arise with a server
startup, where clamd could take longer than james to start. If after some time
clamd has not yet started, James must fail and the administrator shall
intervene to fix clamd.
If I don't want such "safe" behaviour, I can set 0 as you
did.
BTW, I'm changing config.xml to have a commented invocation of ClamAVScan (plus
some other enhancements).
> Having the ClamAVScan mailet configured, but clamd unavailable when JAMES
> starts, keeps JAMES from starting.
>
>
> Key: JAMES-522
> URL: http://issues.apache.org/jira/browse/JAMES-522
> Project: James
> Type: Bug
> Components: Matchers/Mailets (bundled)
> Reporter: Noel J. Bergman
> Assignee: Norman Maurer
> Priority: Trivial
>
> If JAMES attempts to start, ClamAVScan is configured, and clamd is not
> running, ClamAVScan.init() will throw an exception, terminating JAMES
> entirely. This can be seen in ${james}/logs/phoenix.log where the maxPings
> error will appear, and the spoolmanager component will be shown as failing.
> I'm marking this as minor since there is a work around, biut actually, I
> consider it a more major error.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (JAMES-310) Redirect mailet overwrtting To: in header
[ http://issues.apache.org/jira/browse/JAMES-310?page=all ] Vincenzo Gianferrari Pini closed JAMES-310: --- Resolution: Fixed > Redirect mailet overwrtting To: in header > - > > Key: JAMES-310 > URL: http://issues.apache.org/jira/browse/JAMES-310 > Project: James > Type: Bug > Components: Matchers/Mailets (bundled) > Versions: 2.2.0 > Environment: Win XP, java 1.4.1_05 > Reporter: John Hornsby > Assignee: Vincenzo Gianferrari Pini > > As reported in the users mailing list. > Mail sent to: > To: Fred > CC: Bob > with Bob mail redirected to Bob2 in the config file, causes the mail to end > up looking like this: > To: Bob2 > CC: Bob > Hence it appears that the Redirect mailet is overwriting the To: instead of > the CC: (in this case). > Same problem with Bob in the BCC field. > config structure: > > [EMAIL PROTECTED] > unaltered > false > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JAMES-528) Add whitelist support
Add whitelist support - Key: JAMES-528 URL: http://issues.apache.org/jira/browse/JAMES-528 Project: James Type: New Feature Components: Matchers/Mailets (bundled) Versions: 2.3.0b1 Reporter: Vincenzo Gianferrari Pini Assigned to: Vincenzo Gianferrari Pini Priority: Minor Fix For: 2.3.0b1 Add matcher/mailets providing whitelist support, to reduce false positives in anti-spam detection. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JAMES-528) Add whitelist support
[ http://issues.apache.org/jira/browse/JAMES-528?page=all ] Vincenzo Gianferrari Pini resolved JAMES-528: - Resolution: Fixed Added the WhiteListManager mailet and the IsInWhiteList matcher. > Add whitelist support > - > > Key: JAMES-528 > URL: http://issues.apache.org/jira/browse/JAMES-528 > Project: James > Type: New Feature > Components: Matchers/Mailets (bundled) > Versions: 2.3.0b1 > Reporter: Vincenzo Gianferrari Pini > Assignee: Vincenzo Gianferrari Pini > Priority: Minor > Fix For: 2.3.0b1 > > Add matcher/mailets providing whitelist support, to reduce false positives in > anti-spam detection. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-528) Add whitelist support
[ http://issues.apache.org/jira/browse/JAMES-528?page=comments#action_12415823 ] Vincenzo Gianferrari Pini commented on JAMES-528: - The difference between the existing matchers like SenderIsLocal or SenderIsRegex and the new IsInWhiteList matcher consists in the fact that the latter is not "static" (list hardcoded in config.xml) but "dynamic" (list stored in a database), "personal" (per local sender) and optionally grows automatically. The mailet that manages the list in the database is WhiteListManager. The following (that can be found both in javadoc and in config.xml) should explain more: > Add whitelist support > - > > Key: JAMES-528 > URL: http://issues.apache.org/jira/browse/JAMES-528 > Project: James > Type: New Feature > Components: Matchers/Mailets (bundled) > Versions: 2.3.0b1 > Reporter: Vincenzo Gianferrari Pini > Assignee: Vincenzo Gianferrari Pini > Priority: Minor > Fix For: 2.3.0b1 > > Add matcher/mailets providing whitelist support, to reduce false positives in > anti-spam detection. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-552) Clamav code should be moved to a "generic" class to use it on mailet,matcher,messagehandler
[ http://issues.apache.org/jira/browse/JAMES-552?page=comments#action_12419232 ] Vincenzo Gianferrari Pini commented on JAMES-552: - More generally, we talked about setting up a common way (I would use an interface) to help refactor the applicable current matchers and mailets with a matcher-like behaviour, and any future applicable functionality, into such generic classes. The goal is to share code between mailets, matchers and fast fail. I will work on a proposal and submit it. The ClamAVScan mailet, together with the Bayesian mailet and other antispam stuff could be the first candidates for such refactoring. > Clamav code should be moved to a "generic" class to use it on > mailet,matcher,messagehandler > --- > > Key: JAMES-552 > URL: http://issues.apache.org/jira/browse/JAMES-552 > Project: James > Type: Improvement > Components: Mailet API > Reporter: Norman Maurer > Fix For: 3.0 > > We agreed on apacheCon that the clamav mailet code should be placed in a > Generic class to can be used for implement a mailet, matcher and message > handler -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (JAMES-552) Clamav code should be moved to a "generic" class to use it on mailet,matcher,messagehandler
[ http://issues.apache.org/jira/browse/JAMES-552?page=all ] Vincenzo Gianferrari Pini reassigned JAMES-552: --- Assign To: Vincenzo Gianferrari Pini > Clamav code should be moved to a "generic" class to use it on > mailet,matcher,messagehandler > --- > > Key: JAMES-552 > URL: http://issues.apache.org/jira/browse/JAMES-552 > Project: James > Type: Improvement > Components: Mailet API > Reporter: Norman Maurer > Assignee: Vincenzo Gianferrari Pini > Fix For: 3.0 > > We agreed on apacheCon that the clamav mailet code should be placed in a > Generic class to can be used for implement a mailet, matcher and message > handler -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (JAMES-554) Set the right svn property for excutable files
[ http://issues.apache.org/jira/browse/JAMES-554?page=all ] Vincenzo Gianferrari Pini reopened JAMES-554: - I think that such svn property is not related to being executable under linux/unix, but only to being a binary file and as such not viewable under Subversion. *At least this is what happens now after che property change*. So I think that we should revert to the previous state. > Set the right svn property for excutable files > -- > > Key: JAMES-554 > URL: http://issues.apache.org/jira/browse/JAMES-554 > Project: James > Type: Bug > Components: Build System > Reporter: Norman Maurer > Assignee: Norman Maurer > Priority: Minor > Fix For: 3.0, 2.3.0 > > Set the right properties for files which should be excutable in linux systems -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JAMES-554) Set the right svn property for excutable files
[ http://issues.apache.org/jira/browse/JAMES-554?page=all ] Vincenzo Gianferrari Pini resolved JAMES-554: - Resolution: Fixed Sorry, I was wrong :-) Let's resolve it back. > Set the right svn property for excutable files > -- > > Key: JAMES-554 > URL: http://issues.apache.org/jira/browse/JAMES-554 > Project: James > Type: Bug > Components: Build System > Reporter: Norman Maurer > Assignee: Norman Maurer > Priority: Minor > Fix For: 3.0, 2.3.0 > > Set the right properties for files which should be excutable in linux systems -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JAMES-561) User aliasing does not work
User aliasing does not work --- Key: JAMES-561 URL: http://issues.apache.org/jira/browse/JAMES-561 Project: James Type: Bug Components: Matchers/Mailets (bundled) Versions: 3.0, 2.3.0b2 Reporter: Vincenzo Gianferrari Pini Priority: Blocker If user A is an alias of user B ( or viceversa - remote manager help is misleading) messages sent to A have to go (and were going) to B's inbox. Now it ends in A's inbox, that should not even exist. The problem has been found by me using both "file" and "db" repositories under 2.3.0b2, but I expect it to occur also under 3.0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-561) User aliasing does not work
[ http://issues.apache.org/jira/browse/JAMES-561?page=comments#action_12420117 ] Vincenzo Gianferrari Pini commented on JAMES-561: - It works now for me. Thanks to all of the team for the work. I'll test 2.3.0b2 again in production on the weekend of July 22-23. > User aliasing does not work > --- > > Key: JAMES-561 > URL: http://issues.apache.org/jira/browse/JAMES-561 > Project: James > Type: Bug > Components: Matchers/Mailets (bundled) > Versions: 3.0, 2.3.0b2 > Reporter: Vincenzo Gianferrari Pini > Assignee: Norman Maurer > Priority: Blocker > Fix For: 3.0, 2.3.0b3 > > If user A is an alias of user B ( or viceversa - remote manager help is > misleading) messages sent to A have to go (and were going) to B's inbox. Now > it ends in A's inbox, that should not even exist. > The problem has been found by me using both "file" and "db" repositories > under 2.3.0b2, but I expect it to occur also under 3.0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-559) Message body get lost after call saveChanges() and move to other processor
[ http://issues.apache.org/jira/browse/JAMES-559?page=comments#action_12420116 ] Vincenzo Gianferrari Pini commented on JAMES-559: - It works now for me. Thanks to all of the team for the work. I'll test 2.3.0b2 again in production on the weekend of July 22-23. > Message body get lost after call saveChanges() and move to other processor > -- > > Key: JAMES-559 > URL: http://issues.apache.org/jira/browse/JAMES-559 > Project: James > Type: Bug > Versions: 3.0, 2.3.0b2 > Reporter: Norman Maurer > Assignee: Stefano Bagnara > Priority: Blocker > Fix For: 3.0, 2.3.0b3 > > After call saveChanges() in a mailet and move the mail to a other processor > with ToProcessor the whole messageBody getting lost. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JAMES-564) Postage compile error under jdk 1.4
Postage compile error under jdk 1.4
---
Key: JAMES-564
URL: http://issues.apache.org/jira/browse/JAMES-564
Project: James
Type: Bug
Reporter: Vincenzo Gianferrari Pini
Priority: Minor
Compiling Postage under jdk 1.4 I'm getting a "cannot resolve symbol" compile
error:
build:
[echo] Compiling James Postage
[javac] Compiling 29 source files to E:\JamesSVN\postage-trunk\build\classes
[javac]
E:\JamesSVN\postage-trunk\build\source\org\apache\james\postage\jmx\JVMResourceSampler.java:68:
cannot resolve symbol
[javac] symbol : constructor IllegalStateException
(java.lang.String,java.lang.Exception)
[javac] location: class java.lang.IllegalStateException
[javac] throw new IllegalStateException("could not create
JVMResourceSamplerWorker", e);
[javac] ^
[javac]
E:\JamesSVN\postage-trunk\build\source\org\apache\james\postage\jmx\JVMResourceSampler.java:76:
cannot resolve symbol
[javac] symbol : constructor IllegalStateException
(java.lang.String,java.lang.NoSuchMethodException)
[javac] location: class java.lang.IllegalStateException
[javac] throw new IllegalStateException("could not access
delegation methods", e);
[javac] ^
[javac] 2 errors
It happens because the
public IllegalStateException(String message, Throwable cause)
is available only in jdk 1.5
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JAMES-566) Fastfail DNSRBL blacklisted messages are rejected even if the sender user is successfully SMTP AUTHenticated
Fastfail DNSRBL blacklisted messages are rejected even if the sender user is successfully SMTP AUTHenticated Key: JAMES-566 URL: http://issues.apache.org/jira/browse/JAMES-566 Project: James Issue Type: Bug Components: SMTPServer Affects Versions: 2.3.0b2, 2.3.0b1, 2.3.0a3, 2.3.0a2, 2.3.0a1, 2.2.0, 2.3.0b3, 2.3.0, 2.4.0, 3.0 Reporter: Vincenzo Gianferrari Pini Assigned To: Vincenzo Gianferrari Pini Fix For: 2.3.0b3, 3.0 A fastfail DNSBRL blacklisted message is rejected even if the sender user is successfully SMTP AUTHenticated. Instead in such case the message should be accepted. This bug is particularly critical in the scenario in which a blacklist that lists dynamic IP ranges (like "dul.dnsbl.sorbs.net") is being used, and a legitimate and SMTP AUTHenticated mail client roaming user connects from a dynamic IP and tries to send a mail to the James server. He will be rejected in such case. BTW, just FYI, statistics on my production server show that using fastfail DNSBRL blacklists and the Bayesian mailet, about 20% of the spam gets rejected by the "dul.dnsbl.sorbs.net" list, 65% by the other James stock configuration lists, and almost all of the remaining 15% is detected (and flagged for inspection) by the Bayesian mailet. Without the "dul.dnsbl.sorbs.net" about 34% is detected and flagged by the Bayesian mailet but has to be manually inspected to avoid false positives, and 1% is undetected. So the dynamic IP criteria is very effective but, to be used, this bug has to be fixed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JAMES-566) Fastfail DNSRBL blacklisted messages are rejected even if the sender user is successfully SMTP AUTHenticated
[ http://issues.apache.org/jira/browse/JAMES-566?page=all ] Vincenzo Gianferrari Pini resolved JAMES-566. - Resolution: Fixed The problem was in a misleading long boolean expression in RcptCmdHandler, that already gave us a similar problem in the past (in SMTPHandler), when it was used for controlling the logic for outbound mail, a few lines of code down. The code for the latter logic was fixed, but not the blacklist logic. > Fastfail DNSRBL blacklisted messages are rejected even if the sender user is > successfully SMTP AUTHenticated > > > Key: JAMES-566 > URL: http://issues.apache.org/jira/browse/JAMES-566 > Project: James > Issue Type: Bug > Components: SMTPServer >Affects Versions: 2.3.0b2, 2.3.0b1, 2.3.0a3, 2.3.0a2, 2.3.0a1, 2.2.0, > 2.3.0b3, 2.3.0, 2.4.0, 3.0 >Reporter: Vincenzo Gianferrari Pini > Assigned To: Vincenzo Gianferrari Pini > Fix For: 2.3.0b3, 3.0 > > > A fastfail DNSBRL blacklisted message is rejected even if the sender user is > successfully SMTP AUTHenticated. > Instead in such case the message should be accepted. > This bug is particularly critical in the scenario in which a blacklist that > lists dynamic IP ranges (like "dul.dnsbl.sorbs.net") is being used, and a > legitimate and SMTP AUTHenticated mail client roaming user connects from a > dynamic IP and tries to send a mail to the James server. He will be rejected > in such case. > BTW, just FYI, statistics on my production server show that using fastfail > DNSBRL blacklists and the Bayesian mailet, about 20% of the spam gets > rejected by the "dul.dnsbl.sorbs.net" list, 65% by the other James stock > configuration lists, and almost all of the remaining 15% is detected (and > flagged for inspection) by the Bayesian mailet. Without the > "dul.dnsbl.sorbs.net" about 34% is detected and flagged by the Bayesian > mailet but has to be manually inspected to avoid false positives, and 1% is > undetected. So the dynamic IP criteria is very effective but, to be used, > this bug has to be fixed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JAMES-574) Annoying logging of whitelist/blacklist nomatching as "unknown host exception thrown: listname" if INFO is enabled
Annoying logging of whitelist/blacklist nomatching as "unknown host exception thrown: listname" if INFO is enabled -- Key: JAMES-574 URL: http://issues.apache.org/jira/browse/JAMES-574 Project: James Issue Type: Bug Components: SMTPServer Affects Versions: 2.3.0b3, 2.3.0b2, 2.3.0b1, 2.3.0a3, 2.3.0a2, 2.3.0a1, 3.0 Reporter: Vincenzo Gianferrari Pini Assigned To: Vincenzo Gianferrari Pini Priority: Trivial Fix For: 2.3.0rc1, 3.0 When a checkDNSRBL is done, in case getLogger().isInfoEnabled() is true, both successfull and unsuccessfull matches are being logged. While successfull matches are useful to log as INFO, the much more frequent unsuccessfull matches are logged as "unknown host exception thrown: listname", heavily increasing the size of the log file. Such log message is useful only in DEBUG mode. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JAMES-574) Annoying logging of whitelist/blacklist nomatching as "unknown host exception thrown: listname" if INFO is enabled
[ http://issues.apache.org/jira/browse/JAMES-574?page=all ] Vincenzo Gianferrari Pini resolved JAMES-574. - Resolution: Fixed Changed the log message level to debug when match fails. > Annoying logging of whitelist/blacklist nomatching as "unknown host exception > thrown: listname" if INFO is enabled > -- > > Key: JAMES-574 > URL: http://issues.apache.org/jira/browse/JAMES-574 > Project: James > Issue Type: Bug > Components: SMTPServer >Affects Versions: 2.3.0b3, 2.3.0b2, 2.3.0b1, 2.3.0a3, 2.3.0a2, 2.3.0a1, 3.0 >Reporter: Vincenzo Gianferrari Pini > Assigned To: Vincenzo Gianferrari Pini >Priority: Trivial > Fix For: 2.3.0rc1, 3.0 > > > When a checkDNSRBL is done, in case getLogger().isInfoEnabled() is true, both > successfull and unsuccessfull matches are being logged. > While successfull matches are useful to log as INFO, the much more frequent > unsuccessfull matches are logged as "unknown host exception thrown: > listname", heavily increasing the size of the log file. Such log message is > useful only in DEBUG mode. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-576) Mails with Duplicate Mail Address in To / CC
[ http://issues.apache.org/jira/browse/JAMES-576?page=comments#action_12423074 ] Vincenzo Gianferrari Pini commented on JAMES-576: - I just tested with 2.3.0rc1 to both local and outbound, and only one copy is sent. > Mails with Duplicate Mail Address in To / CC > > > Key: JAMES-576 > URL: http://issues.apache.org/jira/browse/JAMES-576 > Project: James > Issue Type: Test > Components: SMTPServer >Affects Versions: 2.2.0 > Environment: Windows XP Professional > James 2.2.0 > JDK 1.4.2_08 >Reporter: Govind Kumar >Priority: Minor > Fix For: 2.2.0 > > > In case a mail's TO and / or CC address contains duplicates of same mail ids > like > To : [EMAIL PROTECTED],[EMAIL PROTECTED] > CC : [EMAIL PROTECTED] > , James sends multiple copies of the same mail to the same addresse. (In this > case [EMAIL PROTECTED] receives 3 copies) > Does this represent the correct behaviour as per the MIME specs (RFC 2045, > RFC 2046, and RFC 2047) ? OR should the smtp server send only 1 mail to > '[EMAIL PROTECTED]'. On referring other mail servers(with their mail > Clients), this is not the case ? If duplicate mails are not to be send, is > this the responsibility of a mail client or the mail server ? > Thanks & Kind Regards, > Govind Kumar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JAMES-580) NPE is issued when receiving a "read receipt" from MS Outlook, and is set to true
NPE is issued when receiving a "read receipt" from MS Outlook, and is set to true -- Key: JAMES-580 URL: http://issues.apache.org/jira/browse/JAMES-580 Project: James Issue Type: Bug Components: SMTPServer Affects Versions: 2.3.0rc1 Reporter: Vincenzo Gianferrari Pini A NPE is issued when receiving a "read receipt" from MS Outlook (not Outlook express nor Thunderbird), and is set to true and the sender IP address is not in : 27/07/06 17:17:00 ERROR smtpserver: Exception opening socket: null java.lang.NullPointerException at org.apache.james.smtpserver.MailCmdHandler.doMAIL(MailCmdHandler.java:210) at org.apache.james.smtpserver.MailCmdHandler.onCommand(MailCmdHandler.java:83) at org.apache.james.smtpserver.SMTPHandler.handleConnection(SMTPHandler.java:391) at org.apache.james.util.connection.ServerConnection$ClientConnectionRunner.run(ServerConnection.java:422) at org.apache.excalibur.thread.impl.ExecutableRunnable.execute(ExecutableRunnable.java:55) at org.apache.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:116) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-580) NPE is issued when receiving a "read receipt" from MS Outlook, and is set to true
[ http://issues.apache.org/jira/browse/JAMES-580?page=comments#action_12423864 ] Vincenzo Gianferrari Pini commented on JAMES-580: - I don't know if this error was also in 2.2. In such case IMO we should consider it a blocker :-( , because after an upgrade from 2.2.0 to 2.3.0 the systems having set to true would lose messages. > NPE is issued when receiving a "read receipt" from MS Outlook, and > is set to true > -- > > Key: JAMES-580 > URL: http://issues.apache.org/jira/browse/JAMES-580 > Project: James > Issue Type: Bug > Components: SMTPServer >Affects Versions: 2.3.0rc1 >Reporter: Vincenzo Gianferrari Pini > > A NPE is issued when receiving a "read receipt" from MS Outlook (not Outlook > express nor Thunderbird), and is set to true and > the sender IP address is not in : > 27/07/06 17:17:00 ERROR smtpserver: Exception opening socket: null > java.lang.NullPointerException > at > org.apache.james.smtpserver.MailCmdHandler.doMAIL(MailCmdHandler.java:210) > at > org.apache.james.smtpserver.MailCmdHandler.onCommand(MailCmdHandler.java:83) > at > org.apache.james.smtpserver.SMTPHandler.handleConnection(SMTPHandler.java:391) > at > org.apache.james.util.connection.ServerConnection$ClientConnectionRunner.run(ServerConnection.java:422) > at > org.apache.excalibur.thread.impl.ExecutableRunnable.execute(ExecutableRunnable.java:55) > at > org.apache.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:116) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (JAMES-580) NPE is issued when receiving a "read receipt" from MS Outlook, and is set to true
[ http://issues.apache.org/jira/browse/JAMES-580?page=all ] Vincenzo Gianferrari Pini reopened JAMES-580: - Assignee: Vincenzo Gianferrari Pini (was: Norman Maurer) The fix was ok for 3.0 in trunk, but not for 2.3.0. > NPE is issued when receiving a "read receipt" from MS Outlook, and > is set to true > -- > > Key: JAMES-580 > URL: http://issues.apache.org/jira/browse/JAMES-580 > Project: James > Issue Type: Bug > Components: SMTPServer >Affects Versions: 2.3.0rc1 >Reporter: Vincenzo Gianferrari Pini > Assigned To: Vincenzo Gianferrari Pini >Priority: Blocker > Fix For: 2.3.0rc2 > > > A NPE is issued when receiving a "read receipt" from MS Outlook (not Outlook > express nor Thunderbird), and is set to true and > the sender IP address is not in : > 27/07/06 17:17:00 ERROR smtpserver: Exception opening socket: null > java.lang.NullPointerException > at > org.apache.james.smtpserver.MailCmdHandler.doMAIL(MailCmdHandler.java:210) > at > org.apache.james.smtpserver.MailCmdHandler.onCommand(MailCmdHandler.java:83) > at > org.apache.james.smtpserver.SMTPHandler.handleConnection(SMTPHandler.java:391) > at > org.apache.james.util.connection.ServerConnection$ClientConnectionRunner.run(ServerConnection.java:422) > at > org.apache.excalibur.thread.impl.ExecutableRunnable.execute(ExecutableRunnable.java:55) > at > org.apache.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:116) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JAMES-580) NPE is issued when receiving a "read receipt" from MS Outlook, and is set to true
[ http://issues.apache.org/jira/browse/JAMES-580?page=all ] Vincenzo Gianferrari Pini resolved JAMES-580. - Resolution: Fixed The fix now is checking senderAddress != null, instead of sender != null. > NPE is issued when receiving a "read receipt" from MS Outlook, and > is set to true > -- > > Key: JAMES-580 > URL: http://issues.apache.org/jira/browse/JAMES-580 > Project: James > Issue Type: Bug > Components: SMTPServer >Affects Versions: 2.3.0rc1 >Reporter: Vincenzo Gianferrari Pini > Assigned To: Vincenzo Gianferrari Pini >Priority: Blocker > Fix For: 2.3.0rc2 > > > A NPE is issued when receiving a "read receipt" from MS Outlook (not Outlook > express nor Thunderbird), and is set to true and > the sender IP address is not in : > 27/07/06 17:17:00 ERROR smtpserver: Exception opening socket: null > java.lang.NullPointerException > at > org.apache.james.smtpserver.MailCmdHandler.doMAIL(MailCmdHandler.java:210) > at > org.apache.james.smtpserver.MailCmdHandler.onCommand(MailCmdHandler.java:83) > at > org.apache.james.smtpserver.SMTPHandler.handleConnection(SMTPHandler.java:391) > at > org.apache.james.util.connection.ServerConnection$ClientConnectionRunner.run(ServerConnection.java:422) > at > org.apache.excalibur.thread.impl.ExecutableRunnable.execute(ExecutableRunnable.java:55) > at > org.apache.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:116) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (POSTAGE-11) Getting NPE in POP3Client
Getting NPE in POP3Client - Key: POSTAGE-11 URL: http://issues.apache.org/jira/browse/POSTAGE-11 Project: Postage Issue Type: Bug Reporter: Vincenzo Gianferrari Pini Assigned To: Vincenzo Gianferrari Pini Getting sometimes an NPE in POP3Client: [java] java.lang.NullPointerException [java] at org.apache.james.postage.client.POP3Client.findAllMatchingTestMail(POP3Client.java:133) [java] at org.apache.james.postage.client.POP3Client.doSample(POP3Client.java:97) [java] at org.apache.james.postage.execution.SampleController.run(SampleController.java:77) [java] at java.util.TimerThread.mainLoop(Timer.java:432) [java] at java.util.TimerThread.run(Timer.java:382) After that Postage stops downloading messages thru POP3. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (POSTAGE-11) Getting NPE in POP3Client
[ http://issues.apache.org/jira/browse/POSTAGE-11?page=all ] Vincenzo Gianferrari Pini resolved POSTAGE-11. -- Resolution: Fixed Fixed the code adding a simple "!= null" test. > Getting NPE in POP3Client > - > > Key: POSTAGE-11 > URL: http://issues.apache.org/jira/browse/POSTAGE-11 > Project: Postage > Issue Type: Bug >Reporter: Vincenzo Gianferrari Pini > Assigned To: Vincenzo Gianferrari Pini > > Getting sometimes an NPE in POP3Client: > [java] java.lang.NullPointerException > [java] at > org.apache.james.postage.client.POP3Client.findAllMatchingTestMail(POP3Client.java:133) > [java] at > org.apache.james.postage.client.POP3Client.doSample(POP3Client.java:97) > [java] at > org.apache.james.postage.execution.SampleController.run(SampleController.java:77) > [java] at java.util.TimerThread.mainLoop(Timer.java:432) > [java] at java.util.TimerThread.run(Timer.java:382) > After that Postage stops downloading messages thru POP3. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (POSTAGE-11) Getting NPE in POP3Client
[ http://issues.apache.org/jira/browse/POSTAGE-11?page=all ] Vincenzo Gianferrari Pini closed POSTAGE-11. > Getting NPE in POP3Client > - > > Key: POSTAGE-11 > URL: http://issues.apache.org/jira/browse/POSTAGE-11 > Project: Postage > Issue Type: Bug >Reporter: Vincenzo Gianferrari Pini > Assigned To: Vincenzo Gianferrari Pini > > Getting sometimes an NPE in POP3Client: > [java] java.lang.NullPointerException > [java] at > org.apache.james.postage.client.POP3Client.findAllMatchingTestMail(POP3Client.java:133) > [java] at > org.apache.james.postage.client.POP3Client.doSample(POP3Client.java:97) > [java] at > org.apache.james.postage.execution.SampleController.run(SampleController.java:77) > [java] at java.util.TimerThread.mainLoop(Timer.java:432) > [java] at java.util.TimerThread.run(Timer.java:382) > After that Postage stops downloading messages thru POP3. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JAMES-596) Reorganize SMIME crypto support code to share it with future new PGP support code
Reorganize SMIME crypto support code to share it with future new PGP support code - Key: JAMES-596 URL: http://issues.apache.org/jira/browse/JAMES-596 Project: James Issue Type: New Feature Components: Matchers/Mailets (bundled) Reporter: Vincenzo Gianferrari Pini Assigned To: Vincenzo Gianferrari Pini Priority: Minor Fix For: 3.0 The current mailet code that does cryptographic activity is specialized for SMIME. In order to support PGP, as requested by some people (Robert Burrel Donkin), it would be nice to have it rearranged in order to share code as much as possible. First of all let me recall the current code. There are two similar but not identically built "strains", one written by me, and the other by Stefano. But from our point of view they are equivalent. My strain is the SMIMESign mailet that extends SMIMEAbstractSign; the split between the two classes is just to allow for some possible massaging of the message before the signature (the "explanation text" in this case). Stefano's strain is composed of the SMIMECheckSignature and SMIMEDecrypt mailet, plus the IsSMIMEEncrypted, IsSMIMESigned and IsX509CertificateSubject matchers. SMIMEAbstractSign (and SMIMEDecrypt) uses *for all the SMIME related work* the org.apache.james.security.KeyHolder helper class; similarly SMIMECheckSignature uses the org.apache.james.security.KeyStoreHolder helper class. The approach I'm thinking about is the following: 1) Create an *interface* named KeyHolder with all the needed (and not SMIME dependent) methods. 2) Rename the current KeyHolder class to SMIMEKeyHolder, and have it implement the KeyHolder interface doing the SMIME implementation. 3) Create a new PGPKeyHolder implementing KeyHolder interface doing the PGP work. My assumption is that *there is a total equivalence* between the SMIME and PGP required/desired functionalities, captured by the KeyHolder interface. 4) Have SMIMEAbstractSign instantiate either SMIMEKeyHolder or PGPKeyHolder as the KeyHolder object that will be used, based on the value of a new attribute, that would be either org.apache.james.security.SMIMEKeyHolder or org.apache.james.security.PGPKeyHolder . 5) Rename SMIMESign to Sign, that will become the concrete sign malet driven by the attribute. 6) Create two new and very simple SMIMESign and PGPSign mailets, whose only job would be to force the attribute to the right one. An equivalent job could and should be done for Stefano's mailets. The PGP equivalents of Stefano's matchers should be written from scratch. I have already done part of the work. If nobody has anything to say against this approach, I will start committing to trunk in the next few days. Robert after that will write the PGP specific code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JAMES-600) Reduce the number of token.toLowerCase() calls in org.apache.james.util.BayesianAnalyzer.buildDegenerated()
Reduce the number of token.toLowerCase() calls in org.apache.james.util.BayesianAnalyzer.buildDegenerated() --- Key: JAMES-600 URL: http://issues.apache.org/jira/browse/JAMES-600 Project: James Issue Type: Improvement Reporter: Vincenzo Gianferrari Pini Assigned To: Vincenzo Gianferrari Pini Priority: Minor Fix For: 2.4.0 Slightly change the code in order to reduce the number of token.toLowerCase() calls in org.apache.james.util.BayesianAnalyzer.buildDegenerated(), that is a cpu hot spot. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JAMES-600) Reduce the number of token.toLowerCase() calls in org.apache.james.util.BayesianAnalyzer.buildDegenerated()
[ http://issues.apache.org/jira/browse/JAMES-600?page=all ] Vincenzo Gianferrari Pini resolved JAMES-600. - Resolution: Fixed > Reduce the number of token.toLowerCase() calls in > org.apache.james.util.BayesianAnalyzer.buildDegenerated() > --- > > Key: JAMES-600 > URL: http://issues.apache.org/jira/browse/JAMES-600 > Project: James > Issue Type: Improvement >Reporter: Vincenzo Gianferrari Pini > Assigned To: Vincenzo Gianferrari Pini >Priority: Minor > Fix For: 2.4.0 > > > Slightly change the code in order to reduce the number of token.toLowerCase() > calls in org.apache.james.util.BayesianAnalyzer.buildDegenerated(), that is a > cpu hot spot. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JAMES-616) Add chi-square-based spam filter approach to BayesianAnalyzer.
Add chi-square-based spam filter approach to BayesianAnalyzer. -- Key: JAMES-616 URL: http://issues.apache.org/jira/browse/JAMES-616 Project: James Issue Type: Improvement Components: Matchers/Mailets (bundled) Affects Versions: Trunk Reporter: Vincenzo Gianferrari Pini Assigned To: Vincenzo Gianferrari Pini Fix For: Trunk We should add chi-square-based spam filter approach to BayesianAnalyzer, based on Gary Robinson's blog and paper (http://garyrob.blogs.com//handlingtokenredundancy94.pdf). I will first of all write him an email asking for some clarifications. My impression for now is that the work should not be so difficult. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-596) Reorganize SMIME crypto support code to share it with future new PGP support code
[ http://issues.apache.org/jira/browse/JAMES-596?page=comments#action_12437208 ] Vincenzo Gianferrari Pini commented on JAMES-596: - I would return for getSignerCN() the primary name of the PGP key; for getSignerDistinguishedName() I would return a "nice" toString of the PGP key, and why not a string like "[EMAIL PROTECTED], CN=The Primary Name", consistent with the string returned by X509Certificate.getSubjectDN().toString()? > Reorganize SMIME crypto support code to share it with future new PGP support > code > - > > Key: JAMES-596 > URL: http://issues.apache.org/jira/browse/JAMES-596 > Project: James > Issue Type: New Feature > Components: Matchers/Mailets (bundled) >Reporter: Vincenzo Gianferrari Pini > Assigned To: Vincenzo Gianferrari Pini >Priority: Minor > Fix For: Trunk > > > The current mailet code that does cryptographic activity is specialized for > SMIME. In order to support PGP, as requested by some people (Robert Burrel > Donkin), it would be nice to have it rearranged in order to share code as > much as possible. > First of all let me recall the current code. > There are two similar but not identically built "strains", one written by me, > and the other by Stefano. But from our point of view they are equivalent. > My strain is the SMIMESign mailet that extends SMIMEAbstractSign; the split > between the two classes is just to allow for some possible massaging of the > message before the signature (the "explanation text" in this case). > Stefano's strain is composed of the SMIMECheckSignature and SMIMEDecrypt > mailet, plus the IsSMIMEEncrypted, IsSMIMESigned and IsX509CertificateSubject > matchers. > SMIMEAbstractSign (and SMIMEDecrypt) uses *for all the SMIME related work* > the org.apache.james.security.KeyHolder helper class; similarly > SMIMECheckSignature uses the org.apache.james.security.KeyStoreHolder helper > class. > The approach I'm thinking about is the following: > 1) Create an *interface* named KeyHolder with all the needed (and not SMIME > dependent) methods. > 2) Rename the current KeyHolder class to SMIMEKeyHolder, and have it > implement the KeyHolder interface doing the SMIME implementation. > 3) Create a new PGPKeyHolder implementing KeyHolder interface doing the PGP > work. My assumption is that *there is a total equivalence* between the SMIME > and PGP required/desired functionalities, captured by the KeyHolder interface. > 4) Have SMIMEAbstractSign instantiate either SMIMEKeyHolder or PGPKeyHolder > as the KeyHolder object that will be used, based on the value of a new > attribute, that would be either > org.apache.james.security.SMIMEKeyHolder or > org.apache.james.security.PGPKeyHolder . > 5) Rename SMIMESign to Sign, that will become the concrete sign malet driven > by the attribute. > 6) Create two new and very simple SMIMESign and PGPSign mailets, whose only > job would be to force the attribute to the right one. > An equivalent job could and should be done for Stefano's mailets. > The PGP equivalents of Stefano's matchers should be written from scratch. > I have already done part of the work. If nobody has anything to say against > this approach, I will start committing to trunk in the next few days. Robert > after that will write the PGP specific code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-596) Reorganize SMIME crypto support code to share it with future new PGP support code
[ http://issues.apache.org/jira/browse/JAMES-596?page=comments#action_12437209 ] Vincenzo Gianferrari Pini commented on JAMES-596: - Regarding your proposal of adding only RFC 3156 OpenPGP/MIME support, I leave it to your judgement; but what is the client support for it? The "Classic inline PGP" is always available to anyone having PGP or GPG installed, so isn't it a pity to miss its support? > Reorganize SMIME crypto support code to share it with future new PGP support > code > - > > Key: JAMES-596 > URL: http://issues.apache.org/jira/browse/JAMES-596 > Project: James > Issue Type: New Feature > Components: Matchers/Mailets (bundled) >Reporter: Vincenzo Gianferrari Pini > Assigned To: Vincenzo Gianferrari Pini >Priority: Minor > Fix For: Trunk > > > The current mailet code that does cryptographic activity is specialized for > SMIME. In order to support PGP, as requested by some people (Robert Burrel > Donkin), it would be nice to have it rearranged in order to share code as > much as possible. > First of all let me recall the current code. > There are two similar but not identically built "strains", one written by me, > and the other by Stefano. But from our point of view they are equivalent. > My strain is the SMIMESign mailet that extends SMIMEAbstractSign; the split > between the two classes is just to allow for some possible massaging of the > message before the signature (the "explanation text" in this case). > Stefano's strain is composed of the SMIMECheckSignature and SMIMEDecrypt > mailet, plus the IsSMIMEEncrypted, IsSMIMESigned and IsX509CertificateSubject > matchers. > SMIMEAbstractSign (and SMIMEDecrypt) uses *for all the SMIME related work* > the org.apache.james.security.KeyHolder helper class; similarly > SMIMECheckSignature uses the org.apache.james.security.KeyStoreHolder helper > class. > The approach I'm thinking about is the following: > 1) Create an *interface* named KeyHolder with all the needed (and not SMIME > dependent) methods. > 2) Rename the current KeyHolder class to SMIMEKeyHolder, and have it > implement the KeyHolder interface doing the SMIME implementation. > 3) Create a new PGPKeyHolder implementing KeyHolder interface doing the PGP > work. My assumption is that *there is a total equivalence* between the SMIME > and PGP required/desired functionalities, captured by the KeyHolder interface. > 4) Have SMIMEAbstractSign instantiate either SMIMEKeyHolder or PGPKeyHolder > as the KeyHolder object that will be used, based on the value of a new > attribute, that would be either > org.apache.james.security.SMIMEKeyHolder or > org.apache.james.security.PGPKeyHolder . > 5) Rename SMIMESign to Sign, that will become the concrete sign malet driven > by the attribute. > 6) Create two new and very simple SMIMESign and PGPSign mailets, whose only > job would be to force the attribute to the right one. > An equivalent job could and should be done for Stefano's mailets. > The PGP equivalents of Stefano's matchers should be written from scratch. > I have already done part of the work. If nobody has anything to say against > this approach, I will start committing to trunk in the next few days. Robert > after that will write the PGP specific code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-596) Reorganize SMIME crypto support code to share it with future new PGP support code
[ http://issues.apache.org/jira/browse/JAMES-596?page=comments#action_12437211 ] Vincenzo Gianferrari Pini commented on JAMES-596: - About the right approach to the generation of the new MimeBodyPart content, I'm unable to answer; perhaps someone else of the committers can. Post the question to server-dev. > Reorganize SMIME crypto support code to share it with future new PGP support > code > - > > Key: JAMES-596 > URL: http://issues.apache.org/jira/browse/JAMES-596 > Project: James > Issue Type: New Feature > Components: Matchers/Mailets (bundled) >Reporter: Vincenzo Gianferrari Pini > Assigned To: Vincenzo Gianferrari Pini >Priority: Minor > Fix For: Trunk > > > The current mailet code that does cryptographic activity is specialized for > SMIME. In order to support PGP, as requested by some people (Robert Burrel > Donkin), it would be nice to have it rearranged in order to share code as > much as possible. > First of all let me recall the current code. > There are two similar but not identically built "strains", one written by me, > and the other by Stefano. But from our point of view they are equivalent. > My strain is the SMIMESign mailet that extends SMIMEAbstractSign; the split > between the two classes is just to allow for some possible massaging of the > message before the signature (the "explanation text" in this case). > Stefano's strain is composed of the SMIMECheckSignature and SMIMEDecrypt > mailet, plus the IsSMIMEEncrypted, IsSMIMESigned and IsX509CertificateSubject > matchers. > SMIMEAbstractSign (and SMIMEDecrypt) uses *for all the SMIME related work* > the org.apache.james.security.KeyHolder helper class; similarly > SMIMECheckSignature uses the org.apache.james.security.KeyStoreHolder helper > class. > The approach I'm thinking about is the following: > 1) Create an *interface* named KeyHolder with all the needed (and not SMIME > dependent) methods. > 2) Rename the current KeyHolder class to SMIMEKeyHolder, and have it > implement the KeyHolder interface doing the SMIME implementation. > 3) Create a new PGPKeyHolder implementing KeyHolder interface doing the PGP > work. My assumption is that *there is a total equivalence* between the SMIME > and PGP required/desired functionalities, captured by the KeyHolder interface. > 4) Have SMIMEAbstractSign instantiate either SMIMEKeyHolder or PGPKeyHolder > as the KeyHolder object that will be used, based on the value of a new > attribute, that would be either > org.apache.james.security.SMIMEKeyHolder or > org.apache.james.security.PGPKeyHolder . > 5) Rename SMIMESign to Sign, that will become the concrete sign malet driven > by the attribute. > 6) Create two new and very simple SMIMESign and PGPSign mailets, whose only > job would be to force the attribute to the right one. > An equivalent job could and should be done for Stefano's mailets. > The PGP equivalents of Stefano's matchers should be written from scratch. > I have already done part of the work. If nobody has anything to say against > this approach, I will start committing to trunk in the next few days. Robert > after that will write the PGP specific code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JAMES-616) Add chi-square-based spam filter approach to BayesianAnalyzer.
[ http://issues.apache.org/jira/browse/JAMES-616?page=all ] Vincenzo Gianferrari Pini updated JAMES-616: Fix Version/s: Next Major Gary Robinson gave a first answer with some clarifications/links and promised to come back, but didn't show up again. But I think that the information I have may be enough. > Add chi-square-based spam filter approach to BayesianAnalyzer. > -- > > Key: JAMES-616 > URL: http://issues.apache.org/jira/browse/JAMES-616 > Project: James > Issue Type: Improvement > Components: Matchers/Mailets (bundled) >Affects Versions: Next Major >Reporter: Vincenzo Gianferrari Pini > Assigned To: Vincenzo Gianferrari Pini > Fix For: Trunk, Next Major > > > We should add chi-square-based spam filter approach to BayesianAnalyzer, > based on Gary > Robinson's blog and paper > (http://garyrob.blogs.com//handlingtokenredundancy94.pdf). > I will first of all write him an email asking for some clarifications. > My impression for now is that the work should not be so difficult. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (JAMES-712) Improbe Logging of delivery exception
[ http://issues.apache.org/jira/browse/JAMES-712?page=all ] Vincenzo Gianferrari Pini reopened JAMES-712: - The fix applied to RemoteDelivery does not compile under JDK 1.4 because uses "replace(CharSequence target, CharSequence replacement)". > Improbe Logging of delivery exception > - > > Key: JAMES-712 > URL: http://issues.apache.org/jira/browse/JAMES-712 > Project: James > Issue Type: Task > Components: Matchers/Mailets (bundled) >Reporter: Norman Maurer > Assigned To: Norman Maurer >Priority: Minor > Fix For: Next Major > > > At the moment no information get logged why the remotemailserver return a > permanent or a temporary exception. Thats really bad logging for admins. We > should provide information of the cause without need for enable debugging in > RemoteDelivery -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
