RE: smtp-api mergin
Am Donnerstag, den 13.07.2006, 14:17 -0400 schrieb Noel J. Bergman: Ok i finished my reorganize of the packages and classes. I don't know that you took out the configuration of the pre and post handlers. The configuration should be soft. Those are only two lines, and should be put back in. We can always detect if we are missing something, and log a message or even default to throwing an exception. Im not sure about this.. I have no problems to put them back, but i think the hardcoded version give us more control that the admin not break the RFC.. Anyway i will put them back in config if that makes you happier. Also, the core handler package can implement both MessageHandler and CommandsHandler so that you can eliminate the explicit SendMailHandler config. --- Noel Im not sure i understand you right... You think we should also load the SendMailHandler in the CoreCmdHandlerLoader ? If that was what you mean i don't agree.. Cause this handler must be calles after the other MessageHandler (which the admin maybe configure). We could only force it to be loaded as the last MessageHandler.. bye Norman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Deprecating code ...
Noel J. Bergman wrote: Stefano Bagnara wrote: About this deprecation issue [you] would like to deprecate some code and I reply with +++1. If you don't want to deprecate it, well, I'm ok anyway. Oh, I want to mark it as deprecated, and see what feedback we get. My way of thinking is to deprecate whatever is felt to be out of the common main view of the direction to go, so the users know that they should not count on them for new things, but not to delete them until it is cumbersome to mantain. Vincenzo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Wiring/Dependencies/Lifecycle Management for next James
Am Donnerstag, den 13.07.2006, 16:48 +0200 schrieb Stefano Bagnara: Hi all, This is a test, I hope it will work because I don't see another simple solution to move forward from the current stall. I'm starting this vote because I saw that there is a lot moving around this issue and we probably currently don't share a common idea, so it's better to see what the preferences/likes/dislikes/vetoes are in the various aspects of this issue. I expect to receive clear -1...+1 votes (decimal values allowed) even if this is not a standard vote. I'd like to keep discussion out from this thread in order to keep this clean (there are a lot of options, so it's better to keep it clean). I think that a small sentence explaing the vote should be allowed, but please *small* or this will become a mess (maybe you want to add priorities and dependencies on other votes). The votes are many and are not clearly organized, but I hope this will give us a first overview on the things where we have agreements and things that may be discussed more. We have a broad range of possibilities for our architecture, so we should try to narrow the real options that will not be vetoed and get more consensus. I want to see if there is at least one option that will not be vetoed by someone :-/ This is far from complete, but I saw that we was not reaching an agreement, so we need to understand what is the current position of each committer before starting working on things that will be vetoed. I hope that after this one it will be more clean what are the liked scenarios and that we can start with small proposals for solutions, roadmap and specific votes. I will put my votes in a reply to this. Here is a glossary: API Components = Matcher/Mailets/new CommandHandlers Top Level Components = The components currently wired in assembly.xml Other James Components = Other components instantiated by Top Level Components but not directly handled by Phoenix. Phoenix = Our current Avalon container Avalon = The avalon framework Cornerstone = I will consider both Cornerstone and Excalibur components inside this name Example votes: +1 = I really like this and I will put my hands in for this to happen +0.1 .. +0.9 = I like this solution +0 = I'm not against this -0 = I can live with it, but I prefer something else. -0.1 .. -0.9 = I don't like it, but I will not veto it -1 = I'm probably going to veto this And now the bulk questions: A. Deprecate phoenix A1. Replace it with Plexus (http://plexus.codehaus.org/) +0 Never used.. A2. Replace it with another Avalon compliant container (name it) -0 A3. Replace it with Felix (http://incubator.apache.org/felix/) +0.5 Felix seems to be very intressting.. But maybe its a bit overkill.. B. Remove avalon B1. Remove it from API Components +0.8 That whould be cool.. I don't like the idea of need knowing about avalon to write mailets or smtphandler etc.. B2. Remove it from both API Components and Other James Components -0.5 B3. Remove it from all the codes and keep wrapper for Top Level Components to be adapted to the container (Avalon or other). -0.5 C. Remove Cornerstone C1. Remove cornerstone dependencies in favor of Jakarta commons libraries where available +0.5 C2. Use MINA to replace sockets/connection dependencies +1 After what i see on apacheCon this seems to be the best way to get a better rid of many connections etc. C3. Import code from not replaceable libraries to James codebase (refactoring it to remove Avalon and anything else needed) -0 Now I expect that many will have replied +X to A3 or at least to one of the B*, so here are further votes related to this scenario. D. Lifecycle and dependency management D1. Use JNDI everywhere (ala J2EE) +0 Can say anything about this.. no expirence D2. Keep Avalon interfaces but write our own mini container for non Top Level Components. +0.5 I like avalon ;-) D3. Introduce new interfaces to replace the one from Avalon and create our own container (that may delegate to the real container we use) to manage lifecycle and dependencies. (see also Central class for service injection topic by Bernd) +0.8 I like Bernds idea.. E. Specific API Components issues: E1. Use JNDI to lookup datasources +0 like i said no expirences with JNDI E2. Use JNDI to lookup users/mail repositories, the store and any other James component. +0 E3. Add datasource, re positories, store and any other used service to the MailetContext API (this also mean adding the interfaces for this objects to the Mailet APIs) -0 E4. Use Dependency Injection (setter based, constructor based, enabling interfaces, service locator injection) to automatically satisfy components dependencies. +0.8 E5. Keep the ServiceManager as a property stored in the MailetContext. -0.5 Seems to be more a hack.. If you voted +X to something DI related please also vote this:
svn commit: r421835 - in /james/server/trunk/src/xdocs: changelog.xml download.xml stylesheets/project.xml
Author: bago Date: Fri Jul 14 01:34:34 2006 New Revision: 421835 URL: http://svn.apache.org/viewvc?rev=421835view=rev Log: Changelog updated to 2.3.0b3 Download fixed sources=source (Thanks to Robert Burrell Donkin) Menu changed to reflect both 2.2 and 2.3b documentation (JAMES-432) Modified: james/server/trunk/src/xdocs/changelog.xml james/server/trunk/src/xdocs/download.xml james/server/trunk/src/xdocs/stylesheets/project.xml Modified: james/server/trunk/src/xdocs/changelog.xml URL: http://svn.apache.org/viewvc/james/server/trunk/src/xdocs/changelog.xml?rev=421835r1=421834r2=421835view=diff == --- james/server/trunk/src/xdocs/changelog.xml (original) +++ james/server/trunk/src/xdocs/changelog.xml Fri Jul 14 01:34:34 2006 @@ -20,6 +20,42 @@ liAnd a href=http://wiki.apache.org/james/JamesV3;more/a/li /ul /section +section name=Version 2.3.0b3 +pReleased 15 July 2006/p +pDetail/p +h2Bug/h2 +ul +li[a href='http://issues.apache.org/jira/browse/JAMES-554'JAMES-554/a] - Set the right svn property for excutable files/li +li[a href='http://issues.apache.org/jira/browse/JAMES-559'JAMES-559/a] - Message body get lost after call saveChanges() and move to other processor/li +li[a href='http://issues.apache.org/jira/browse/JAMES-560'JAMES-560/a] - SetMimeHeader not throw an MessagingException if needed config values missed/li +li[a href='http://issues.apache.org/jira/browse/JAMES-561'JAMES-561/a] - User aliasing does not work/li +/ul +/section +section name=Version 2.3.0b2 +pUnreleased/p +pDetail/p +h2Bug/h2 +ul +li[a href='http://issues.apache.org/jira/browse/JAMES-527'JAMES-527/a] - data-source for default derby maildb is configured with a relative path/li +li[a href='http://issues.apache.org/jira/browse/JAMES-535'JAMES-535/a] - Denial of service (CPU consumption) via a long argument to the MAIL command./li +li[a href='http://issues.apache.org/jira/browse/JAMES-538'JAMES-538/a] - Original headers are lost when trying to alter headers of a cloned message/li +li[a href='http://issues.apache.org/jira/browse/JAMES-540'JAMES-540/a] - catch lifecycle problems for handlers/li +/ul +h2Improvement/h2 +ul +li[a href='http://issues.apache.org/jira/browse/JAMES-553'JAMES-553/a] - Upgrade to Derby 10.1.3.1/li +/ul +h2New Feature/h2 +ul +li[a href='http://issues.apache.org/jira/browse/JAMES-537'JAMES-537/a] - Add ConfigOption to disable the RemoteManager/li +/ul +h2Task/h2 +ul +li[a href='http://issues.apache.org/jira/browse/JAMES-496'JAMES-496/a] - Add a default hardcoded configuration for the SMTPHandlerChain/li +li[a href='http://issues.apache.org/jira/browse/JAMES-529'JAMES-529/a] - Add a GenericAddFooter for use in AddFooter and CommandListservFooter/li +li[a href='http://issues.apache.org/jira/browse/JAMES-536'JAMES-536/a] - Decide what to do with repository implementations configured by default (db/dbfile/file)/li +/ul +/section section name=Version 2.3.0b1 pReleased 9 June 2006/p pDetails/p Modified: james/server/trunk/src/xdocs/download.xml URL: http://svn.apache.org/viewvc/james/server/trunk/src/xdocs/download.xml?rev=421835r1=421834r2=421835view=diff == --- james/server/trunk/src/xdocs/download.xml (original) +++ james/server/trunk/src/xdocs/download.xml Fri Jul 14 01:34:34 2006 @@ -67,19 +67,19 @@ liSource (Unix TAR): a href=[preferred]/james/james-2.3.0-src.tar.gzjames-2.3.0-src.tar.gz/a [a -href=http://www.apache.org/dist/james/sources/james-2.3.0-src.tar.gz.asc;PGP/a]/li +href=http://www.apache.org/dist/james/source/james-2.3.0-src.tar.gz.asc;PGP/a]/li liSource (ZIP Format): a href=[preferred]/james/james-2.3.0-src.zipjames-2.3.0-src.zip/a [a -href=http://www.apache.org/dist/james/sources/james-2.3.0-src.zip.asc;PGP/a]/li +href=http://www.apache.org/dist/james/source/james-2.3.0-src.zip.asc;PGP/a]/li liSource with Avalon Phoenix binaries (Unix TAR): a href=[preferred]/james/james-with-phoenix-2.3.0-src.tar.gzjames-with-phoenix-2.3.0-src.tar.gz/a [a -href=http://www.apache.org/dist/james/sources/james-with-phoenix-2.3.0-src.tar.gz.asc;PGP/a]/li +href=http://www.apache.org/dist/james/source/james-with-phoenix-2.3.0-src.tar.gz.asc;PGP/a]/li liSource with Avalon Phoenix binaries (ZIP Format): a href=[preferred]/james/james-with-phoenix-2.3.0-src.zipjames-with-phoenix-2.3.0-src.zip/a [a -href=http://www.apache.org/dist/james/sources/james-with-phoenix-2.3.0-src.zip.asc;PGP/a]/li +href=http://www.apache.org/dist/james/source/james-with-phoenix-2.3.0-src.zip.asc;PGP/a]/li lia href=[preferred]/james/binaries/Other Modified: james/server/trunk/src/xdocs/stylesheets/project.xml URL: http://svn.apache.org/viewvc/james/server/trunk/src/xdocs/stylesheets/project.xml?rev=421835r1=421834r2=421835view=diff == ---
svn commit: r421840 - /james/jspf/trunk/src/site/site.xml
Author: bago Date: Fri Jul 14 02:04:43 2006 New Revision: 421840 URL: http://svn.apache.org/viewvc?rev=421840view=rev Log: Commented empty/todo pages and links to non existant subproject websites. We'll enable them as soon as content will appear. Modified: james/jspf/trunk/src/site/site.xml Modified: james/jspf/trunk/src/site/site.xml URL: http://svn.apache.org/viewvc/james/jspf/trunk/src/site/site.xml?rev=421840r1=421839r2=421840view=diff == --- james/jspf/trunk/src/site/site.xml (original) +++ james/jspf/trunk/src/site/site.xml Fri Jul 14 02:04:43 2006 @@ -13,9 +13,11 @@ item name=Apache href=http://www.apache.org/; / item name=James href=http://james.apache.org// item name=jSPF href=http://james.apache.org/jspf// + !-- Not yet there item name=jSieve href=http://james.apache.org/jsieve// item name=Mime4J href=http://james.apache.org/mime4j// item name=Postage href=http://james.apache.org/postage// + -- /links menu name=jSPF @@ -25,8 +27,10 @@ /menu menu name=Documentation + !-- Not yet there item name=jSPF href=documentation.html/ item name=Design href=design.html/ + -- item name=jSPF Javadocs href=apidocs/index.html / item name=Useful RFCs href=rfclist.html/ /menu @@ -35,7 +39,9 @@ item name=Bug Database href=issue-tracking.html/ item name=Source Code href=source-repository.html/ item name=Who We Are href=team-list.html / + !-- Not yet there item name=Contributing href=contribute.html/ + -- item name=Standards href=code-standards.html/ item name=License href=license.html/ /menu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Wiring/Dependencies/Lifecycle Management for next James
And now the bulk questions: A. Deprecate phoenix +0.8 A1. Replace it with Plexus (http://plexus.codehaus.org/) -0 A2. Replace it with another Avalon compliant container (name it) -0 A3. Replace it with Felix (http://incubator.apache.org/felix/) +0.2 B. Remove avalon +0.8 B1. Remove it from API Components +0.8 B2. Remove it from both API Components and Other James Components +0.8 B3. Remove it from all the codes and keep wrapper for Top Level Components to be adapted to the container (Avalon or other). +0.8 C. Remove Cornerstone +0.8 C1. Remove cornerstone dependencies in favor of Jakarta commons libraries where available +0.8 C2. Use MINA to replace sockets/connection dependencies +0.8 C3. Import code from not replaceable libraries to James codebase (refactoring it to remove Avalon and anything else needed) +0.8 Now I expect that many will have replied +X to A3 or at least to one of the B*, so here are further votes related to this scenario. D. Lifecycle and dependency management D1. Use JNDI everywhere (ala J2EE) +0 D2. Keep Avalon interfaces but write our own mini container for non Top Level Components. -0.8 D3. Introduce new interfaces to replace the one from Avalon and create our own container (that may delegate to the real container we use) to manage lifecycle and dependencies. (see also Central class for service injection topic by Bernd) +0.2 E. Specific API Components issues: E1. Use JNDI to lookup datasources +0.2 E2. Use JNDI to lookup users/mail repositories, the store and any other James component. +0.2 E3. Add datasource, repositories, store and any other used service to the MailetContext API (this also mean adding the interfaces for this objects to the Mailet APIs) +0.5 for a proper subset (which one :-) ?) -0.8 for everything E4. Use Dependency Injection (setter based, constructor based, enabling interfaces, service locator injection) to automatically satisfy components dependencies. +0 E5. Keep the ServiceManager as a property stored in the MailetContext. -0.8 If you voted +X to something DI related please also vote this: G. Dependency Injection +0 G1. Use CDI (constructor base DI) G2. Use Setters G3. Use Setters with Enabling Interfaces G4. Keep single setter for ServiceLocator (ala Avalon) G5. Use reflection and convention over configurations for the above DI Furthermore these technologies could be used to sole one or more aspects of the above points, please give your opinions. H1. Use Spring +0 H2. Use XBean +0 H3. Use OSGi Declarative Services +0 Vincenzo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Wiring/Dependencies/Lifecycle Management for next James
Stefano Bagnara wrote: Noel J. Bergman wrote: You might want to have some discussion on each item before calling for a vote. In some of these cases, there may be alternatives to the choices you listed. Example votes -1 or +1 are the only meaningful votes at the ASF. I think I really well explained what was the goal of the vote and made clear this is not a standard vote but a vote-like. I used the [VOTE] subject to attract replies. To attract replies, you shouldn't use [VOTE], if you don't call for a vote. Please take people seriously. Nevertheless, I think the thread you started serves a purpose by collecting a mood board on some/most of the pending discussions. And it certainly should not be intended as a way to shut down discussions. Most of the topics are such long-termed endevours that it is impossible to do a bulk commit now. What I agree on with you and I feel you are missing is the free way to keep development going. I'd recommend to take one piece at a time from the pile of todo's, recall or start some dev-discussions, then vote, then implement and be flexible enough to accept peoples ongoing input. I explained what the various -1..+1 votes should be used for. That said, you should now explain your reply in the context of the topic I started. snip/ Btw I hope you will be more flexible about this discussion procedures the next times. Noel (whom you are responding to) like everyone else participating in the project has the right and the duty to define procedures. He responded in a very flexible way, I think. I stopped my activity on the james trunk because I feel out of synch with the team, I'm simply trying to understand if there is still space for my work or not. I'm very confident, there is. But having people with different opinions is not a burden, it's a gift. The community is growing, so there are popping up more opinions, what do you expect? (with community growing linear, opinions are growing exponentially ;-)) Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Postage SVN notifications
Noel J. Bergman wrote: As a person having SVN karma, would you mind to turn on SVN notifications for postage Yes. And, honestly, I'm annoyed. The mailer must be configured BEFORE the commits are made, not after. As far as I know, we now need a list of every revision number for all of the commits to postage so that we can re-run the mailer to generate the notices. But I realize that this wasn't intentional. No one meant to do anything wrong, they just don't know what they are doing in terms of how SVN is configured. This went wrong, I am sorry for not speaking up sooner. (Or asking more politely.) What can I do to drive this topic, so we can get over this? We have JIRA POSTAGE-4 to track progress. The revisions in question are: 414144 (initial directory creation) 415259, 415275, 415277 (initial import) 415580, 415588, 417957, 420489, 421286 (development) For future reference, DO NOT CREATE ANYTHING DIRECTLY UNDER james/ unless you know how, and have authorization, to change the mailer configuration. As an aside, since we're talking about SVN and I'm in a snarky mood, we should get rid of this sandbox nonsense. Let's stick with the standard tags, branches, trunk. What's a sandbox? A branch for playing in. Fine. Put it under branches. It's slightly off topic, but anyway: +1, sandbox should live under branches/ Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r421849 - in /james/server/trunk/src/xdocs: documentation_2_3.xml download.xml
Author: norman Date: Fri Jul 14 02:47:49 2006 New Revision: 421849 URL: http://svn.apache.org/viewvc?rev=421849view=rev Log: Fix some typos Modified: james/server/trunk/src/xdocs/documentation_2_3.xml james/server/trunk/src/xdocs/download.xml Modified: james/server/trunk/src/xdocs/documentation_2_3.xml URL: http://svn.apache.org/viewvc/james/server/trunk/src/xdocs/documentation_2_3.xml?rev=421849r1=421848r2=421849view=diff == --- james/server/trunk/src/xdocs/documentation_2_3.xml (original) +++ james/server/trunk/src/xdocs/documentation_2_3.xml Fri Jul 14 02:47:49 2006 @@ -54,7 +54,7 @@ lia href=smtp_configuration_2_3.htmlSMTP Server Configuration/a/li lia href=nntp_configuration_2_3.htmlNNTP Server Configuration/a/li lia href=fetchmail_configuration_2_3.htmlfetchMail Configuration/a/li -lia href=remotemanager_configuration_2_1.htmlRemoteManager Configuration/a/li +lia href=remotemanager_configuration_2_3.htmlRemoteManager Configuration/a/li lia href=repositories_2_3.htmlRepository Configuration/a/li lia href=spoolmanager_configuration_2_3.htmlSpoolManager Configuration/a/li lia href=serverwide_configuration_2_3.htmlServer-wide Configuration/a/li Modified: james/server/trunk/src/xdocs/download.xml URL: http://svn.apache.org/viewvc/james/server/trunk/src/xdocs/download.xml?rev=421849r1=421848r2=421849view=diff == --- james/server/trunk/src/xdocs/download.xml (original) +++ james/server/trunk/src/xdocs/download.xml Fri Jul 14 02:47:49 2006 @@ -52,7 +52,7 @@ release. See the a href=http://james.apache.org/changelog.html;Change Log/a for a detailed list of changes. Some of the earlier defects could -turn a James mail server into an Open Relay. All users of James are urged to upgrade to James v2.2.0 as soon as +turn a James mail server into an Open Relay. All users of James are urged to upgrade to James v2.3.0 as soon as possible./p ul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Wiring/Dependencies/Lifecycle Management for next James
Bernd Fondermann wrote: I think I really well explained what was the goal of the vote and made clear this is not a standard vote but a vote-like. I used the [VOTE] subject to attract replies. To attract replies, you shouldn't use [VOTE], if you don't call for a vote. Please take people seriously. I really hope you don't think I don't take people seriously. I used VOTE because this is like a VOTE but ASF never defined this kind of vote, so I thought it was better to try this test (we are a community, we should try to find solutions even without a lawyer) with multiple vote-like questions as a way to collect as much as possible an overview of our ideas. Maybe I'm the only one confused but I see that is happened too much that we thought we were in line with a goal while we were working on things that have been vetoed (or criticized) when done. Nevertheless, I think the thread you started serves a purpose by collecting a mood board on some/most of the pending discussions. And it certainly should not be intended as a way to shut down discussions. I really hope this will stop religious threads that do not bring anywhere. I hope that starting from the results of this poll (do we want to call it poll?) we can have something more concrete to discuss about. I asked to not start discussions inside the vote replies because I wanted to be able to collect the results in an easy way. Imho discussions will belong to the result comment thread. Most of the topics are such long-termed endevours that it is impossible to do a bulk commit now. I agree, I never thought about a bulk commit. Btw I think that we did a lot of discussions that are meaningless if not contextualized in a long term goal or at least in a set of roadmaps we could reach consensus upon. What I agree on with you and I feel you are missing is the free way to keep development going. I'd recommend to take one piece at a time from the pile of todo's, recall or start some dev-discussions, then vote, then implement and be flexible enough to accept peoples ongoing input. Do you think I should have better started a single vote for each question? I thought at solution for weeks.. unfortunately this my best shot now... if anyone has better way to bring our trunk to life and increase probability to have a James 3.0 in a real future I would really be happy to use my time to partecipate. I explained what the various -1..+1 votes should be used for. That said, you should now explain your reply in the context of the topic I started. snip/ Btw I hope you will be more flexible about this discussion procedures the next times. Noel (whom you are responding to) like everyone else participating in the project has the right and the duty to define procedures. He responded in a very flexible way, I think. I only wanted to say that I opened a topic, I asked to reply with decimal votes, he decided to change the rule. Imo this is not good: other committers did understand my proposed way to vote. I just asked flexibility about this. In the context of my vote/poll each of the -1 by Noel is a VETO... you know, if everyone put so much vetoes in a list we'll never reach consensus. I stopped my activity on the james trunk because I feel out of synch with the team, I'm simply trying to understand if there is still space for my work or not. I'm very confident, there is. But having people with different opinions is not a burden, it's a gift. The community is growing, so there are popping up more opinions, what do you expect? (with community growing linear, opinions are growing exponentially ;-)) Bernd It's all about consensus: I'm not trying to convince anyone of anything, I'm collecting personal positions, to be able to understand where is the space for consensus. I feel I am the one that much more try to understand other opinions and try to find consensus. As an example you can read our last threads about configurations: I tried to put out a list of possibilities, I declared my preferences, I examinated proposals by other members, I made questions... thread died. I know I'm hard in words, but 1) I never learned soft words in english 2) I'm just trying to be concrete. James needs much more concrete things. Stefano - 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]
svn commit: r421871 - /james/server/trunk/src/java/org/apache/james/smtpserver/RcptCmdHandler.java
Author: vincenzo
Date: Fri Jul 14 04:25:34 2006
New Revision: 421871
URL: http://svn.apache.org/viewvc?rev=421871view=rev
Log:
A fastfail DNSBRL blacklisted message is rejected even if the sender user is
successfully SMTP AUTHenticated (see JAMES-566).
The correction is to a misleading long boolean expression, that already gave us
a problem in the past.
Modified:
james/server/trunk/src/java/org/apache/james/smtpserver/RcptCmdHandler.java
Modified:
james/server/trunk/src/java/org/apache/james/smtpserver/RcptCmdHandler.java
URL:
http://svn.apache.org/viewvc/james/server/trunk/src/java/org/apache/james/smtpserver/RcptCmdHandler.java?rev=421871r1=421870r2=421871view=diff
==
--- james/server/trunk/src/java/org/apache/james/smtpserver/RcptCmdHandler.java
(original)
+++ james/server/trunk/src/java/org/apache/james/smtpserver/RcptCmdHandler.java
Fri Jul 14 04:25:34 2006
@@ -188,7 +188,7 @@
}
if (session.isBlockListed()
// was found in the RBL
-(!session.isRelayingAllowed() || (session.isAuthRequired()
session.getUser() == null)) // Not an authorized IP or SMTP AUTH is enabled
and not authenticated
+!(session.isRelayingAllowed() || (session.isAuthRequired()
session.getUser() != null)) // Not (either an authorized IP or (SMTP AUTH
is enabled and not authenticated))
!(recipientAddress.getUser().equalsIgnoreCase(postmaster) ||
recipientAddress.getUser().equalsIgnoreCase(abuse))) {
// trying to send e-mail to other than postmaster or abuse
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r421873 - /james/server/branches/v2.3/src/java/org/apache/james/smtpserver/RcptCmdHandler.java
Author: vincenzo
Date: Fri Jul 14 04:27:06 2006
New Revision: 421873
URL: http://svn.apache.org/viewvc?rev=421873view=rev
Log:
A fastfail DNSBRL blacklisted message is rejected even if the sender user is
successfully SMTP AUTHenticated (see JAMES-566).
The correction is to a misleading long boolean expression, that already gave us
a problem in the past.
Modified:
james/server/branches/v2.3/src/java/org/apache/james/smtpserver/RcptCmdHandler.java
Modified:
james/server/branches/v2.3/src/java/org/apache/james/smtpserver/RcptCmdHandler.java
URL:
http://svn.apache.org/viewvc/james/server/branches/v2.3/src/java/org/apache/james/smtpserver/RcptCmdHandler.java?rev=421873r1=421872r2=421873view=diff
==
---
james/server/branches/v2.3/src/java/org/apache/james/smtpserver/RcptCmdHandler.java
(original)
+++
james/server/branches/v2.3/src/java/org/apache/james/smtpserver/RcptCmdHandler.java
Fri Jul 14 04:27:06 2006
@@ -159,7 +159,7 @@
}
if (session.isBlockListed()
// was found in the RBL
-(!session.isRelayingAllowed() || (session.isAuthRequired()
session.getUser() == null)) // Not an authorized IP or SMTP AUTH is enabled
and not authenticated
+!(session.isRelayingAllowed() || (session.isAuthRequired()
session.getUser() != null)) // Not (either an authorized IP or (SMTP AUTH
is enabled and not authenticated))
!(recipientAddress.getUser().equalsIgnoreCase(postmaster) ||
recipientAddress.getUser().equalsIgnoreCase(abuse))) {
// trying to send e-mail to other than postmaster or abuse
responseString = 530
+DSNStatus.getStatus(DSNStatus.PERMANENT,DSNStatus.SECURITY_AUTH)+ Rejected:
unauthenticated e-mail from + session.getRemoteIPAddress() + is restricted.
Contact the postmaster for details.;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Loom/Phoenix Integration with Plexus
On Jul 14, 2006, at 4:28 AM, Jason van Zyl wrote: After meeting Mauro in London we got chatting and eventually started talking about containers, which lead to talking about Loom/ Phoenix and Plexus. One thing lead to another and I asked if we could possibly merge the contain and component code. A little email exchange ensued and Peter Donald, Peter Royal, Mauro, Paul agreed to the merger. Johan is away but I am going to assume he would be fine with it. The promise is to keep things working for existing Loom/Phoenix users, other then that we benefit by getting some excellent code. The developers of Loom/Phoenix don't have a lot of time so there might not be much input there but there is a vast store of good code and awesome components. Technically how the merger will proceed I will work on but I wanted to now ask the rest of the Plexus developers what they think about the merger of the code. I think this will be awesome personally. cc'ing the james-dev list, as I'm sure they'll be interested in this news as users of Phoenix. -pete -- [EMAIL PROTECTED] - http://fotap.org/~osi smime.p7s Description: S/MIME cryptographic signature
[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]
Re: IMAP Draft: Quota
Am Montag, den 10.07.2006, 16:18 +0200 schrieb Bernd Fondermann: are you really making that good progress you are already discussing advanced features, or are quotas required by IMAP? Well, the progress is near to alpha for basic commands. What really is needed now is starting an Imap capable storage back-end. It is great how hard you are working on the IMAP topic. I hope to get a chance to review it soon! That would be great! At the moment I make only sporadic changes to the draft API interfaces on SVN. I'd more or less stick to your JIRA postings/attachements (as JIRA is one of our 'official' project resources). I understand that. But as I said before it's always a lot of work to make a release even if it is only a draft. I made the effort and brought the interfaces to some kind of a consistent state and attached it to Jira. Also, we have to keep in mind how to integrate your code with the James codebase. But that's for another thread... I think a lot about that. I also have some ideas. One question is for example how could James benefit from a logical namespace for message repositories / mailboxes? But IMO the first solution will be to allow optionally plugging in the namespace/hierarchy aware repository and using wrappers for legacy code. (a NamespaceMailRepository implementation). So the codebase keeps stable. namespaces for repos is something which is also going around in my mind for some time. maybe we should have a separate discussion about it in near future! I hope soon, because it's getting a blocker for my work on imap. No waterfall model, just an overview. No complete elaborated plan, just a few thoughts and drafts. And I promise just to skip thinking about quota right now, because it should be enough as an overview. :-) we could go on. but we must keep in mind the whole discussion is repeated in the future when quotas eventually are reconsidered. ;-) The optimist would say ideas will keep growing until then and we'll be able to discuss on a higher level. :-) Well, I agree there are more important topics now. Joachim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Wiring/Dependencies/Lifecycle Management for next James
Stefano Bagnara wrote: Bernd Fondermann wrote: Nevertheless, I think the thread you started serves a purpose by collecting a mood board on some/most of the pending discussions. And it certainly should not be intended as a way to shut down discussions. I really hope this will stop religious threads that do not bring anywhere. I hope that starting from the results of this poll (do we want to call it poll?) we can have something more concrete to discuss about. Let's call it poll :-) . I asked to not start discussions inside the vote replies because I wanted to be able to collect the results in an easy way. Imho discussions will belong to the result comment thread. Correct. Most of the topics are such long-termed endevours that it is impossible to do a bulk commit now. I agree, I never thought about a bulk commit. Btw I think that we did a lot of discussions that are meaningless if not contextualized in a long term goal or at least in a set of roadmaps we could reach consensus upon. Correct. What I agree on with you and I feel you are missing is the free way to keep development going. I'd recommend to take one piece at a time from the pile of todo's, recall or start some dev-discussions, then vote, then implement and be flexible enough to accept peoples ongoing input. Do you think I should have better started a single vote for each question? I thought at solution for weeks.. unfortunately this my best shot now... if anyone has better way to bring our trunk to life and increase probability to have a James 3.0 in a real future I would really be happy to use my time to partecipate. I explained what the various -1..+1 votes should be used for. That said, you should now explain your reply in the context of the topic I started. snip/ Btw I hope you will be more flexible about this discussion procedures the next times. Noel (whom you are responding to) like everyone else participating in the project has the right and the duty to define procedures. He responded in a very flexible way, I think. I only wanted to say that I opened a topic, I asked to reply with decimal votes, he decided to change the rule. Imo this is not good: other committers did understand my proposed way to vote. I just asked flexibility about this. In the context of my vote/poll each of the -1 by Noel is a VETO... you know, if everyone put so much vetoes in a list we'll never reach consensus. I understood and agree with your approach. Just remember that not everyone has enough knowledge/convincement/clear thoughts on every topic (and this is why I answered with several +0 :-) ). I stopped my activity on the james trunk because I feel out of synch with the team, I'm simply trying to understand if there is still space for my work or not. I'm very confident, there is. But having people with different opinions is not a burden, it's a gift. The community is growing, so there are popping up more opinions, what do you expect? (with community growing linear, opinions are growing exponentially ;-)) Bernd It's all about consensus: I'm not trying to convince anyone of anything, I'm collecting personal positions, to be able to understand where is the space for consensus. I feel I am the one that much more try to understand other opinions and try to find consensus. As an example you can read our last threads about configurations: I tried to put out a list of possibilities, I declared my preferences, I examinated proposals by other members, I made questions... thread died. I agree with Bernd. In any case, sometimes ideas have to die and resuscitate again to succeed, as they may be felt less mature or realistic at the beginning (looks like I'm too much a philosopher now, or a priest ;-) ). I know I'm hard in words, but 1) I never learned soft words in english 2) I'm just trying to be concrete. James needs much more concrete things. Words in foreign languages can be subtly misunderstood (think at the recent Zidane vs. Materazzi thread ;-) ). Let's remember that and *never* feel offended. Vincenzo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IMAP Draft: Cluster
Am Montag, den 10.07.2006, 21:05 -0600 schrieb Mike Heath: On Mon, 2006-07-10 at 14:57 +0200, Joachim Draeger wrote: Maybe such idle connections could be handled by a special thread and if any real work is starting on a connection, this one is handed over to a worker thread? To allow many idle connections but limit the maximal possible server load, I have the idea of a central scheduler in mind. The scheduler keeps track of all running threads. If a session thread wants to run an expensive command it has to ask the scheduler first. The thread per connection model simply doesn't scale to the level that would be needed for a decent IMAP server. Why? There are reasons to limit the maximal number of simultaneously running threads. But what are the drawbacks of having one thread per connection? Fortunately, this is a problem that has already been solved by SEDA [1]. The Apache MINA project [2] implements the good ideas of SEDA plus adds a number of other good ideas providing a framework that is very easy to learn and use. MINA also performs and scales very well. I just begun to read MINA docs to get an overview. How does it work internally? How does MINA know there is data waiting on a connection? Is it possible to let Java fire events in a new thread when data has arrived or are you polling every connection for new data? I had a fast look to a SEDA doc. Does MINA support prioritization? E.G.: NOOP is a cheap, LIST or APPEND are expensive commands. Maybe between ProtocolAcceptor and ProtocolHandler? Joachim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] James website update (Was: svn commit: r421896 - in /james/site/trunk/www)
This time a real, official, standard vote. Normally I wouldn't call a vote for a site update, but I just finished committing more than *1000* files updated in our site/trunk repository. As you can see from the funny comment about the 261 parts it changed almost all the website. I published an export of the updated site here: http://people.apache.org/~bago/james/www/ http://people.apache.org/~bago/james/www/jspf/ Main changes: 1) Added jspf website 2) Changed the left column to include 2.3b documentation 3) Added all the latest documentation under 2.3 submenus (mainly updated by Norman, more to be done) 4) Removed few very old files no more linked. 5) Updated mailets API and James javadoc to 2.3.0b3: the one previously online was related to an old 3.0 trunk that has never really been published (it had repositories in Mailet APIs). It was so bad to have javadocs for an unsupported apis that I decided it was better to put 2.3b without not many discussions about putting 2.2.0 or anything else. A +1 will mean I will leave the code in the current trunk and I will run an update on minotaur to publish the changes. If you cast a -1 please let me know if you are simply against the publishing of the updated website or if you want me to revert the commit. This is far from perfect, but I think it is better than before, so let's publish this, and them we can tune it with further changes (maybe with no need to vote at each one). The commit log explain how I generated the files I committed. Stefano [EMAIL PROTECTED] wrote: Author: bago Date: Fri Jul 14 06:05:56 2006 New Revision: 421896 URL: http://svn.apache.org/viewvc?rev=421896view=rev Log: Update full website to include jspf and 2.3 things. 1) ant website from james/server/trunk root. 2) replaced 2.2.0 with 2.3.0 in download.xml 3) mvn site from james/jspf/trunk root. 4) copied jspf/target/site to site root/jspf 5) fixcrlf on all the html files under www [This commit notification would consist of 261 parts, which exceeds the limit of 50 ones, so it was shortened to the summary.] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] James website update (Was: svn commit: r421896 - in /james/site/trunk/www)
+1 Norman Am Freitag, den 14.07.2006, 15:26 +0200 schrieb Stefano Bagnara: This time a real, official, standard vote. Normally I wouldn't call a vote for a site update, but I just finished committing more than *1000* files updated in our site/trunk repository. As you can see from the funny comment about the 261 parts it changed almost all the website. I published an export of the updated site here: http://people.apache.org/~bago/james/www/ http://people.apache.org/~bago/james/www/jspf/ Main changes: 1) Added jspf website 2) Changed the left column to include 2.3b documentation 3) Added all the latest documentation under 2.3 submenus (mainly updated by Norman, more to be done) 4) Removed few very old files no more linked. 5) Updated mailets API and James javadoc to 2.3.0b3: the one previously online was related to an old 3.0 trunk that has never really been published (it had repositories in Mailet APIs). It was so bad to have javadocs for an unsupported apis that I decided it was better to put 2.3b without not many discussions about putting 2.2.0 or anything else. A +1 will mean I will leave the code in the current trunk and I will run an update on minotaur to publish the changes. If you cast a -1 please let me know if you are simply against the publishing of the updated website or if you want me to revert the commit. This is far from perfect, but I think it is better than before, so let's publish this, and them we can tune it with further changes (maybe with no need to vote at each one). The commit log explain how I generated the files I committed. Stefano [EMAIL PROTECTED] wrote: Author: bago Date: Fri Jul 14 06:05:56 2006 New Revision: 421896 URL: http://svn.apache.org/viewvc?rev=421896view=rev Log: Update full website to include jspf and 2.3 things. 1) ant website from james/server/trunk root. 2) replaced 2.2.0 with 2.3.0 in download.xml 3) mvn site from james/jspf/trunk root. 4) copied jspf/target/site to site root/jspf 5) fixcrlf on all the html files under www [This commit notification would consist of 261 parts, which exceeds the limit of 50 ones, so it was shortened to the summary.] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] !EXCUBATOR:1,44b79baf43381598049557! signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: IMAP Draft: Cluster
Joachim Draeger wrote: The thread per connection model simply doesn't scale to the level that would be needed for a decent IMAP server. Why? There are reasons to limit the maximal number of simultaneously running threads. But what are the drawbacks of having one thread per connection? I think that many of the answers you are looking for are better described in papers found here: http://www.eecs.harvard.edu/~mdw/proj/seda/#papers IMAP is a perfect case for SEDA because often there are a lot of idle collection and without SEDA you need to keep idle threads allocated. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] James website update (Was: svn commit: r421896 - in /james/site/trunk/www)
+1 Vincenzo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: The Imap store issue WAS: Deprecating code ...
Am Donnerstag, den 13.07.2006, 20:31 -0400 schrieb Noel J. Bergman: Btw my personal opinion is that James needs new features - IMAP Agreed. And we have a lot of protocol support for it. I have an idea for resolving the store issue. I'm very curious to hear about it! I tried to collect the requirements from James, Imap and Javamail and put it into interfaces. But as Bernd remarked that should be concepts of whole James and I really can't do that all on my own. Joachim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: typo downloads.cgi
Thank you Robert! I just fixed it in our repository, it will published as soon as we'll update the online export. Stefano robert burrell donkin wrote: PGP detached sigs for source links 404. to fix s/sources/source/ (i had intended to submit this change as a patch but the documentation on building and changing the documentation seems a little out of date. i found the site directory but it isn't clear whether the contents are generated) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JSPF-20) Introduce Logger service and use DI to pass it to subcomponents. Add a default JUL or LOG4J implementation for command line usage
Introduce Logger service and use DI to pass it to subcomponents. Add a default JUL or LOG4J implementation for command line usage - Key: JSPF-20 URL: http://issues.apache.org/jira/browse/JSPF-20 Project: jSPF Issue Type: Improvement Components: Core Affects Versions: 0.9 Reporter: Stefano Bagnara We can simply clone the Avalon Logger, so we already can find the Avalon Logger implementation that uses JUL or LOG4J without having to worry about having it working right. -- 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]
Re: IMAP Draft: Cluster
Am Freitag, den 14.07.2006, 15:40 +0200 schrieb Stefano Bagnara: The thread per connection model simply doesn't scale to the level that would be needed for a decent IMAP server. Why? There are reasons to limit the maximal number of simultaneously running threads. But what are the drawbacks of having one thread per connection? I think that many of the answers you are looking for are better described in papers found here: http://www.eecs.harvard.edu/~mdw/proj/seda/#papers Oh dear, it would take me a hundred years for sure to go through all of that :-), although it looks very interesting. It's quite theoretical and I guess my question is more JVM related. When I was looking for the maximal number of threads Java is able to run I found the answer that it is only limited by memory... I always try to challenge propositions. Is it even a problem to have a sleeping thread per connection? IMAP is a perfect case for SEDA because often there are a lot of idle collection and without SEDA you need to keep idle threads allocated. How much does it cost to keep an idle thread allocated? Is it only using memory or using a lot of memory or does the JVM need cpu time to deal with them? Do you recommend using SEDA instead of MINA? Joachim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Apply JAMES-358 patch (singleIPperMX option)
I'm sorry for another vote today, but I found the time only today to collect enough informations to proceed. The vote is to apply the patch attached to http://issues.apache.org/jira/browse/JAMES-358 (Ok, i will fix tabs to spaces if this get a +1) Vincenzo, Bernd, Norman and I already agreed we should apply it, but Noel expressed in a comment I disagree with this patch... and maybe even Danny had something to say. So I decided for a vote because this is there from too much time. The patch introduce a new *optional* value for the dnsserver that make it to only return a single IP for each MX server (even if it is multihomed) when resolving mail servers for a domain. Without this patch I was unable to send 10 mails per day (or similar volumes). As a reference about previous discussions you can read: 1) JIRA Comments: http://issues.apache.org/jira/browse/JAMES-358 2) Thread: [EMAIL PROTECTED] 3) Thread: [EMAIL PROTECTED] Stefano PS: I even think this should be the default, but this vote is not to make it the default, only to add it as an option. PS2: If you have better ideas for the configuration option name singleIPperMX is not so good, so any better idea is welcome! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IMAP Draft: Cluster
On Jul 14, 2006, at 10:08 AM, Joachim Draeger wrote: How much does it cost to keep an idle thread allocated? Is it only using memory or using a lot of memory or does the JVM need cpu time to deal with them? Do you recommend using SEDA instead of MINA? MINA would let you implement a SEDA-style architecture. -pete -- [EMAIL PROTECTED] - http://fotap.org/~osi smime.p7s Description: S/MIME cryptographic signature
Re: IMAP Draft: Cluster
Joachim Draeger wrote: IMAP is a perfect case for SEDA because often there are a lot of idle collection and without SEDA you need to keep idle threads allocated. How much does it cost to keep an idle thread allocated? Is it only using memory or using a lot of memory or does the JVM need cpu time to deal with them? IIRC each jvm thread needs 512K memory for the stack inside the JVM: some application, like resin, bump this value to 2MB at startup (to avoid OOM under deep calls, I guess). (-Xss is the jvm parameter to tune it) Furthermore each JVM implements threads differently on various OSes. Again IIRC jvm 1.4 under linux uses linux processes for threads and this means more memory and resouces for the machine (default stack for a linux process should be 4-32K) I don't know enought the JVM threading model to say how much does the number of threads impact on the performances. Do you recommend using SEDA instead of MINA? At a glance MINA is SEDA for JAVA. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Apply JAMES-358 patch (singleIPperMX option)
+1 (but It should not be a default, the current behaviour is like the RFC says, and our default should mirror that) --Søren On Friday 14 July 2006 16:14, Stefano Bagnara wrote: I'm sorry for another vote today, but I found the time only today to collect enough informations to proceed. The vote is to apply the patch attached to http://issues.apache.org/jira/browse/JAMES-358 (Ok, i will fix tabs to spaces if this get a +1) Vincenzo, Bernd, Norman and I already agreed we should apply it, but Noel expressed in a comment I disagree with this patch... and maybe even Danny had something to say. So I decided for a vote because this is there from too much time. The patch introduce a new *optional* value for the dnsserver that make it to only return a single IP for each MX server (even if it is multihomed) when resolving mail servers for a domain. Without this patch I was unable to send 10 mails per day (or similar volumes). As a reference about previous discussions you can read: 1) JIRA Comments: http://issues.apache.org/jira/browse/JAMES-358 2) Thread: [EMAIL PROTECTED] 3) Thread: [EMAIL PROTECTED] Stefano PS: I even think this should be the default, but this vote is not to make it the default, only to add it as an option. PS2: If you have better ideas for the configuration option name singleIPperMX is not so good, so any better idea is welcome! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc., M.Crypt. wideTrail Phone: +45 25481225 Pilevænget 41 Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web:www.widetrail.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] James website update (Was: svn commit: r421896 - in /james/site/trunk/www)
+1 On Friday 14 July 2006 15:26, Stefano Bagnara wrote: This time a real, official, standard vote. Normally I wouldn't call a vote for a site update, but I just finished committing more than *1000* files updated in our site/trunk repository. As you can see from the funny comment about the 261 parts it changed almost all the website. I published an export of the updated site here: http://people.apache.org/~bago/james/www/ http://people.apache.org/~bago/james/www/jspf/ Main changes: 1) Added jspf website 2) Changed the left column to include 2.3b documentation 3) Added all the latest documentation under 2.3 submenus (mainly updated by Norman, more to be done) 4) Removed few very old files no more linked. 5) Updated mailets API and James javadoc to 2.3.0b3: the one previously online was related to an old 3.0 trunk that has never really been published (it had repositories in Mailet APIs). It was so bad to have javadocs for an unsupported apis that I decided it was better to put 2.3b without not many discussions about putting 2.2.0 or anything else. A +1 will mean I will leave the code in the current trunk and I will run an update on minotaur to publish the changes. If you cast a -1 please let me know if you are simply against the publishing of the updated website or if you want me to revert the commit. This is far from perfect, but I think it is better than before, so let's publish this, and them we can tune it with further changes (maybe with no need to vote at each one). The commit log explain how I generated the files I committed. Stefano [EMAIL PROTECTED] wrote: Author: bago Date: Fri Jul 14 06:05:56 2006 New Revision: 421896 URL: http://svn.apache.org/viewvc?rev=421896view=rev Log: Update full website to include jspf and 2.3 things. 1) ant website from james/server/trunk root. 2) replaced 2.2.0 with 2.3.0 in download.xml 3) mvn site from james/jspf/trunk root. 4) copied jspf/target/site to site root/jspf 5) fixcrlf on all the html files under www [This commit notification would consist of 261 parts, which exceeds the limit of 50 ones, so it was shortened to the summary.] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc., M.Crypt. wideTrail Phone: +45 25481225 Pilevænget 41 Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web:www.widetrail.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (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 ] Stefano Bagnara updated JAMES-566: -- Fix Version/s: 2.3.0b4 (was: 2.3.0b3) 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: 3.0, 2.3.0a1, 2.2.0, 2.3.0a2, 2.3.0, 2.3.0a3, 2.3.0b1, 2.3.0b2, 2.3.0b3 Reporter: Vincenzo Gianferrari Pini Assigned To: Vincenzo Gianferrari Pini Fix For: 2.3.0b4, 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]
svn commit: r421930 - in /james/server/trunk/src/test/org/apache/james/smtpserver: SMTPServerTest.java SMTPTestConfiguration.java
Author: norman
Date: Fri Jul 14 08:58:37 2006
New Revision: 421930
URL: http://svn.apache.org/viewvc?rev=421930view=rev
Log:
Add junit test for JAMES-566.
Modified:
james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java
james/server/trunk/src/test/org/apache/james/smtpserver/SMTPTestConfiguration.java
Modified:
james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java
URL:
http://svn.apache.org/viewvc/james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java?rev=421930r1=421929r2=421930view=diff
==
--- james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java
(original)
+++ james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java
Fri Jul 14 08:58:37 2006
@@ -96,6 +96,10 @@
if (127.0.0.1.equals(host)) return getLocalhostByName();
}
+if (1.0.0.127.bl.spamcop.net.equals(host)) {
+return getLocalhostByName();
+}
+
return InetAddress.getByName(host);
//throw new UnsupportedOperationException(getByName not
implemented in mock for host: +host);
}
@@ -1068,5 +1072,57 @@
}
-
+// Check if auth users get not rejected cause rbl. See JAMES-566
+public void testDNSRBLNotRejectAuthUser() throws Exception {
+m_testConfiguration.setAuthorizedAddresses(192.168.0.1/32);
+m_testConfiguration.setAuthorizingAnnounce();
+m_testConfiguration.useRBL(true);
+finishSetUp(m_testConfiguration);
+
+m_dnsServer.setLocalhostByName(InetAddress.getByName(127.0.0.1));
+
+SMTPClient smtpProtocol = new SMTPClient();
+smtpProtocol.connect(127.0.0.1, m_smtpListenerPort);
+
+smtpProtocol.sendCommand(ehlo,
InetAddress.getLocalHost().toString());
+String[] capabilityRes = smtpProtocol.getReplyStrings();
+
+List capabilitieslist = new ArrayList();
+for (int i = 1; i capabilityRes.length; i++) {
+capabilitieslist.add(capabilityRes[i].substring(4));
+}
+
+assertTrue(anouncing auth required, capabilitieslist
+.contains(AUTH LOGIN PLAIN));
+// is this required or just for compatibility? assertTrue(anouncing
+// auth required, capabilitieslist.contains(AUTH=LOGIN PLAIN));
+
+String userName = test_user_smtp;
+String sender = [EMAIL PROTECTED];
+
+smtpProtocol.setSender(sender);
+
+smtpProtocol.sendCommand(AUTH PLAIN);
+
+m_usersRepository.addUser(userName, pwd);
+
+smtpProtocol.sendCommand(AUTH PLAIN);
+
+smtpProtocol.sendCommand(AUTH PLAIN);
+smtpProtocol.sendCommand(Base64.encodeAsString(\0 + userName
++ \0pwd\0));
+assertEquals(authenticated, 235, smtpProtocol.getReplyCode());
+
+smtpProtocol.addRecipient([EMAIL PROTECTED]);
+assertEquals(authenticated.. not reject, 250, smtpProtocol
+.getReplyCode());
+
+smtpProtocol.sendShortMessageData(Subject: test\r\n\r\nTest
body\r\n);
+
+smtpProtocol.quit();
+
+// mail was propagated by SMTPServer
+assertNotNull(mail received by mail server, m_mailServer
+.getLastMail());
+}
}
Modified:
james/server/trunk/src/test/org/apache/james/smtpserver/SMTPTestConfiguration.java
URL:
http://svn.apache.org/viewvc/james/server/trunk/src/test/org/apache/james/smtpserver/SMTPTestConfiguration.java?rev=421930r1=421929r2=421930view=diff
==
---
james/server/trunk/src/test/org/apache/james/smtpserver/SMTPTestConfiguration.java
(original)
+++
james/server/trunk/src/test/org/apache/james/smtpserver/SMTPTestConfiguration.java
Fri Jul 14 08:58:37 2006
@@ -40,6 +40,7 @@
private boolean m_reverseEqualsHelo = false;
private boolean m_reverseEqualsEhlo = false;
private int m_maxRcpt = 0;
+private boolean m_useRBL = false;
public SMTPTestConfiguration(int smtpListenerPort) {
@@ -120,6 +121,10 @@
public void setHeloEhloEnforcement(boolean heloEhloEnforcement) {
m_heloEhloEnforcement = heloEhloEnforcement;
}
+
+public void useRBL(boolean useRBL) {
+m_useRBL = useRBL;
+}
public void init() throws ConfigurationException {
@@ -137,8 +142,18 @@
handlerConfig.addChild(Util.getValuedConfiguration(heloEhloEnforcement,
m_heloEhloEnforcement+));
if (m_verifyIdentity)
handlerConfig.addChild(Util.getValuedConfiguration(verifyIdentity, +
m_verifyIdentity));
+
handlerConfig.addChild(Util.createSMTPHandlerChainConfiguration());
+if (m_useRBL) {
+DefaultConfiguration handlerChain = (DefaultConfiguration)
handlerConfig
+
Re: [jira] Updated: (JAMES-566) Fastfail DNSRBL blacklisted messages are rejected even if the sender user is successfully SMTP AUTHenticated
Thx for the fix.. But please if you fix a BUG write a junit test too.. I did this now for you ;-) Bye Norman Am Freitag, den 14.07.2006, 08:44 -0700 schrieb Stefano Bagnara (JIRA): [ http://issues.apache.org/jira/browse/JAMES-566?page=all ] Stefano Bagnara updated JAMES-566: -- Fix Version/s: 2.3.0b4 (was: 2.3.0b3) 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: 3.0, 2.3.0a1, 2.2.0, 2.3.0a2, 2.3.0, 2.3.0a3, 2.3.0b1, 2.3.0b2, 2.3.0b3 Reporter: Vincenzo Gianferrari Pini Assigned To: Vincenzo Gianferrari Pini Fix For: 2.3.0b4, 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. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [VOTE] Apply JAMES-358 patch (singleIPperMX option)
+1 But not as default. bye Norman Am Freitag, den 14.07.2006, 16:51 +0200 schrieb Søren Hilmer: +1 (but It should not be a default, the current behaviour is like the RFC says, and our default should mirror that) --Søren On Friday 14 July 2006 16:14, Stefano Bagnara wrote: I'm sorry for another vote today, but I found the time only today to collect enough informations to proceed. The vote is to apply the patch attached to http://issues.apache.org/jira/browse/JAMES-358 (Ok, i will fix tabs to spaces if this get a +1) Vincenzo, Bernd, Norman and I already agreed we should apply it, but Noel expressed in a comment I disagree with this patch... and maybe even Danny had something to say. So I decided for a vote because this is there from too much time. The patch introduce a new *optional* value for the dnsserver that make it to only return a single IP for each MX server (even if it is multihomed) when resolving mail servers for a domain. Without this patch I was unable to send 10 mails per day (or similar volumes). As a reference about previous discussions you can read: 1) JIRA Comments: http://issues.apache.org/jira/browse/JAMES-358 2) Thread: [EMAIL PROTECTED] 3) Thread: [EMAIL PROTECTED] Stefano PS: I even think this should be the default, but this vote is not to make it the default, only to add it as an option. PS2: If you have better ideas for the configuration option name singleIPperMX is not so good, so any better idea is welcome! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
svn commit: r421933 - in /james/server/trunk/src/test/org/apache/james/smtpserver: SMTPServerTest.java SMTPTestConfiguration.java
Author: norman Date: Fri Jul 14 09:11:13 2006 New Revision: 421933 URL: http://svn.apache.org/viewvc?rev=421933view=rev Log: Remove uneeded methods Modified: james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java james/server/trunk/src/test/org/apache/james/smtpserver/SMTPTestConfiguration.java Modified: james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java URL: http://svn.apache.org/viewvc/james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java?rev=421933r1=421932r2=421933view=diff == --- james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java (original) +++ james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java Fri Jul 14 09:11:13 2006 @@ -1102,11 +1102,7 @@ smtpProtocol.setSender(sender); -smtpProtocol.sendCommand(AUTH PLAIN); - m_usersRepository.addUser(userName, pwd); - -smtpProtocol.sendCommand(AUTH PLAIN); smtpProtocol.sendCommand(AUTH PLAIN); smtpProtocol.sendCommand(Base64.encodeAsString(\0 + userName Modified: james/server/trunk/src/test/org/apache/james/smtpserver/SMTPTestConfiguration.java URL: http://svn.apache.org/viewvc/james/server/trunk/src/test/org/apache/james/smtpserver/SMTPTestConfiguration.java?rev=421933r1=421932r2=421933view=diff == --- james/server/trunk/src/test/org/apache/james/smtpserver/SMTPTestConfiguration.java (original) +++ james/server/trunk/src/test/org/apache/james/smtpserver/SMTPTestConfiguration.java Fri Jul 14 09:11:13 2006 @@ -151,7 +151,6 @@ DefaultConfiguration handler = new DefaultConfiguration(handler); handler.setAttribute(class, DNSRBLHandler.class.getName()); handlerChain.addChild(handler); -handlerConfig.addChild(handlerChain); } // Add Configuration for Helo checks and Ehlo checks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Notes from ApacheCon
Noel J. Bergman wrote: We also spoke with the Derby folks, and got some tips from them, which will result in some changes for the database schema. Also, they have a new release coming out with in a week or so, and that would be a good time to put out a release candidate. Any update on this? I would like to know that are the optimizations proposed by the derby folks. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JAMES-449) RemoteAddr and RemoteHost incorrectly set
[ http://issues.apache.org/jira/browse/JAMES-449?page=all ] Stefano Bagnara resolved JAMES-449. --- Resolution: Cannot Reproduce Reopen it with further details if needed. RemoteAddr and RemoteHost incorrectly set - Key: JAMES-449 URL: http://issues.apache.org/jira/browse/JAMES-449 Project: James Issue Type: Bug Components: Matchers/Mailets (bundled) Reporter: Noel J. Bergman At some point -- I suspect LocalDelivery, but haven't checked -- the remoteaddr and remotehost fields are being set to localhost instead of the correct values. -- 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-565) Code review to @deprecate things we already know want to remove in 3.0
[ http://issues.apache.org/jira/browse/JAMES-565?page=all ] Stefano Bagnara updated JAMES-565: -- Fix Version/s: 2.3.0 Affects Version/s: 2.3.0b3 (was: 2.3.0b2) Code review to @deprecate things we already know want to remove in 3.0 -- Key: JAMES-565 URL: http://issues.apache.org/jira/browse/JAMES-565 Project: James Issue Type: Task Affects Versions: 2.3.0b3 Reporter: Stefano Bagnara Fix For: 2.3.0 This is not really needed because with the major number change we could do this anyway, but if we already have some knowledge about things we'll change for sure we can give hints to our users using the @deprecate. -- 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-515) Remove RepositoryManager and cornerstone-store-impl
[ http://issues.apache.org/jira/browse/JAMES-515?page=all ] Stefano Bagnara resolved JAMES-515. --- Resolution: Fixed Remove RepositoryManager and cornerstone-store-impl --- Key: JAMES-515 URL: http://issues.apache.org/jira/browse/JAMES-515 Project: James Issue Type: Task Components: Build System Affects Versions: 3.0 Reporter: Stefano Bagnara Assigned To: Stefano Bagnara Priority: Minor Fix For: 3.0 Attachments: JAMES-515.diff RepositoryManager is not used anymore = Delete it. cornerstone-store-impl should not be used = Delete it, remove from build process, check it works. We could probably remove the whole Store api as we don't even use their implementation. Maybe we could remove the whole objectrepository stuff, hardcoding object and stream repository creation/lookup directly in the AvalonMailRepository and UsersFileRepository. This remove some modularity but this modularity is only in file storage and we want to deprecate cornerstone components, so I think this is a needed step. Has anyone ever customized James altering the Object and Stream repository factory? -- 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]
RE: [VOTE] James website update (Was: svn commit: r421896 - in /james/site/trunk/www)
Stefano Bagnara wrote: Normally I wouldn't call a vote for a site update, but I just finished committing more than *1000* files updated in our site/trunk repository. ROFLMAO! :-D Yes, that's what happens. :-) We've all been there and done that, and had the same reaction. Welcome to the club. :-) I published an export of the updated site here: http://people.apache.org/~bago/james/www/ http://people.apache.org/~bago/james/www/jspf/ Thanks for that, Stefano. :-) Several changes: Would you please update the stylesheet to use the ApacheCon US 2006 logo instead of the one from last year? And, yes, you're about to generate a huge number of changed pages. URL: http://www.apache.org/ads/ApacheCon/234x60-2006-us.gif Also, the beta is 2.3.0b3, not b1. We should add jSPF to the navigation tree for the JAMES site, although I really dislike that we have two totally different looks. There are other things that need to change, but revising the site is an evolution. For example, the version specific docs ought to be under a version specific directory, so that we can publish docs for multiple versions. 2) replaced 2.2.0 with 2.3.0 in download.xml Whoops ... this and the related text changes on the main page are premature, until we do release JAMES v2.3. This is the only thing that I feel should be reverted ... FOR NOW. Everything else is a go. I'd really like to publish the site, with all of the JAMES v2.3 beta content; we just can't say that v2.3 is released until it is. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JSPF-21) SPF1Data.MAX_DEPTH = 10 not enough
SPF1Data.MAX_DEPTH = 10 not enough -- Key: JSPF-21 URL: http://issues.apache.org/jira/browse/JSPF-21 Project: jSPF Issue Type: Bug Components: Core Reporter: Miguel Di Ciurcio Filho Priority: Blocker Using the default MAX_DEPTH = 10 in SPF1Data can not finish the probe for a decision. Try with microsoft.com, it will fail :-P Microsoft's domain have alot of includes. Well, I rised it to 15 and now works fine. -- 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]
Re: [VOTE] James website update (Was: svn commit: r421896 - in /james/site/trunk/www)
Noel J. Bergman wrote: 2) replaced 2.2.0 with 2.3.0 in download.xml Whoops ... this and the related text changes on the main page are premature, until we do release JAMES v2.3. This is the only thing that I feel should be reverted ... FOR NOW. Everything else is a go. I'd really like to publish the site, with all of the JAMES v2.3 beta content; we just can't say that v2.3 is released until it is. Well, this is good, because in fact I did exactly the opposite. Our trunk xdocs already generate 2.3.0 references in the download page, so I replaced 2.3.0 with 2.2.0 before submitting to the site repository. Sorry for the wrong comment, happy to see you noticed this! Stefano PS: about the other things I will do the simple ones before updating. About the layout I did something as a test few weeks ago, but I thought we can live with 2 different layouts for a while: not perfect, but better than nothing! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
