[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]
[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] 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 keyHolderClass attribute, that would be either keyHolderClass org.apache.james.security.SMIMEKeyHolder /keyHolderClassor keyHolderClass org.apache.james.security.PGPKeyHolder /keyHolderClass. 5) Rename SMIMESign to Sign, that will become the concrete sign malet driven by the keyHolderClass attribute. 6) Create two new and very simple SMIMESign and PGPSign mailets, whose only job would be to force the keyHolderClass 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 keyHolderClass attribute, that would be either keyHolderClass org.apache.james.security.SMIMEKeyHolder /keyHolderClassor keyHolderClass org.apache.james.security.PGPKeyHolder /keyHolderClass. 5) Rename SMIMESign to Sign, that will become the concrete sign malet driven by the keyHolderClass attribute. 6) Create two new and very simple SMIMESign and PGPSign mailets, whose only job would be to force the keyHolderClass 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 keyHolderClass attribute, that would be either keyHolderClass org.apache.james.security.SMIMEKeyHolder /keyHolderClassor keyHolderClass org.apache.james.security.PGPKeyHolder /keyHolderClass. 5) Rename SMIMESign to Sign, that will become the concrete sign malet driven by the keyHolderClass attribute. 6) Create two new and very simple SMIMESign and PGPSign mailets, whose only job would be to force the keyHolderClass 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-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] 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-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 keyHolderClass attribute, that would be either keyHolderClass org.apache.james.security.SMIMEKeyHolder /keyHolderClassor keyHolderClass org.apache.james.security.PGPKeyHolder /keyHolderClass. 5) Rename SMIMESign to Sign, that will become the concrete sign malet driven by the keyHolderClass attribute. 6) Create two new and very simple SMIMESign and PGPSign mailets, whose only job would be to force the keyHolderClass 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: (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] 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] Reopened: (JAMES-580) NPE is issued when receiving a read receipt from MS Outlook, and checkValidSenderDomain 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 checkValidSenderDomain 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 checkValidSenderDomain is set to true and the sender IP address is not in authorizedAddresses: 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 checkValidSenderDomain 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 checkValidSenderDomain 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 checkValidSenderDomain is set to true and the sender IP address is not in authorizedAddresses: 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: (JAMES-580) NPE is issued when receiving a read receipt from MS Outlook, and checkValidSenderDomain is set to true
NPE is issued when receiving a read receipt from MS Outlook, and checkValidSenderDomain 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 checkValidSenderDomain is set to true and the sender IP address is not in authorizedAddresses: 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 checkValidSenderDomain 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 checkValidSenderDomain set to true would lose messages. NPE is issued when receiving a read receipt from MS Outlook, and checkValidSenderDomain 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 checkValidSenderDomain is set to true and the sender IP address is not in authorizedAddresses: 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-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-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] 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] 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-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] 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] 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: !-- Whitelist Management -- !-- Manages for each local user a white list of remote addresses whose messages -- !-- should never be blocked as spam. -- !-- -- !-- If automaticInsert is true, it will check, for a local sender, if a remote recipient -- !-- is already in the list: if not, it will be automatically inserted. -- !-- This is under the interpretation that if a local sender X sends a message to a -- !-- remote recipient Y, then later on if a message is sent by Y to X it should be -- !-- considered always valid and never blocked; hence Y should be in the white list -- !-- of X. -- !-- -- !-- Another mode of operations is when a local sender sends a message to whitelistManagerAddress -- !-- with one of three specific values in the subject, to -- !-- (i) send back a message displaying a list of the addresses in his own list (displayFlag); -- !-- (ii) insert some new addresses in his own list (insertFlag); -- !-- (iii) remove some addresses from his own list (removeFlag). -- !-- In all of the three above cases the message will be ghosted and the postmaster will reply -- !-- to the sender. -- !-- -- !-- The sender name is always converted to its primary name (handling aliases). -- !-- mailet match=SMTPAuthSuccessful class=WhiteListManager onMailetException=ignore repositoryPathdb://maildb/repositoryPath automaticInserttrue/automaticInsert whitelistManagerAddress[EMAIL PROTECTED]/whitelistManagerAddress displayFlagdisplay/displayFlag insertFlaginsert/insertFlag removeFlagremove/removeFlag /mailet -- 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] 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-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
maxPingsn/maxPings, 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 maxPings0/maxPings 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] 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] 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-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] 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] 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] 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: authAnnounce. When false, the behaviour would be as always (depend on authRequired); 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 authRequiredfalse/authRequired and authAnnouncetrue/authAnnounce? If not, it would be better to just add a new possible value to authRequired: authRequiredannounce/authRequired, that implies authRequiredtrue/authRequired. 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] 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 protocolfile/protocol), 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] 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. !-- The Connection Manager block -- ... !-- The max-connections parameter specifies the default maximum number of client -- !-- connections that this connection manager will allow per managed server socket. -- !-- This value can be overridden by each individual service. -- !-- If no value is specified, the value defaults to 30. -- !-- A value of 0 means that there is no limit imposed by the connection manager, although -- !-- resource limitations imposed by other components (i.e. max # of threads) may -- !-- serve to limit the number of open connections. -- !-- -- connections idle-timeout30/idle-timeout max-connections30/max-connections /connections -- 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-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-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] 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] 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) jre/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 jre/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 jre/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 james/lib, not from jre/lib, so the jars needed mus be placed in james/lib. I mean james/lib, not james/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 james/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 james/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 james/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 james/lib, or B.2 Copy some other provider jars to james/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 jre/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
