Re: [VOTE] Release JAMES IMAP 0.1
+1 this is great news, well done everyone. On 16 Sep 2010 13:24, "Norman" wrote: I will close the VOTE on Friday 17.09.2010 09:00 CEST. Thx, Norman Am 16.09.2010 07:34, schrieb Manuel Carrasco Moñino: > > +1, It looks good for me, please release the artifacts. > > -Manolo > > On Mon, Sep 13, 2010 at...
Re: [VOTE] Release apache-mailet-base 1.1
+1 (no time to review, but I trust you Norman..) On Fri, May 21, 2010 at 10:15 AM, Manuel Carrasco Moñino wrote: > +1 > > -Manolo > > On Wed, May 19, 2010 at 4:56 PM, Vincenzo Gianferrari Pini > wrote: >> [X] +0 No time for review >> >> Vincenzo >> > > - > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > > - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: [VOTE] Release James-Project 1.5
+1 On 12 Jan 2010 21:10, "Norman Maurer" wrote: +1 Bye Norman 2010/1/12, Manuel Carrasco Moñino : > +1 > > On Tue, Jan 12, 2010 at 7:09 PM, Stefano Bagnara wrote: > >> 2010/1/12 No...
Re: How to configure the Websphere Business Event with apache-james
add it to the smtp server block On Tue, Nov 17, 2009 at 10:53 AM, limincn wrote: > > Thank you for your answering > > But I can not find the tag in the config.xml. > > Would you kindly tell me where I should difine the tag exactly in the > config.xml. > > or It will be better if you can give me a sample file segment. > > Thank you in advance. > > > Danny Angus-2 wrote: >> >> norman already said: >> >> Maybe websphere is not using <> in mail from. You can disable the >> need of the <..> in mail from by setting the following in smtpserver >> component configuration (config.xml). >> >> false >> >> - >> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org >> For additional commands, e-mail: server-dev-h...@james.apache.org >> >> >> > > -- > View this message in context: > http://old.nabble.com/Re%3A-How-to-configure-the-Websphere-Business-Event-with-apache-james-tp26333801p26387869.html > Sent from the James - Dev mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > > - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: How to configure the Websphere Business Event with apache-james
norman already said: Maybe websphere is not using <> in mail from. You can disable the need of the <..> in mail from by setting the following in smtpserver component configuration (config.xml). false - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: Fundamental Flaws
Simon, > My next statement will certainly raise some flags of concern however I am > hoping you will hear me out Oh we're very sensitive to the nuances of language here, we have a multi-lingual team and have learned the hard way not to make to many assumptions about the difference between a words common usage and its real meaning! > There are frameworks and the like that deal with these issues but I have > come to believe the problem is with component design itself. We do struggle with component design, but more because purity of design is hard to implement in a code base that has adopted, and rejected, a number of approaches over the years. > Anyhow, here goes. Any component that contains any sort of logging code is > flawed. Agreed, but remember that James did this before it was possibel to be agnostic about logging and you're probably the first guy who has had such a beef with it! > I have an approach that addresses these issues and if this is the > appropriate forum I will send another post containing some commentary on how > to do something about it. Indeed it is the right forum, post away. But remember that the problem is the effort not the ideas, so also feel free to submit patches. > I think it is the right forum as I actually use > James as a business tool so I am also expressing things I would like to see > as a user too. At present I don't think I have any code that is useful and I > will continue to use James as I am at present. I do believe however that I > can contribute some ideas and documentation. Documentation is *always* more than welcome! d. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: Passive Spam Revocation
Hi Yao Ziyuan, I see you also posted this to the asrg. I'm shamelessly cross posting my reply, sorry in advance to *both* lists! My response is in two parts: a) I like the fact that the recipient can set up a test which must be passed by the sender. I also like the fact that the test would be passive protection when protecting against, for example spam viruses. In other words the recipient can set up a test, but the test itself only generates load when the sender considers it worthwhile to take the test. However I would prefer to see the test administered by the mail system, rather then via another channel. Solving the problem of spam by invoking a channel not currently involved in mail transport is not really a solution, it is both delegating the problem to another arena, and changing the nature of email. There's nothing inherently wrong with this, but if we are to consider changing the nature of email and channels involved we assume that we could design out the problem from the outset by introducing a strong concept of identity to the process. If we anticipate a design which uses the mail transport the passivity advantage breaks down as the sender must be notified that a test exists. In this case it would fail the criteria for not introducing *more* load (email) in response to spam. The goal is to find a solution which reduces the load as it becomes successful, even if faced with increased demand. What I mean is that a true solution would be completely passive when confronted with spam, and in reducing the spam transported would result in a net decrease in demand. A passive test that meets the criteria would be one in which a test is published in advance at low cost (perhaps by a third party), and for which the solution is encapsulated in the message when it is sent. For example the test may be for the sender to publish SPF records, or use a mark similar to the habeus warrant mark. A recipient domain can publish the test in the their T's & C's. If you want to consider CAPTCHA, perhaps the test would be to pre-solve a CAPTCHA, send the UID of the puzzle and its solution in the mail headers, but CAPTCHA is not really low cost, and is still another channel. b) the idea of using a CAPTCHA is flawed and has already been discussed at length by the asrg. In essence CAPTCHA works where there is less value in solving the puzzle than it costs to solve. If you introduce a strong commercial incentive you will start an arms race which will see people compete to develop systems which can solve puzzles at a lower cost, and others compete to develop more complex puzzles. We must assume that this will happen unless you can describe a test which can be reasoned to be unable to be solved by a machine. The fact that CAPTCHA are impractical to solve with current technology doesn't imply that they are impossible to solve. This ties in with point a) because it suggests that in operation the incentive is there for spammers to now not only send spam but also create additional work for the CAPTCHA component and the quarantine components. Even if spammers use systems which can only achieve a low sucess rate at the test, there is an incentive to attempt the test every time. This generates additional demand. d. On Mon, Oct 26, 2009 at 12:16 AM, Yao Ziyuan wrote: > Passive Spam Revocation (PSR) > > Currently almost all mail systems (e.g. Hotmail and Gmail) use a spam > filter, which can drop good and important messages. > > I propose an optional feature for current mail systems. The main idea > is if a message is considered spam, this spam status can be tracked by > the sender (but not sent to him directly, as the From field can be > faked). The message can be re-marked as "not spam" if the sender can > solve a CAPTCHA. > > STEP 1: A is going to send B a message. A's mail client generates a > random code and puts it in a custom field in the outgoing message's > header: > Code: > STEP 2: A's mail client sends the message, waits 30 seconds, and then visits: > https://spamstatus./?msgid=&code= > This page displays one of these possible "spam statuses": > * MESSAGE CONSIDERED SPAM. (A CAPTCHA is also presented below.) > * MESSAGE CONSIDERED NOT SPAM. > * PENDING. PLEASE TRY AGAIN LATER. > * All other responses mean B's mail system doesn't support this feature. > In the first case, A's mail client will report the status and the > CAPTCHA to A. A can choose to solve the CAPTCHA to prove the message > is not spam. > > Like the idea? Here is the official Google group for it: > http://groups.google.com/group/passive-spam-revocation > > Regards, > Yao Ziyuan > http://sites.google.com/site/yaoziyuan/ > > - > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > > - To unsubscribe, e-mail: server
Re: James on Internet
Frank, >> If you have more questions, ask on server-u...@james.apache.org where >> other users will be able to help you, this list is for contributors to >> talk about developing James. d. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: James on Internet
Hi Frank, read this: http://wiki.apache.org/james/JamesQuickstart If you have more questions, ask on server-u...@james.apache.org where other users will be able to help you, this list is for contributors to talk about developing James. d. On Sat, May 30, 2009 at 12:26 AM, frank2009 wrote: > > Hello > > Im preety new at James Server and my question will reveal it. > I have an application that connects to a smtp server (james) for sending > notifications, for example the notification is for the email u...@gmail.com. > BUT when I check the account on gmail, there is no mail. > > How can I make James to send emails to other accounts such as gmail or > hotmail? > > Thanks in advance > -- > View this message in context: > http://www.nabble.com/James-on-Internet-tp23788445p23788445.html > Sent from the James - Dev mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > > - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: [VOTE] Release Apache Crypto Mailets 1.0
pong? On Thu, May 7, 2009 at 5:29 PM, Robert Burrell Donkin wrote: > ping? > > On Mon, Apr 27, 2009 at 1:18 PM, Robert Burrell Donkin > wrote: >> after positive feedback on the last candidate, i've cut an FC for >> Apache Crypto Mailets 1.0 and uploaded it to >> http://people.apache.org/~rdonkin/apache-crypto-mailets/ >> >> please review and cast your votes >> >> here's my +1 >> >> - robert >> >> --8<- >> [ ] +1 Release Apache Crypo Mailets 1.0 >> [ ] +0 >> [ ] -0 >> [ ] -1 Do not release Apache Crypo Mailets 1.0 >> > > - > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > > - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: [VOTE] Release Apache Crypto Mailets 1.0
+0 - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: [VOTE] Release Apache Mailet Base 1.0
late as ever :-( +1 On Mon, Mar 23, 2009 at 8:27 AM, Robert Burrell Donkin wrote: > i'll tally this VOTE no early than 1200GMT tomorrow (23rd March) so > if anyone else wants to VOTE please do do soon > > - robert > > On Thu, Mar 19, 2009 at 9:24 PM, Robert Burrell Donkin > wrote: >> after three release candidates, i think it's time to call the work. >> the release can be found at >> http://people.apache.org/~rdonkin/apache-mailet-base/ >> >> here's my +1 >> >> - robert >> >> --8<--- >> [ ] +1Release apache-mailet-base 1.0 >> [ ] +0 >> [ ] -0 >> [ ] -1 Do not release apache-mailet-base 1.0 >> - >> > > - > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > > - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Google Summer of Code 2009
Hi, Once again the Apache Software Foundation have been accepted as a mentoring organisation into Google Summer of Code. Students: If you would like to participate in Summer of Code on a James related project reply to this email! If you know anyone who might be interested, forward this email to them. Mentors: If James is to get a student this year we should begin by listing ideas for projects here: http://wiki.apache.org/general/SummerOfCode2009 d. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: [mailet-api] 2.4 RC2
looks ok from here On Thu, Nov 6, 2008 at 6:50 PM, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > last call for reviews > > - robert > > On Wed, Oct 29, 2008 at 6:54 PM, Robert Burrell Donkin > <[EMAIL PROTECTED]> wrote: >> i've created a second release candidate for mailet-api 2.4. it's >> available at http://people.apache.org/~rdonkin/mailet-api/. >> >> please take a look when you have time >> >> - robert >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [server] Java 5, Spring And Phoenix
I agree with Norman, we should possibly poll the users/dev lists but I can't believe that 1.4 is still a requirement. d. On Sun, Nov 2, 2008 at 11:42 AM, Norman Maurer <[EMAIL PROTECTED]> wrote: > Hi Robert, > > I'm very limited in free time atm. So I think the descision should be made > by the active developers. Anyway I think we should drop java 1.4 support at > all. I see no real reason to support such old / outdated jvm. > > > Cheers, > Norman > > 2008/11/2 Robert Burrell Donkin <[EMAIL PROTECTED]> > >> i'm increasingly convinced that the 3.0 codebase contains some >> compelling reasons to upgrade. i think it's important to offer an >> upgrade path for existing installations including retaining 1.4 JVM >> support. this means preserving 1.4 compatibility in the API and >> library layers and in any functions that existing in james 2. >> >> i quite fancy experimenting with some stuff (for example OpenJPA) that >> requires java 5. IIRC there are already some optional modules which >> require a 1.5 JVM but i'd like to use a more regular system. i propose >> using module names to allow java5 in the function layer. for example, >> openjpa-java5 would act like openjpa-function but would only be >> compiled when a 1.5 JVM is used. >> >> any objections? >> >> going forward, this will result in the issue that - given the current >> build - new features would only be available atfer downloading the >> source and compiling with a 1.5 JVM. i would like to suggest the >> following long term strategy: we use the same module system but ship >> the phoenix built under 1.4 (without new features) and spring built >> under 1.5 (with the new features). >> >> opinions? >> >> - robert >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mailet base] Packaging
I think ... org.apache.mailet for things in the mailet project. org.apache.james.mailet for anything in server. If that opinion helps in any way! d. On Sun, Nov 2, 2008 at 12:29 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: >> (as can be seen at >> http://james.apache.org/mailet/base/apidocs/index.html) base mailet >> has quite a lot of packages for such a small library. they also seem >> quite messy - and so unlikely to play well with OSGi (for example). >> >> perhaps we should take this opportunity to rationalise into a single package >> >> ATM we have >> org.apache.james.util.mailet >> org.apache.mailet >> org.apache.mailet.dates >> >> i can see an argument for org.apache.mailet.base but there perhaps >> org.apache.mailet should be reserved just for the API. in which case >> org.apache.james.mailet.base might be better. >> >> opinions? > > Make sense. > > As we already started using "org.apache.mailet" as a top level package > name for mailet stuff maybe org.apache.mailet.base is better. > org.apache.mailet.standard > org.apache.mailet.crypto. > > All of that code should work in any mailet container and have no other > dependencies on james products (IIRC). > > That said I'm also fine with org.apache.james.mailet.base. > > Stefano > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-875) Message-ID changed by mailets (MSGID_FROM_MTA_HEADER changed)
[ https://issues.apache.org/jira/browse/JAMES-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12643651#action_12643651 ] Danny Angus commented on JAMES-875: --- @stefano. Difficult question... In the wrapper makes james behave like an MTA by default but may confuse people who are used to JavaMail. If we could somehow set a flag or param to hint that a new id is required then I'd definitely say it should be in the wrapper, because 99 times out of 100 James users will want to alter an existing message, not effectively create a new one. (This issue also causes problems for MUA's that use ID's and In-reply-to id's to organise threads) > Message-ID changed by mailets (MSGID_FROM_MTA_HEADER changed) > - > > Key: JAMES-875 > URL: https://issues.apache.org/jira/browse/JAMES-875 > Project: JAMES Server > Issue Type: Bug > Components: SMTPServer >Affects Versions: 2.3.1, Trunk > Environment: Linux (Fedora Core 8) >Reporter: Marc SCHNEIDER > Fix For: 2.3.2, Trunk > > Attachments: config-james.xml > > > I noticed that emails sent using my James Server have this header when they > are delivered : > X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,MSGID_FROM_MTA_HEADER > > This is added by SpamAssassin telling that the Message-Id was generated by a > relay, rather than by the user agent. > If I use the same mailing software but not James to send an email, I don't > have this problem. > I looked in the configuration files of James and couldn't find anything about > this msgid. Why is James changing that ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-875) Message-ID changed by mailets (MSGID_FROM_MTA_HEADER changed)
[ https://issues.apache.org/jira/browse/JAMES-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12643537#action_12643537 ] Danny Angus commented on JAMES-875: --- this was discussed with Sun, it is a "feature" of JavaMail and they justify it by saying that javamail is a client API and any changes made by a MUA should result in a new message. The approved workaround is as shown, which was developed specifically after the discussion with the Sun guys. > Message-ID changed by mailets (MSGID_FROM_MTA_HEADER changed) > - > > Key: JAMES-875 > URL: https://issues.apache.org/jira/browse/JAMES-875 > Project: JAMES Server > Issue Type: Bug > Components: SMTPServer >Affects Versions: 2.3.1, Trunk > Environment: Linux (Fedora Core 8) >Reporter: Marc SCHNEIDER > Fix For: 2.3.2, Trunk > > Attachments: config-james.xml > > > I noticed that emails sent using my James Server have this header when they > are delivered : > X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,MSGID_FROM_MTA_HEADER > > This is added by SpamAssassin telling that the Message-Id was generated by a > relay, rather than by the user agent. > If I use the same mailing software but not James to send an email, I don't > have this problem. > I looked in the configuration files of James and couldn't find anything about > this msgid. Why is James changing that ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] James Mime4j 0.4 release (take 2)
+1 On Mon, Aug 18, 2008 at 7:52 AM, Niklas Therning <[EMAIL PROTECTED]> wrote: > +1 (non-binding) > > /Niklas > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [server.trunk] introducing mail-library
+1 better to make it too specific than too general. On 8/4/08, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > On Mon, Aug 4, 2008 at 12:30 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: >> I'd like to create a mail-library module including everything we currently >> have in core-library in the o.a.j.util.mail package. >> >> They are various mdn/dsn (mail delivery notification, delivery status >> notification) related classes and are currently used by smtpserver >> function, >> by the DSNMailet (mailets-function) and by spoolmanager-function >> (sieve.Action). >> >> IIRC we have no references to this classes in configurations and never >> exposed too much of this packages, so we could even rename the packaging. >> >> I'm not sure if "mail-library" (and org.apache.james.mail package) is >> appropriate or we should go with something more detailed like >> "deliverynotification-library" and org.apache.james.dn package. >> >> Opinions? > > more detailed is good: perhaps delivery-library > > - robert > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Sent from Google Mail for mobile | mobile.google.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [server.trunk] modules/package refactoring UPDATE
Well done, and thanks for the clear update, this was good to read. :-) i've just got the code and will have a look at it later, but it sounds like a good job. On 8/11/08, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Stefano Bagnara ha scritto: >> I completed my first step in "repackaging" and "remoduling" server.trunk >> code. >> It is far from being perfect, but at least a first goal is achieved. >> Now no package belong to 2 modules considering -util, -api and -library >> modules. >> [...] >> The next steps (as soon as I find the cycles) are: >> 1. core-library: split it into multiple modules, repackage content to >>avoid use of the "generic" packages. >> 2. take care of packages in functions: they must not reuse packages >>already used by api/util/libraries. > > Here we are at the end of my second day on this "sprint". > > I moved around some more code and main changes are: > > A. Packages should no more be repeated in api/libraries/util. > > B. No package used by api/libraries/util is used in functions (A+B means > that I'm not sure if we have functions using the same packages) > > C. Renamed mailnotification-util to javamail-util (at the end of the 2 > days refactoring it made more sense because of dependencies/content). > > D. Introduced core-api to contain basic service interfaces > (org.apache.james.services) from core-library. (I also moved some of > org.apache.james.services to functions when they were not used by other > modules). > > E. Introduced a management-library module to contain management stuff > (after I refactored code to be selfcontained in that package). Only > RemoteManager-function currently depends on this. > > F. Introduced a core-function module to host all of the code from > core-library that was not used by other functions and reduce the size of > this core-library as it already is the most used dependency. > > I don't plan further major changes after this one, but I have to take > the time to review the resulting structure with my tools. > > There are still some utilities in core-library that should be checked. > I still have issues with some module "granularization" but I can't see a > better solution now. The main goal of this was packages separation and > smaller core-library. > > Currently hudson fail because of svn issues I have to investigate. I'm > not sure if the ant/m2 builds works now and if the resulting binary > works. I'm testing this now. > > I don't know what's next.. I have to relax and look at the "new" tree > after cooling down. > > Please review and tell if you see improvement over the previous tree or > you prefer to revert this 2 days big-bang. > > Stefano > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Sent from Google Mail for mobile | mobile.google.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES and CI (Was: Server's test failure and CI)
> +1 It's cool to have an active infra member in the team! :-) +1, > PS: "all agree" ??? Be serious, we are JAMES PMC! Reaching a majority > agreement is a better goal ;-) Lol. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extract Modred Library [WAS Re: compile 2.3.1]
On Mon, Apr 28, 2008 at 7:42 PM, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > See my reply. What?! d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Introduce mailet-base product
On Thu, Apr 24, 2008 at 8:28 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > > here's my +1 and mine +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Road Forward
On Wed, Apr 16, 2008 at 9:50 PM, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > the major issue is that we don't collectively understand the quality > of the code in trunk nor how it differs from 2.4.x +1 I think, and hope, that that is what Noel, in his inimitable style, is pushing us towards doing. > > modularisation has some significant side benefits (which i'll outline > in another mail) but it also allows us to release code a chunk at a > time: we don't need to review all of trunk, just each bit in turn that > we want to release. +1 ... > manage the progression of code from unstable (trunk) to stable > (production) should be the management point +1 Agreed, if we look at sucessful projects with small numbers of commiters the role of the comitter is one of QA, patches are applied freely (CTR) but its the role of the committers to manage their progress thereafter as gatekeepers, not as coders or innovaters. > > for example, the loosely coupled mailets (whether cryto or standard) > should be extracted into separate products within a week or two. it > would not be unreasonable to diff the mailets with production and then > look to release these products soon. once we're happy with the > quality, we delete the duplicates from production and trunk and depend > on the library releases. +1 > i advocate managing QA not in the transition from branches to trunk > but from trunk to production +1 Exactly what I was trying to say :-) d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Road Forward
Glad you guys seem to have had some productive chat @apachecon. Sorry I had to miss it this year, its the easter holidays and I went to Aviemore with the family. Loads of snow on the ski slopes, which is unusual for the time of year. http://www.cairngormmountain.org.uk/web-cam However to get to the point... my comments are below: > >some looks ok, some looks questionable but i'm > > not enough of an expert to judge. Oh I'm sure you're probably being modest. I think that much of the diff between 2.x branch and trunk suffers from not being tested enough, and not having been subjected to the level of scrutiny which it might have received in more active projects. Which means my opinion is that the trunk isn't fit to release, but it may contain code worth "working up" into production quality. > > 2. i want people to innovate on trunk rather than on their own > > branches. This is a worthwhile goal, but has resulted in the lack of quality assurance which blights the trunk. We need to make a clear statement about the purpose and nature of the trunk. We also need to work out how we avoid a situation where the delta between branch and trunk continues to grow until they are too different to manage. Perhaps we are already at that point. > > IMHO modularisation is an inevitable consequence of > > this approach. I've long said that modularisation is absolutely, fundamentally, totally and utterly essential to the survival of the project. James server is too complex to get your head round all of it in one go, which dissuades people from casual participation, or put another way James requires a significant commitment from contributors just to understand what to change. The shame is that I believe that we loose valuable contributions because of this overhead. > > noel prefers to see this process as allowing anyone to > > dump junk in trunk and i have no probably about that language but > > that's not the way i see things. Nor I, but Noel, as you say, is prone to talking in soundbites and likes to make a drama out of a crisis. I have no problem with people throwing stones into the pond to see what floats to the surface, but I think the truth here is that we need to establish an environment where there is a low cost for people to innovate James, and the higher cost is associated with taking those ideas into production. We lack any notion of degrees of quality assurance, and we lack a lifecycle which allows changes to be promoted up the quality scale. I think we need somewhere to dump junk, a way to pan the junk for nuggets, and a clear path to "release" for chosen changes. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [JAMESHandler] Streams in AbstractJamesHandler
On Sat, Apr 5, 2008 at 10:19 AM, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > #6 uses Buffered streams for IO. > 6A the buffer size is hard coded. this is ok or does it need to be > configurable? Its probably OK, assuming that we understand the normal patterns of data we expect to be reading, and we don;t really want to confuse people with too many esoteric config params. OTOH making it configurable would allow people to be optimised for patterns which don't fit our model. > 6B performance wise, many implementations read character by > character. IMHO it depends what your priorities are, if you *need* to clear down the stream and close it fast, perhaps to release I/O resources you should have a buffer which will make this happen, i.e. one sized to accept most of the stream in one go. If you process your bytes slowly you will fill you buffer, release your resources and then read from the buffer, but if your processing is quick and your I/O slow you may just be streaming your bytes straight through the buffer or even waiting for bytes to be read from the stream. However apart from the memory overhead I can't see that it would do much harm as long as you didn't have huge empty buffers hanging about. But thats just my 2c. > IIRC Andrew C. Oliver posted about that reading or writing > bytewise from a buffered source is an anti-pattern. can anyone > explain? is buffering the right choice? do implementations need to > fill buffers? Not Sure what Andy might have been alluding to if its not covered by my guess work. > > #7 when an exception is caught, it is immediately rethrown. in this > case, are the streams ever closed? do they need to be? Always, in case not closing them locks some I/O resource like a socket or filehandle. IMHO you should always close I/O in finally, even if you suspect that the implementation will release "orphaned" resources at/after garbage collection. > #8 each protocol needs to decide whether to use character or bytewise > streams. so, i think that either in+outs, or out+inReader will be used > but not both. would it be better to split off subclasses or would this > be overengineering? IMHO choices are specialisation and should always be implemented with inheritance, however that itself might be more elegantly achieved using delegation (normalise your model), delegate to an abstract generalisation and provide alternate implementations which can be selected at runtime. Anything else is, to use a datamodelling term again, a "denormalisation". > > #9 these fields only seem to be used when logging exceptions. reverse > DNS lookups have a tendency to be expensive and will often not produce > any useful information. this cost is paid every time that a connection > is started. is this worthwhile? IMO no, DNS lookups should be off by default and enabled by choice if the operator is willing to take the performance hit in return for the convenience of not having to look them up when interpreting the exception. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
GSOC Deadline approaches... Get you applications in NOW
Hi, All you students who are thinking about applying for GSOC for James related projects, you need to get you applications in NOW the deadline is 00:00 April 1st UTC. That means you have *one* *day* left to apply, if you miss the deadline we *can't* consider you at all. http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED] EU 08 [WAS: Re: Apache James and the JCR...]
I'm unable to make it this year, because it coincides with the school's Easter Holidays and we're going away. What a PITA. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: GSoC james-mladmin
James already can archive mail, but to retrieve them you'd need to assign ID's to them. d. > Can you give me some links where i can read about mail archivation? I > I'm going to read ezmlm documentation, and look through is sources, but > project is large and it can take much time, can you advice me something > little easier. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] jSPF-0.9.6
thank goodness one +1! On 3/26/08, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Norman Maurer ha scritto: > > > I finally found the time to prepare for next jSPF > > release... > > > [X] +1 Yes plz make this release official! > > > Stefano > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: GSoC james-mladmin
On 3/27/08, Kirill Kosinov <[EMAIL PROTECTED]> wrote: > 1) Information about moderated list should be stored in some place, i > see many ways here (for example to add in mailet configuration > UserRepository of banned users or to create some kind of ACL) what way > is more correct? ACL(s) preferably, I'm not too keen on extending User's with this specialised data. > 2) How many moderators can be in one mailing list? (one, described in > mailet configuration, or many). Many, and variable, so simple to update lists. > 3) If we have many moderators, should we have a command in telnet > console for adding a moderator, or they are statically described in > mailet config. I think either a command or a separate list that can be updated on the fly, mailet-config needs a restart after a change :-( > 4) Different right for moderators a required? What do you mean? > 5) What about abridged mail reading, JAMES hasn't web interface (correct > me if not) but fetching concrete mail may be realized using commands. That would be nice, it means you'd also have to create an archive for each list. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: GSoC james-mladmin
Kirill, This all sounds good, I would suggest that post moderation has four options, 1/ accept this message only ACCEPT 2/ allow this sender to post again without moderation, ALLOW. 3/ don't allow this message (defaults to this after x hours in queue) REJECT 4/ prevent this sender from sending again BLOCK d. On 3/27/08, Kirill Kosinov <[EMAIL PROTECTED]> wrote: > Goog day. > > Noel, thank you for answer to my previous post in > [EMAIL PROTECTED] mailing list > (GSoC james-mladmin questions). > > So i want to propose more conceit idea. At first i would like to define > some concepts. I'm a student not a james commiter and i want to explain > what i understand by word moderation. > > I have red, that there are two distinct kinds of mailing list > moderation: a moderated subscription process and moderated posting. > > I'll begin with moderated posting :-). Let's imagine that we have a user > who has two mail addresses, one of them is on Subscribe List, the second > is not. User writes two letters from different addresses, JAMES can > determine posting privileges (imagine that we have posting privileges) > and send mail into Subscribe List, second message will be forwarded to > moderator (who recognizes that these messages were sent by the same > individual using different email addresses, the moderator may approve > the second message because he knows the individual who sent it). > > What about current functionality. As i understood subscribing process is > handled by CommandListservManager from transport package (uses command > behavioral pattern), > mailet uses UserRepository (just a folder as i understood), if user > executes subscribe-confirm > command, JAMES adds new user to repository. When message comes > toCommandListservManager it is forwarded to users in UserRepository of > Subscribe List. > > For handling messages james uses visitor patter, asking all registred > mailets, so i > think for moderation new mailet is required. > > What we need to implement moderation. At first i think that we need > implement User interface > or extend DefaultUser (to store posting permissions, moderation > attributes and subscription type, something like 'Regular', 'Digest', > 'Allow'), may be create a subscription object. Second is moderation list > entity, as i understood JAMES hasn't this and that's why if i want to > use moderated configuration settings (things like 'Anyone can post but > all posts are moderated', 'Subscribers can post and all others > moderated', 'Subscribers can post, all others are rejected, and all > posts are moderated' and 'Only moderators can post ') i have to create > this, or to add attribute in mailet... > > I used remote debugging and API docs to understand JAMES functionality, > may be i missed > something or my understanding is wrong, please correct me. > > In conclusion i want to summarize that i want to implement mailets for > post moderation (using list > moderation type) and subscription types. > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Google Summer of Code (GSOC) 2008 now accepting student applications
Student? Want to apply? See James ideas here: http://wiki.apache.org/general/SummerOfCode2008#james Apply to Google Here, with one of our ideas, or one of your own: http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants Remember, there are limited places and your application will be reviewed and compared to applications for all the Apache projects (not just James), so make it a good one :-) ... and don't forget the deadline. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: GSOC 2008
> where do I find the mailing list manager? I'm a little bit confused... http://svn.apache.org/viewvc/james/server/trunk/spoolmanager-function/src/main/java/org/apache/james/transport/mailets/listservcommands/ (or similar path in tag 2.3.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: GSOC 2008
James mlm is mailets and matchers in o.a.james.transport.matchers and o.a.j.t.mailets, I'm not sure what google think about more than one student per idea, I'm guessing that you'd have to apply separately, and then you'll probably be competing. Perhaps if one applies for the VERP task and one for the other mailer enhancements you could collaborate if you're both accepted? I'll ask about multiple students per idea though. d. On Tue, Mar 25, 2008 at 4:30 PM, Sascha Fröhlich <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Noel J. Bergman schrieb: > > > |> | are you interested in verp or mladmin? > |> I threw a glance on VERP and think it's indeed quite interesting. > | > | Please note that I've already written and contributed a REGEX-based VERP > | parser. The real issue would be implementing VERP in the mailing list > | manager, along with other necessary features, and then using VERP > (with the > | provided parser) when receiving bounces and similarly encoded messages. > | > | --- Noel > | > | > | > | - > | To unsubscribe, e-mail: [EMAIL PROTECTED] > | For additional commands, e-mail: [EMAIL PROTECTED] > | > Hi there, > > where do I find the mailing list manager? I'm a little bit confused... > > Greetings, Sascha > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.4.8 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkfpKLkACgkQN1kDpsIDAWFlLgCgznpg0PyW2tEJlGhFHeL8+ZnA > BnoAoLgh1v0zFcKPNW/YrxCA8AFt3Z5y > =u7Hr > -END PGP SIGNATURE- > >
Re: [VOTE] jSPF-0.9.6
+0 If you think this is ready I'm happy to accept that. d. On Tue, Mar 25, 2008 at 11:02 AM, Søren Hilmer <[EMAIL PROTECTED]> wrote: > +0 > -- > Søren Hilmer, M.Sc., M.Crypt. > wideTrailPhone: +45 25481225 > Pilevænget 41Email: [EMAIL PROTECTED] > DK-8961 Allingåbro Web: www.widetrail.dk > > > > On Tue, March 25, 2008 11:17, Norman Maurer wrote: > > Hi dev-team, > > > > I finally found the time to prepare for next jSPF > > release... > > > > Fixed bugs and improvements can be found at: > > > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310350&fixfor=12312813 > > > > > > Packages can be found at: > > > http://people.apache.org/~norman/staging-repository/org/apache/james/apache-jspf/0.9.6/ > > > > So please vote.. The VOTE will be closed on 23.03.08 11:00:00 CET 2008 > > > > VOTE: > > [ ] +1 Yes plz make this release official! > > [ ] +0 Cool to see the release > > [ ] -0 Anyway I don't care to much.. > > [ ] -1 No.. I don't want a new release for some reason! > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: GSOC 2008
You read this too right? http://wiki.apache.org/general/SummerOfCode2008#james - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: GSOC 2008
Oh.. and I'm sure everyone here will be happy to help you with your application. Be sure to explain what you want to do and why, the applications are all reviewed by humans and the "best" ones selected. Not every idea gets a student, and we don't even know how many Apache students there will be until student applications close, so take your time to make a good job of it. d. On Mon, Mar 24, 2008 at 8:48 PM, Danny Angus <[EMAIL PROTECTED]> wrote: > Sascha, > > You apply to Google, if you are successful I will help you with your project. > > I understand that the thing to do right now is to watch announcement > list, when applications open it will be announced. > > d. > > On Mon, Mar 24, 2008 at 7:45 PM, Sascha Fröhlich > > > <[EMAIL PROTECTED]> wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Hi, > > > > Robert Burrell Donkin schrieb: > > > > | On Mon, Mar 24, 2008 at 3:49 PM, Sascha Fröhlich > > | <[EMAIL PROTECTED]> wrote: > > |> Hi there, > > | > > | hi > > | > > |> I would like to apply for Google Summer of Code at the Apache James > > |> Project. I'm quite involved with James due to my student work as a > > |> software developer so I think it's a good choice to apply here. > > | > > | cool > > | > > |> I've got some questions I'd like to ask: > > |> > > |> I've read the FAQ at http://code.google.com/soc/2008/ and I know > > |> basically what I should write in my application. > > |> Is there anything you want to know beside this FAQ? > > | > > | are you interested in verp or mladmin? > > I threw a glance on VERP and think it's indeed quite interesting. There > > are a few days left to get into this topic and there is a lot of > information > > available. > > > > Is Danny Angus the one to whom my application goes? > > > > Greetings, > > Sascha > > > > | > > |> Are there any applications from the years before I can have a look at? > > |> > > |> Is there some student work from the years before I can have a look at? > > | > > | hopefully some other people with longer memories will jump in but > > | there are some examples linked from http://code.google.com/soc/2008/ > > | > > |> My decision to participate this year in Googles Summer of Code was > very > > |> rapid, I hope you don't mind. > > | > > | the timetable for GSOC 2008 is compressed so being rapid is good :-) > > | > > | - robert > > | > > | - > > | To unsubscribe, e-mail: [EMAIL PROTECTED] > > | For additional commands, e-mail: [EMAIL PROTECTED] > > | > > > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.4.8 (MingW32) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > > iEYEARECAAYFAkfoBNQACgkQN1kDpsIDAWGsNgCgnn8G4Y9N/brvNTaGjO9ls55h > > DPsAoLDpoQ5cT/f213BS12E0EHQIn5VX > > =eZAr > > -END PGP SIGNATURE- > > > > >
Re: GSOC 2008
Sascha, You apply to Google, if you are successful I will help you with your project. I understand that the thing to do right now is to watch announcement list, when applications open it will be announced. d. On Mon, Mar 24, 2008 at 7:45 PM, Sascha Fröhlich <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > Robert Burrell Donkin schrieb: > > | On Mon, Mar 24, 2008 at 3:49 PM, Sascha Fröhlich > | <[EMAIL PROTECTED]> wrote: > |> Hi there, > | > | hi > | > |> I would like to apply for Google Summer of Code at the Apache James > |> Project. I'm quite involved with James due to my student work as a > |> software developer so I think it's a good choice to apply here. > | > | cool > | > |> I've got some questions I'd like to ask: > |> > |> I've read the FAQ at http://code.google.com/soc/2008/ and I know > |> basically what I should write in my application. > |> Is there anything you want to know beside this FAQ? > | > | are you interested in verp or mladmin? > I threw a glance on VERP and think it's indeed quite interesting. There > are a few days left to get into this topic and there is a lot of information > available. > > Is Danny Angus the one to whom my application goes? > > Greetings, > Sascha > > | > |> Are there any applications from the years before I can have a look at? > |> > |> Is there some student work from the years before I can have a look at? > | > | hopefully some other people with longer memories will jump in but > | there are some examples linked from http://code.google.com/soc/2008/ > | > |> My decision to participate this year in Googles Summer of Code was very > |> rapid, I hope you don't mind. > | > | the timetable for GSOC 2008 is compressed so being rapid is good :-) > | > | - robert > | > | - > | To unsubscribe, e-mail: [EMAIL PROTECTED] > | For additional commands, e-mail: [EMAIL PROTECTED] > | > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.8 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkfoBNQACgkQN1kDpsIDAWGsNgCgnn8G4Y9N/brvNTaGjO9ls55h > DPsAoLDpoQ5cT/f213BS12E0EHQIn5VX > =eZAr > -END PGP SIGNATURE- > >
Apache James Google Summer of Code 2008
The Apache James team (http://james.apache.org) are pleased to announce that once more we are proposing ideas for Google Summer of Code student projects. This years ideas are: 1) To develop a VERP[1] Mailet to allow James to write VERP modified return addresses on outbound messages, and an inbound mailet/matcher to identify VERP bounces and invoke configurable "do something" code. 2) James' provided mailing list manager is fine for small closed groups, but lacks the functionality of a more robust MLM, the project is to add some all or more of the following features: subscriber and message moderation, double opt-in and bounce handling. We all look forward to welcoming Student proposals for these or any other ideas, and would welcome discussion of the ideas on the James Server Developers mailing list [2]. [1] VERP - http://cr.yp.to/proto/verp.txt [2] James mailing lists - http://james.apache.org/mail.html Danny Angus (PMC Chair Apache James) on behalf of the Apache James Project. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: GSOC?
Done: http://wiki.apache.org/general/SummerOfCode2008#james On Wed, Mar 19, 2008 at 9:15 AM, Danny Angus <[EMAIL PROTECTED]> wrote: > I'm on it *now* :-) > > > > On Tue, Mar 18, 2008 at 2:52 PM, Robert Burrell Donkin > <[EMAIL PROTECTED]> wrote: > > On Mon, Mar 17, 2008 at 5:32 PM, Danny Angus <[EMAIL PROTECTED]> wrote: > > > > > I'm more than happy to do it. > > > VERP is a great idea for gsoc > > > > > > if we want any chance of a GSOC for JAMES, ideas really need to be written > > up right away > > > > - robert > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: GSOC?
I'm on it *now* :-) On Tue, Mar 18, 2008 at 2:52 PM, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > On Mon, Mar 17, 2008 at 5:32 PM, Danny Angus <[EMAIL PROTECTED]> wrote: > > > I'm more than happy to do it. > > VERP is a great idea for gsoc > > > if we want any chance of a GSOC for JAMES, ideas really need to be written > up right away > > - robert > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: GSOC?
I'm more than happy to do it. VERP is a great idea for gsoc On Fri, Mar 14, 2008 at 5:13 PM, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > For the "etc.", add VERP and bounce handling. I've already written and > posted the VERP parser, and can do so again. > > Robert and Danny: are one of you going to do the GSoC work this year, or are > you waiting for someone else to do it? > > --- Noel > > > -Original Message- > From: Norman Maurer [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 13, 2008 2:14 > To: James Developers List > > > Subject: RE: GSOC? > > > +1 > > Norman > > Am Mittwoch, den 12.03.2008, 16:19 -0400 schrieb Noel J. Bergman: > > Enhance the mailing list manager. Add moderation, confirmation, etc. > > > > --- Noel > > > > -Original Message- > > From: Robert Burrell Donkin [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, March 12, 2008 9:44 > > To: James Developers List > > Subject: GSOC? > > > > > > http://wiki.apache.org/general/SummerOfCode2008 > > > > ideas, anyone? > > > > - robert > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Mailet First Steps
+1 +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-837) Case Sensitivity Issue - Verify Identity
[ https://issues.apache.org/jira/browse/JAMES-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572627#action_12572627 ] Danny Angus commented on JAMES-837: --- IMHO this is a defect, While domain names are case insensitive according to their RFC's the local part of addresses are not, per the mail RFC's. However, because James allows non compliant handling of local-parts case-insensitively, sense would tell us that this setting must apply to all uses of the local-part by James. > Case Sensitivity Issue - Verify Identity > > > Key: JAMES-837 > URL: https://issues.apache.org/jira/browse/JAMES-837 > Project: James > Issue Type: Bug >Affects Versions: 2.3.1 > Environment: CentOS 5 >Reporter: Al Stu > > How do I make the verify identity to be case insensitive? > Even if though user name is case insensitive, if user puts in email address > with mixed or upper case, it will not match and rejects the email. > James 3.2.1 on Linux CentOS 5 > SMTP Server Log: > 23/02/08 03:11:50 ERROR smtpserver: User account_name authenticated, however > tried sending email as [EMAIL PROTECTED] > [to:[EMAIL PROTECTED] [from:[EMAIL PROTECTED] > Config.xml: > > > . > . > > > > enableForwarding="true"/> > . > . > > . > . > > . > . > > . > . > > > > true > . > . > > > . > . > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: James Server as a WAR
On Feb 8, 2008 8:27 AM, Jukka Zitting <[EMAIL PROTECTED]> wrote: > From my perspective and use cases I mostly care about James being > modular and easily embeddable. You're not the only one, there are many many use-cases that see James embedded to provide the embedor with high quality adaptable mail functionality. And its seldom talked about for use as front-line mail servers, much more likely is its use in mid tiers to combine email with other channels, for instance in CRM or CMS. In fact before I changed jobs I showed the guys at the old work what you'd done and I think they were going to use it in a new CRM system to combine email with call logs and web chat in the same UI. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: James OSGi Bundle
On Feb 5, 2008 3:09 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > I'm not sure I understand the advantages of the redeploy of a single > processor. Processors are bigger than collections of mailet/matchers, they can invoke one another and can be implemented in different ways, e.g. jsieve. They are in fact "Mail Applications" I've always said (well for several *years* anyway) that we should allow archived processors with their config archived with them in a WAR-like structure to be deployed in James simply by dropping them in. Then you just have to set up a "to processor" rule to have mail handled by the app you've deployed. Get it now? d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: James Server as a WAR
On Feb 7, 2008 12:14 AM, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > That's generally down to laziness, not good architecture. I don't think its fair to characterize the perfectly reasonable desire to minimise the admin overhead of systems, and the size of the skills base required as "laziness", it is in fact a strategy with reduces both cost and risk. Your comment is, if I may say so, "just stupidity". > And it can hamper other things. Not our call to make, its not *my* decision what kind of sys admins, dbas, NOC teams people have in their organisation, what they choose to do is their choice not ours. We should support them by providing options, and, as in this case, even by providing options which are more $$$ than Comp Sci. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: James Server as a WAR
Embeding james in databases is not as silly as you seem to think, Dan Debruner proposed embeding james in derby a couple of years ago. Admins want to run the products they know, and as little else as possible. On 2/6/08, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > Bernd Fondermann wrote: > > > > - The Web container is the wrong container > > One has to get used to it. ;-) > > Oh, please, I spend more time in the web container than you do awake. :-p > > Still doesn't make the web container the right place to embed a fairly heavy > mail server, as opposed to providing a connection from things running in the > Web container to a mail server running elsewhere. > > > > - We should be doing OSGi, not Spring > > +0 for starting a pure OSGi deployment. This is such a massive task, I > > probably have no time to take a major role there. But I will try to > > help where I can. > > Robert's idea of talking with the Felix folks in April makes sense. > > > > - None of this has anything to do with improving JAMES for mainstream > use > > We will see. Tomcat and Jetty are in mainstream use. > > Yes, for Web apps. Hey, why not embed JAMES inside of Oracle and DB2, too? > They're in mainstream use. > > > As I reported recently, the phoenix-deployment is currently broken caused > > by JMS configuration issues. > > Well, it would be nice if whomever broke it, fixed it. > > --- Noel > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Sent from Google Mail for mobile | mobile.google.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: James OSGi Bundle
I agree with noel, processors should be the deployable application On 2/5/08, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > Stefano Bagnara wrote: > > > The really cool thing would be to have each top level component deployable > > as separate osgi bundle, so to be able to undeploy the spool manager, > > alter mailet configuration, deploy it back (and other similar things). > > Mailet configuration seems the wrong place. Pipeline configuration means > configuring processors, which could be the deployable unit. Processors are > the containers for Mailets. Can you make the argument for why Mailets, > themselves, should not be kept simple and far far away from this stuff? > > --- Noel > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Sent from Google Mail for mobile | mobile.google.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: James Server as a WAR
On Feb 3, 2008 9:51 AM, Bernd Fondermann <[EMAIL PROTECTED]> wrote: > What do others think? Long overdue. My opinion in the past was that James should be deployable in a J2EE container but I always envisaged that as EJB's and JCA in an EAR rather than at the WAR level. But if you can do it then great! d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLANNING] Road map - lets find some consensus on .... release contents ....
On Feb 3, 2008 8:20 AM, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > > Yeah. In the sandbox i did this using JMS lookup for services, > > JMS ->JNDI ...? Doh! Yeah, slip of the brain. At my age all acronyms start to merge into one ;-) d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jukka Zitting commit in trunk
.. and FWIW my vote... On Feb 3, 2008 12:09 AM, Danny Angus <[EMAIL PROTECTED]> wrote: [X] +1 I agree that Jukka should be allowed to commit anywhere in James codebase d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Jukka Zitting commit in trunk
Hi, I just want to get this recorded, Jukka is a commiter on this project but has agreed to limit his contribution to the sandbox. If you agree that Jukka's limited agreement to commit only to the sandbox be lifted and it be understood that Jukka is now trusted to commit wherever he feels appropriate please vote accordingly.. [ ] +1 I agree that Jukka should be allowed to commit anywhere in James codebase [ ] 0 I will abide by the majority decision [ ] -1 I disagree, the PMC should debate this case further. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mailets and dependencies (Was: [PLANNING] Road map)
I did the "v3" stuff and the sandbox stuff isn't very different, look at it, I can do it all again. The problems are really only... 1/ some of the interfaces that you need to move to mailet aren't totally normalised, IOW they are a bit hacked to make them work in James not the way you would design them from scratch, and 2/ RemoteDelivery is a total hack right now and needs a) a complete rethink and b) a fully featured implementation of javamail with callbacks (to Listeners messages) from events that occur after they have been queued, possibly upto to several days and several restarts after they enter the outgoing queue. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [modules] Backends
On Feb 2, 2008 11:13 AM, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > i now wonder whether it might be better to aggregate backend classes > according to the technologies they use. so (for example) any backend > code that uses torque would be in a torque-backend module, any code > that uses avalon to store data in a avalon-backend module and so on. > any backend implementations that just use java would be moved into a > base-backend module. I liketo use a pattern that has agnostic API interface module and has technology specific implementations. Then for service X you could have X-torque-impl or X-hibernate-impl etc. You can then also have technology specific shared code, which might be used across the same technology for a number of different module impls and anything that is technology neutral is util code for the API. You kind of get two hierarchies, one functional one technological. Does that make sense in this context? It preserves the "purity" of module splits by function, but also allows for the need to support different technologies in implementation. d. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JCR -> trunk ...?
+1 jcr has some drawbacks (afaik there's still a jackrabbit hard limit of a few thousand docs per node which is too few for a big mail deployment) but IMHO is well worth having in trunk to allow people to experiment. Its an area that has a lot of current interest (with the resurgence of CRM, and all the channel blending that implies, as an IT Big Thing) and IMHO it would be a Good Thing to make it more readily accessable. Whats more I think Jukka did a great job which deserves more visibility. d On Feb 2, 2008 3:42 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: > > i'd like to copy james-jcr into trunk and add some example > > configurations. development can continue in the sandbox (or not) and > > merged in later (if necessary). > > > > any objections? > > > > - robert > > +1 > And I would prefer if development will continue in trunk. If it does not > require big changes to other modules then we don't need a sandbox or a > branch. If instead further development will require experimental changes > to core api then a sandbox or a branch will be more appropriate. > > Stefano > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLANNING] Road map - lets find some consensus on .... release contents ....
On Feb 2, 2008 12:57 PM, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > i agree in principle but trunk has a lot of JAMES-specific mailets > (but i suspect that many of these could be decoupled) Very many of them can. > > i think that it would be a good plan to pull out those mailets which > are conceptually independent into separate a subproject (standard > mailets, say) Agreed, it would be fairly easy to do. > > the problem is that many common problems solved by mailets require > access to basic services Yeah. In the sandbox i did this using JMS lookup for services, and moved several interfaces from JAMES to MAILET to de-couple. There is (was?) a lot of inconsistency around the use of Repository and Store, I favour Store as a interface to a specialised repository lookup because it can be used to provide access to "logical" repositories within a physical store. There's also some design/modelling confusion in the area of users and accounts. > which are environment specific (for example, > delivery to a logical mailbox or access to user information). ATM > mailets are coupled to basic service APIs defined by JAMES. IMHO it > would be better if mailets were decoupled by exposing their own API > interfaces rather than using JAMES service APIs. Yeah, and if you look in the sandbox there's one example of how this can be done. > i agree about extension points but it is the service APIs that worry me > > ATM mailets are coupled to service APIs. some of the service APIs are > reused as extension APIs (which IMHO is not a good idea). so mailets > are coupled to extension APIs which is IMHO not at all good. Agreed, we need to design generic service API's in MAILET which services need to expose for their primary purpose, but also have extension API's which expose management/lifecycle interfaces to allow contributed services to be managed by the container. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: James OSGi Bundle
On Jan 31, 2008 4:13 AM, Bernd Fondermann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> with the release of the OSGi extension to Spring[1], it seems to be
> reasonably easy to turn any spring app into an OSGi deployment ('bundle').
>
> I'd like to try and make the spring deployment OSGi-deployable this way.
>
> In a first step, this would only mean 'deployable'. I would defer
> exposing any interfaces as OSGi services or even splitting James into
> multiple bundles.
>
> Any comments?
+1 I Like it. I must try the spring deployment.
d.
>
>Bernd
>
> [1] http://www.springframework.org/osgi
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLANNING] Road map - lets find some consensus on .... release contents ....
On Jan 24, 2008 10:51 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > I just wanted to say that *all* of our upgrading users have a config.xml > and stored mails to take care upgrading, while a minority have custom > components (I would bet less than 10%, but this is just my personal guess). > > That's why I think config.xml and storage compatibility should be a > greater priority compared to API stability. I agree an upgrade path is a necessity, but it could also include a transform script to migrate files to a new format. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLANNING] Road map - lets find some consensus on .... release contents ....
On Jan 23, 2008 12:13 AM, Steve Brewin <[EMAIL PROTECTED]> wrote: > Would it be possible to further classify Stefano's excellent list of new > functionality in trunk to indicate which rely on none, minor or major API and > schema changes? Then we could evaluate what is the 'low hanging fruit' that > we could most easily harvest for an initial milestone drop. Sounds like a good idea, I'll give it a go. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLANNING] Road map - lets find some consensus on .... release contents ....
> ATM JAMES allows developers to create third party plugins but does not > clearly indicate which APIs are subject to change +1 API's need to be an early target. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLANNING] Road map - lets find some consensus on .... release contents ....
So we're looking for a plan to sort out trunk, with realistic milestones then? The first milestone should be 3.0.0M1 an alpha branch of selected trunk changes for review, but never realistically destined to be the stable 3.0.0? To be followed by successive milestone releases until we have a radically new James architecture. for 3.0.0 Yes/No? d. On Jan 21, 2008 11:10 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Danny Angus ha scritto: > > Hi, > > Roadmap ... we need to do this to give ourselves some direction. > > > > The two questions are "what" we should release and "when" we should release > > it. > > > > I just want to focus on "what" first, we'll look at "when" once we know > > what. > > > > We have two targets, an incremental release of the current live > > version, which we will call "next minor" and the next major release > > from James trunk which we will call "next major" > > Welcome back to the labels ;-) > > > So... > > > > What do *you* want to include in each of these targets? > > 2.3.2: we have no outstanding bugs on 2.3.1, so I don't think we have to > plan a 2.3.2 right now. > > next-minor (2.4 ?): this is Noel field. My opinion is unchanged. IMHO we > should work on trunk because backporting to the old structure IMHO is > too much work and does not make sense. BTW if anyone is willing to work > on this, well, why not: the more we release the better. > > I think a better plan is to try to release at least one milestone from > trunk and depending on the feedback we'll have on the milestones we'll > be able to decide whether it's better to make more milestones from trunk > or it is better to branch for consolidation. > > I don't speak about IMAP (I think Robert will tell us what he thinks > about IMAP modules and their status) but I think most of the other > modules in trunk are ready (since 13 months) for a milestone/alpha/beta > release and they already provide a lot of new features compared to > 2.3.1. Most of the code in trunk should be storage and config.xml > compatible with 2.3.1. > > Unfortunately now I cannot be active as I was 13 months ago when I > proposed to cut a milestone from that code, but this is anyway my > opinion on the code we have. > > Most of our "SNAPSHOT" dependencies have been upgraded to finals in the > past year, now we only have mailet, jsieve and mime4j as snapshot > dependencies. Maybe we should try to cut releases for that products > before trying with Server (but this is not mandatory). > > Stefano > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PLANNING] Road map - lets find some consensus on .... release contents ....
Hi, Roadmap ... we need to do this to give ourselves some direction. The two questions are "what" we should release and "when" we should release it. I just want to focus on "what" first, we'll look at "when" once we know what. We have two targets, an incremental release of the current live version, which we will call "next minor" and the next major release from James trunk which we will call "next major" So... What do *you* want to include in each of these targets? And ... remember that we have had problems with these discussions before, so please lets all think before we speak. I don't mind if we argue over important differences of opinion, but lets listen carefully and try not to argue when we actually agree :-) d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sample MIME messages
The problem would be most acute where the sender has misspelled a real address and the content contains personal or commercial info. Which makes anonymising the data a non-starter too :-( On 12/19/07, Serge Knystautas <[EMAIL PROTECTED]> wrote: > On Dec 18, 2007 4:55 PM, Robert Burrell Donkin > <[EMAIL PROTECTED]> wrote: > > On Dec 18, 2007 9:50 PM, Danny Angus <[EMAIL PROTECTED]> wrote: > > > Serge, is it all spam? Or real messages? I ask because 1.2m real > > > messages would be worth having, but 1.2m bits of spam is probably less > > > representative. > > > > perhaps 1.2m SPAM emails would interest spamassassin > > Yeah, I'm not sure how many are spam and how many aren't. This should > have gotten past the spam filters, but I haven't had a chance to look > through to see how many were bad recipients vs. just random email > addresses. I'll have to look through and dig into it. > > > my main issue was licensing. AIUI the legal status of emails is a grey > > area which i'd like to avoid. > > True... yeah, that is a nasty issue that you've highlighted. > > -- > Serge Knystautas > Lokitech >> software . strategy . design >> http://www.lokitech.com > p. 301.656.5501 > e. [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Sent from Google Mail for mobile | mobile.google.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sample MIME messages
Serge, is it all spam? Or real messages? I ask because 1.2m real messages would be worth having, but 1.2m bits of spam is probably less representative. On 12/17/07, Serge Knystautas <[EMAIL PROTECTED]> wrote: > We have this catchall email account... any email that wasn't addressed > to a correct mailbox was going into it. I had lapsed checking on it, > and it grew out of control. The result is a DVD with 5GB of about 1.2 > million email messages. Robert, you had asked for some sample emails... > would this interest you? > > -- > Serge Knystautas > Lokitech >> software . strategy . design >> http://www.lokitech.com > p. 301.656.5501 > e. [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Sent from Google Mail for mobile | mobile.google.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Users] Split into components
On 11/12/2007, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > this process will inevitably go too far. (IMAP has too many modules.) +1 I've seen this at work too, but it is still a useful way to explode the big ball of mud. > but this is an exercise in comprehension. once the code has been > broken down and the dependencies fixed then we can reaggregate. We can, but I'm betting that by the time we should we won't want to anymore. If the build-test-release cycle is efficient enough there's no real incentive, and it helps stop the ball of mud from reforming. > > > IMHO too many modules is an anti pattern. > > define too many without selecting an arbitrary numeric value :-) Literally? n+1 where n is the optimum number. ;-) (Sorry!) > > i think that JAMES needs to move towards finely grained COP ATM. this > will allow the dependencies to be fixed in an evolutionary manner. +1 we need to expose our internal dependencies, which is where the pain of making changes comes from, so that we can see them clearly and manage them effectively. > IMHO the future for trunk should be pruned releases. experimental and > innovative code should be allowed in trunk without having to convince > people of it's value a priori. first, the APIs are finalised on trunk. > (hence API modules.) before a release, immature modules and general > cruft would be pruned on the release branch. these modules which > didn't make the cut would still be available by compilation of a tag. Sounds like a sensible approach for managing this. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActiveMQ
I agree, but the message body should be a serialised Mail and not a Message to keep things simple. d. On 01/12/2007, Tim Stephenson <[EMAIL PROTECTED]> wrote: > The original and simple idea of using JMS as a means to inject Mail > into James' processors seems good to me, it would open up James to the > JEE audience. I was about to embark on the exact same experiment, so > thanks Robert. > > The source of the message can be the James SMTP service, Fetchmail or > any number of other things and internal Mail processing downstream is > unaffected. This introduces a break between the mail source and the > mail processing, which surely is a good thing? > > rgds, tim > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Users] Split into components
On 29/11/2007, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > i've adopted stefano's suggestion but a longer explanation would be > appreciated +1 I'd like someone to take me through this, if that's OK? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Users] Split into components
... P.S. I like the "Store" entitity because it would allow the mailet API to expose multiple different sets of respositories, but they're (stores & repository access) used inconsistently in James at the moment. And I think we need to be more consistent with some of our abstrations & implementations in this area. Its all a bit philosophical, but I think a good spring-clean of this stuff would reap rewards. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Users] Split into components
On 24/11/2007, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > 1 the granularity of the components is debatable. including user > repositories, stores and virtual user tables together seemed > reasonable to me but perhaps there are better arrangements. This is another area I've been thinking about in relation to mailet, I started trying to model the whole thing, but didn't get far before I got confused! I still think we could do with modelling the whole thing again from 1st principles, even if we come up with the same answer at least we would understand (and have documented) the reasoning a bit better. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [management] 2xVirtualUserTableManagement
On 24/11/2007, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > i'm happy to rename all of them so how about administration for each > interface and administrator for each implementation? +1 Bernd's comment makes sense. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Users] Modularisation
On 24/11/2007, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > after modularisation, the user-api module should contain only basic > interfaces with no coupling to other parts of JAMES or avalon. Cool. I think this needs to go into the mailet API, because mailet is pretty helpless without some knowedge of users, your proposal should make the impact on james little more than a package-name refactoring. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Users] Modularisation
I was going to nick some of the users stuff for mailet at some point, because the API needs users or it can never be complete. Therfore if you could keep this in the back of your mind and don't make the API too Jamesey it might make it easier to derive the mailet users stuff from your work when the time comes, which will make it less painful for James to switch over to using mailet.user . If you see what i mean. d. On 24/11/2007, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > i plan to split the users code out from core-library into an API, > library and implementation modules. please jump in soon if this isn't > convenient right now. > > - robert > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [management] 2xVirtualUserTableManagement
> why not call the implementation VirtualUserTableManager? Aha! Using the power of sematics you have triumphed! :-) Yes, the purpose is "Management" the realisation requires the existence of a "Manager" d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [management] 2xVirtualUserTableManagement
Hi, > Maybe It whould be better to call the Implementation > org.apache.james.management.VirtualUserTableManagementImpl Just my 2c here ... but ... I'm not a big fan of naming implementations with "impl". Why? Well the purpose of an interface is to describe an abstract class if thing or a generalised service, a purpose if you like, and an implementation is a specific realisation of the abstract notion. Therfore I take the view that implementations should be differentiated by their nature, not their purpose. So if you have, for example, a MailBox (interface) and a FileMailBox (impl), or you could differentiate in the package naming e.g. file.MailBox (impl) and service.MailBox (interface). If you can't differentiate between purpose and implementation then I would question whether you really need the interface at all. That will only help this discussion if there are specific characteristics of the implementation. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple matchers per mailet ?
On 22/11/2007, Tim Stephenson <[EMAIL PROTECTED]> wrote: > do you have any comments / advice on if this is a good idea or would > be of any interest within James 3 (or whatever it will be known as)? > if i do go ahead it will only be the mailet container not the > fetchmail, smtp (or other) services which i'd like to be pluggable. Tim its a great idea, subscribe to the mailet-api list. One thing I've wanted to do is to have an independant implementation of the API which we could use as a dev environment for mailets and also to make it easy for folks to add a mailet pipeline to their own applications. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple matchers per mailet ?
I did originally think that a sieve Mailet was the idea. But Steve said it should be an alternative to mailets. If mailets were responsible for matching as well they could use matchers or be sieve without breaking existing config. On 11/21/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > On Nov 21, 2007 5:00 PM, Danny Angus <[EMAIL PROTECTED]> wrote: > > I actually meant instead of mailets altogether, but hey, :-) > > i didn't see this before but blending jsieve with mailets would be > quite powerful > > one use case would be for safe per-user scripting > > - robert > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Sent from Google Mail for mobile | mobile.google.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple matchers per mailet ?
I actually meant instead of mailets altogether, but hey, :-) On 21/11/2007, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > On Nov 21, 2007 1:19 PM, Danny Angus <[EMAIL PROTECTED]> wrote: > > On 21/11/2007, Tim Stephenson <[EMAIL PROTECTED]> wrote: > > > Has anyone ever asked for or considered allowing more than one matcher > > > per mailet? > > > > Yes, we have considered it for inclusion in the next generation of the API. > > > > > a more elegant solution would appear to be to support more than one > > > matcher per mailet, how feasible is that? Any pointers to where i > > > should be looking to implement this would also be appreciated. > > > > You have three choices here > > > > > 3/ use jseive instead > > this is an interesting idea and probably do-able without too much problems > > an extension MailetCommand would need to be developed (for an example, see 1) > > - robert > > 1. > http://svn.apache.org/repos/asf/james/jsieve/trunk/src/main/java/org/apache/jsieve/commands/extensions/Log.java > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple matchers per mailet ?
On 21/11/2007, Tim Stephenson <[EMAIL PROTECTED]> wrote: > Has anyone ever asked for or considered allowing more than one matcher > per mailet? Yes, we have considered it for inclusion in the next generation of the API. > a more elegant solution would appear to be to support more than one > matcher per mailet, how feasible is that? Any pointers to where i > should be looking to implement this would also be appreciated. You have three choices here 1/ implement a matcher which takes as its argument a script of some sort, I've always thought that javascript using rhino (http://www.mozilla.org/rhino/) would be easy, you can just expose the Mail as an object to the javascript, and the script would traverse the mail much like a script in a browser traverses the DOM. Its surprisingly easy to use rhino to expose scriptable objects and run scripts against them once you get over the initial learning curve. Your matcher would have an object which would contain a property for the response and a property for the Mail and expose this to the script, the script would look at the Mail and update the response. When it finished the matcher would return the response from the scripted object. or 2/ change the way James reads the mailet configuration and assembles the pipeline. Possibly not for the faint hearted. or 3/ use jseive instead - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jira bulk update closed issues
Hi, I suppressed the 200 emails jira wanted to send. I've closed all the issues marked "fixed" in released versions. If they are reported again they can always be reopened. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VERSIONS] next-minor is now 2.3.2 and next-major is 3.0
I've also added 2.3.3 in case anyone wants to bump issues out beyond 2.3.2. d. On 20/11/2007, Danny Angus <[EMAIL PROTECTED]> wrote: > I've merged next-minor with 2.3.2, the combined milestone has 6 > unresolved issues. > > I've also renamed next-major to 3.0 which has 16 unresolved issues. > > d. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VERSIONS] next-minor is now 2.3.2 and next-major is 3.0
I've merged next-minor with 2.3.2, the combined milestone has 6 unresolved issues. I've also renamed next-major to 3.0 which has 16 unresolved issues. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JAMES-812) Fix JIRA versions. next-minor and next-major do not have anymore meaning.
[ https://issues.apache.org/jira/browse/JAMES-812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Angus resolved JAMES-812. --- Resolution: Fixed Fix Version/s: (was: Trunk) Merged next-minor with 2.3.2 > Fix JIRA versions. next-minor and next-major do not have anymore meaning. > - > > Key: JAMES-812 > URL: https://issues.apache.org/jira/browse/JAMES-812 > Project: James > Issue Type: Task >Affects Versions: 2.3.2, 3.0, Trunk >Reporter: Stefano Bagnara > Assignee: Danny Angus > Fix For: 2.3.2, 3.0 > > > Since we voted to rename the version from next-major to 3.0-SNAPSHOT the JIRA > version should be updated according to that vote. > next-minor and next-major should be removed forever as the vote where they > was introduced has been "invalidated". > Please fix this: mixing old and new names is even worse than not having a > name/version at all. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JAMES-770) Exception when runnning JAMES with run.sh
[ https://issues.apache.org/jira/browse/JAMES-770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Angus updated JAMES-770: -- Fix Version/s: (was: 2.2.0) Next Minor > Exception when runnning JAMES with run.sh > - > > Key: JAMES-770 > URL: https://issues.apache.org/jira/browse/JAMES-770 > Project: James > Issue Type: Bug >Affects Versions: 2.3.0 > Environment: windows, cygwin >Reporter: maximeloridan > Fix For: Next Minor > > Attachments: james.jpg > > > Open cygwin > then type directly: "D:/James-2.3.0/bin/run.sh" (this is where my james 2.3.0 > is installed) > The result is: ClassNotFoundException (see the top of the picture) > Actually, we have to set first a directory by typing : "cd D:" (see the > middle of the picture) and then launch JAMES (see the bottom of the picture). > In this case, it will work > NB: I test it with JAMES-2.2.0, and this problem does not appear. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (JAMES-812) Fix JIRA versions. next-minor and next-major do not have anymore meaning.
That makes sense to me. I'll make the changes. d. On 20/11/2007, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Danny Angus (JIRA) ha scritto: > > [ > > https://issues.apache.org/jira/browse/JAMES-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543887 > > ] > > > > Danny Angus commented on JAMES-812: > > --- > > > > Should the version in JIRA be 3.0 or 3.0-SNAPSHOT ? > > > > if the major version is 3.0, then subsequent minor versions will be 3.0.x > > > > If it is 3.0-SNAPSHOT then presumably that would cover any unreleased > > version of 3.0? > > > > Comments? > > > IMHO it depends on how we intend to use JIRA. > > I'm used to use real product release versions as labels. > > So, I'd name it "3.0". When we'll be ready for 3.0b1 (or something > similar) we rename 3.0 to 3.0b1 and then we create a new 3.0 where we > move evey issue we don't plan to fix for 3.0b1. > > Stefano > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Close resolved issues in released versions
Hi, I'd like to close all resolved issues which refer to a version that has been released. Any objections? d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Proposal Bulk close Fixed issues
Looking at JIRA today I see that 244 issues were reported by a member of "james developers" and are assigned to another member of the group and are marked as "fixed". The vast majority, but not all, of these are also assigned to the reporter. I'd like to propose that issues we have reported ourselves and are marked fixed are all moved to closed. Issues can be reopened if necessary. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (JAMES-812) Fix JIRA versions. next-minor and next-major do not have anymore meaning.
[ https://issues.apache.org/jira/browse/JAMES-812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Angus reassigned JAMES-812: - Assignee: Danny Angus > Fix JIRA versions. next-minor and next-major do not have anymore meaning. > - > > Key: JAMES-812 > URL: https://issues.apache.org/jira/browse/JAMES-812 > Project: James > Issue Type: Task >Affects Versions: Next Minor, Next Major, Trunk >Reporter: Stefano Bagnara > Assignee: Danny Angus > Fix For: Next Minor, Next Major, Trunk > > > Since we voted to rename the version from next-major to 3.0-SNAPSHOT the JIRA > version should be updated according to that vote. > next-minor and next-major should be removed forever as the vote where they > was introduced has been "invalidated". > Please fix this: mixing old and new names is even worse than not having a > name/version at all. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-812) Fix JIRA versions. next-minor and next-major do not have anymore meaning.
[ https://issues.apache.org/jira/browse/JAMES-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543887 ] Danny Angus commented on JAMES-812: --- Should the version in JIRA be 3.0 or 3.0-SNAPSHOT ? if the major version is 3.0, then subsequent minor versions will be 3.0.x If it is 3.0-SNAPSHOT then presumably that would cover any unreleased version of 3.0? Comments? > Fix JIRA versions. next-minor and next-major do not have anymore meaning. > - > > Key: JAMES-812 > URL: https://issues.apache.org/jira/browse/JAMES-812 > Project: James > Issue Type: Task >Affects Versions: Next Minor, Next Major, Trunk >Reporter: Stefano Bagnara > Fix For: Next Minor, Next Major, Trunk > > > Since we voted to rename the version from next-major to 3.0-SNAPSHOT the JIRA > version should be updated according to that vote. > next-minor and next-major should be removed forever as the vote where they > was introduced has been "invalidated". > Please fix this: mixing old and new names is even worse than not having a > name/version at all. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ApacheCon Atlanta: anyone?
On 10/11/2007, Andoni OConchubhair <[EMAIL PROTECTED]> wrote: > I was wondering if anyone else from this list is going. I'd be > very interested in meeting with some of you and finding out how you use > James. Noel will be there, sadly I've had to pull out this year. I'm not sure who else might be going. > I also have aspirations towards one day doing some Open Source > development, though I am told that despite email being my area in > professional life, I should start with a project that is only starting > out rather than a developed project like James. I completely disagree, working on an established and mature project can teach you a lot about how open source projects work, and there will be people with experience there to help you when you get stuck. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JAMES-828) Create a rules engine matcher
[ https://issues.apache.org/jira/browse/JAMES-828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Angus updated JAMES-828: -- Description: A rules engine matcher would be configured with rules and invoke a rules engine. A wrapper delegating to a JSR-94 [1] compliant rules engine could probably be written fairly easily. [1]http://java.sun.com/developer/technicalArticles/J2SE/JavaRule.html was:A rules engine matcher would be configured with rules and invoke a rules engine. A wrapper delegating to ahttp://java.sun.com/developer/technicalArticles/J2SE/JavaRule.html";>JSR 94 compliant rules engine could probably be written fairly easily. > Create a rules engine matcher > -- > > Key: JAMES-828 > URL: https://issues.apache.org/jira/browse/JAMES-828 > Project: James > Issue Type: New Feature > Components: Matchers/Mailets (bundled) >Reporter: Danny Angus >Priority: Minor > > A rules engine matcher would be configured with rules and invoke a rules > engine. A wrapper delegating to a JSR-94 [1] compliant rules engine could > probably be written fairly easily. > [1]http://java.sun.com/developer/technicalArticles/J2SE/JavaRule.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JAMES-828) Create a rules engine matcher
Create a rules engine matcher -- Key: JAMES-828 URL: https://issues.apache.org/jira/browse/JAMES-828 Project: James Issue Type: New Feature Components: Matchers/Mailets (bundled) Reporter: Danny Angus Priority: Minor A rules engine matcher would be configured with rules and invoke a rules engine. A wrapper delegating to ahttp://java.sun.com/developer/technicalArticles/J2SE/JavaRule.html";>JSR 94 compliant rules engine could probably be written fairly easily. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (JAMES-827) More fault resistent version of MBoxMailRepository
[ https://issues.apache.org/jira/browse/JAMES-827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Angus reassigned JAMES-827: - Assignee: Danny Angus > More fault resistent version of MBoxMailRepository > -- > > Key: JAMES-827 > URL: https://issues.apache.org/jira/browse/JAMES-827 > Project: James > Issue Type: Improvement > Components: MailStore & MailRepository >Affects Versions: 2.3.1 >Reporter: Jason Hunter >Assignee: Danny Angus > Attachments: MLMBoxMailRepository.java > > > Per my earlier email http://markmail.org/message/qaxrmtdzdf6fvbwu > I wrote my own MboxMailRepository to be a bit more fault resistent: > * Reports exceptions if the mbox dir isn't there. > * Closes files in finally block. > * Nicely exceptions out if no disk space. > * Ensures "envsender" in From line is one word. > It's write-only but perhaps the code can be helpful. > -jh- > P.S. Where's the file upload? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Users] Add support for user meta-data? [WAS Re: [MailboxAPI] Delete]
... sorry, which all means that I prefer Serialisable get(user,key) d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [MailboxAPI] Factories Factories Factories
On 06/11/2007, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > I think that we need to revisit the whole area. I don't consider much of > the code in the trunk more than experimental directions that various people > went in without much rhyme, reason or discussion. And I have no difficulty > at all with the idea of punting most of the crap out of trunk. In that case we should be replacing it with something which has been designed to fit requirements. > Personally, I could argue for standardizing on a single implementation based > on JCR, and providing import and/or export support for various formats, such > as our current file-based and db-based format, maildir and mbox. I'd rather we abstracted, I think the interchangeable implementations are one of James' strengths. Paradoxically if we hadn't had that then it wouldn't have been possible for Jukka to build the JCR POC so easily, and we'd probably still be thinking that it would be neat to try. > Likewise, I'd be just as happy to move to and standardize on a user > repository based on LDAP, using ApacheDS by default and able to plug into > other LDAP systems. I am a bit less concerned about this area, though. The > only place where I feel that LDAP offers a value to us is with user > credentials (e.g., SMTP AUTH and/or S/MIME certificates). I think standardising on LDAP is probably a sensible pragmatic approach as every man and his dog seems happy to use LDAP these days. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Users] Add support for user meta-data? [WAS Re: [MailboxAPI] Delete]
On 06/11/2007, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > Zsombor suggests object storage. ... > (not sure i have a strong preference) > > opinions? There are two approaches, and they are mutually exclusive, they are.. 1/ Start from a strongly typed and controlled structure (like "UserMetaData") and extend it with each new use-case. This approach might help to mitigate upgrade compatibility issues, but has an analysis and design overhead. 2/ The other approach would be to go for the most general, which is anything Serializable, and leave upgrade compatibility in the hands of the gods. I would tend to come down on the side of 2/ because I'm not convinced that we can justify the amount of engineering involved in 1, and I already like the relaxed approach that servlet session has. You can build rigour on top of a loose framework but not the other way around. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [MailboxAPI] Factories Factories Factories
On 06/11/2007, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > I think that when you store a message into a mailbox (LocalDelivery) you > don't have a real user, unless we introduce a "Spooler" or "Remote" user > to be used in that use case (I don't like it too much). Oh I see. Hmmm, no I don't like the sound if that much either. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [MailboxAPI] Factories Factories Factories
On 06/11/2007, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > i think that this probably means that user information is going to > need to be passed in (if anyone can see good alternatives, please jump > in). I don't think that it needs to be a problem, is there a use case of a mailbox without a user? d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
