date:20060526


I've noticed we have/are rapidly added/ing many "subprojects" to
James.  The term "subproject" is something of a loaded term at Apache,
so wanted to a) have group discuss how they see these as related and
b) be intentional in the term we're using.

1. How these code bases are related
My 2 cents... these are code bases with separate code bases, separate
(but hopefully similar) build processes, separate (but visually
similar) websites.  For me, the most important issue is that we have
only one committer base across all these.  i.e., we're not going to
add someone exclusively to mime4j or postage.

2. Intentional with terms we're using
Here are some sample terms...

subproject - jakarta terminology
project - xml.apache.org's terminology
plugin - maven.apache.org's terminology
module - ?
codebase - ?

Others?

What do you think?

--
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]

Re: [VOTE] Create Postage project


On 5/26/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:

- create the svn folder james/postage (including trunk/tags/branches
folders),
- import the current code at http://issues.apache.org/jira/browse/JAMES-442
- create a JIRA subproject named POSTAGE

+1


+0 only because I have no time to look at the code.  It all sounds
reasonable based on the comments.

I have a follow-up email on terminology coming soon.

--
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]

Re: Virtual User Tables


On 5/26/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:

Sendmail merges aliases, virtualusertable, users entries to fill in a
single map for the matching.

We can't do this because we have mailets.


Sure, I just wanted to bring up the idea.

Maybe a flag (per hostname) to say whether to be rigorous on what
recipients you accept?  So maybe @notices.lokitech.com can receive any
random recipient, but I'm only going to accept @lokitech.com only if
it's in a user table?

I don't know... I always thought this made it easier for spammers to
figure out who to send to, but I guess they don't care about what
would require more programming.  You guys know better whether this
direction has any merit in it.

--
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]

Re: [VOTE] Create Postage project

2006-05-26 Thread Bernd Fondermann


Stefano Bagnara wrote:
- create the svn folder james/postage (including trunk/tags/branches 
folders),

- import the current code at http://issues.apache.org/jira/browse/JAMES-442
- create a JIRA subproject named POSTAGE



+1

  Bernd

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Create Postage project

Am Freitag, den 26.05.2006, 17:12 +0200 schrieb Stefano Bagnara:
> - create the svn folder james/postage (including trunk/tags/branches 
> folders),
> - import the current code at http://issues.apache.org/jira/browse/JAMES-442
> - create a JIRA subproject named POSTAGE
> 
> +1
> 
> Stefano

+1
Norman


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

[VOTE] Create Postage project

- create the svn folder james/postage (including trunk/tags/branches 
folders),

- import the current code at http://issues.apache.org/jira/browse/JAMES-442
- create a JIRA subproject named POSTAGE

+1

Stefano


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Postage's future


Bernd Fondermann wrote:

Possible solutions I can think of are...
o go on patching JAMES-442, don't change anything right now


+0


o move to a svn-sandbox, allow for more review, feedback and tests


+0.5


o make it a subproject


+1

o merge into James Server codebase (option: hold on until mvn2 
modularization is in effect)


-1 (even if we introduce modules Postage doesn't belong to James Server, 
imho)



o move to JMeter


Well, I think that JMeter will have much more requirements for Postage 
to be included in its repository. At least it would share a common 
infrastructure with JMeter and probably they will not like the James 
dependencies. Btw this is not an option I can vote on.


I'd favor "subproject", at least as a mid-term perspective. If I 
understand correctly, this would require PMC attention.


I'm starting a vote for this.

Stefano


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Postage's future

Im fully agree. Making this a subproject whould make the most sense to
me. And yes you are right for create a subproject we must vote.

bye
Norman

Am Freitag, den 26.05.2006, 16:49 +0200 schrieb Bernd Fondermann:
> Hi,
> 
> Over the last weeks I have tested different JAMES versions and 
> configurations using Postage. This way, I found one or two bugs in the 
> Server. I am quite happy with it and for me it is already an 
> indispensable tool when working on James.
> 
> On the current status, see a prev thread: 
> http://mail-archives.apache.org/mod_mbox/james-server-dev/200605.mbox/[EMAIL 
> PROTECTED]
> 
> I think it's time now to move the codebase (which is attached to 
> JAMES-442) to someplace else to eventually grow sufficent community and 
> utilization around it.
> 
> Possible solutions I can think of are...
> o go on patching JAMES-442, don't change anything right now
> o move to a svn-sandbox, allow for more review, feedback and tests
> o make it a subproject
> o merge into James Server codebase (option: hold on until mvn2 
> modularization is in effect)
> o move to JMeter
> 
> I'd favor "subproject", at least as a mid-term perspective. If I 
> understand correctly, this would require PMC attention.
> 
> What do the others think?
> 
>Bernd



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Postage's future

2006-05-26 Thread Bernd Fondermann


Hi,

Over the last weeks I have tested different JAMES versions and 
configurations using Postage. This way, I found one or two bugs in the 
Server. I am quite happy with it and for me it is already an 
indispensable tool when working on James.


On the current status, see a prev thread: 
http://mail-archives.apache.org/mod_mbox/james-server-dev/200605.mbox/[EMAIL PROTECTED]


I think it's time now to move the codebase (which is attached to 
JAMES-442) to someplace else to eventually grow sufficent community and 
utilization around it.


Possible solutions I can think of are...
o go on patching JAMES-442, don't change anything right now
o move to a svn-sandbox, allow for more review, feedback and tests
o make it a subproject
o merge into James Server codebase (option: hold on until mvn2 
modularization is in effect)

o move to JMeter

I'd favor "subproject", at least as a mid-term perspective. If I 
understand correctly, this would require PMC attention.


What do the others think?

  Bernd


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Virtual User Tables

Am Freitag, den 26.05.2006, 15:02 +0200 schrieb Stefano Bagnara:
> Serge Knystautas wrote:
> > On 5/26/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> >> Is what you propose a service like:
> >>
> >> public class RewritingService {
> >> public MailAddress[] rewrite(MailAddress address);
> >> }
> > 
> > Just to throw it out there... one thing that makes sendmail rather
> > strong is that since it's aliases are quite structured, it can know
> > (and thus reject during SMTP protocol) recipients that it cannot
> > handle for authoritative domain.  So perhaps add both a rewrite() and
> > a handles() method?
> 
> Sendmail merges aliases, virtualusertable, users entries to fill in a 
> single map for the matching.
> 
> We can't do this because we have mailets.
> 
> Let's say I have this mailet as my first mailet:
> 
>   ..repository infos..
> 
> 
> In the SMTPHandler we are not able to understand that the mailet will 
> introduce some sort of whitelist for particular senders.
> 
> If we want to provide full fastfailing to the SMTPHandler we ask the 
> users to move much of their logic from Mailets processed by the 
> SpoolManager to Handlers processed by the SMTPServer.
> 
> I could also have mailets that allow only specific combinations of 
> sender/recipients and so on.
> 
> So we can support facilities for site administrators to manually insert 
> "filters" in the SMTPhandler to fastfail, but we'll never automagically 
> do that if we don't remove the Mailet support.
> 
> A middle step would be the "in-handler" processor: add a processor that 
> is executed after the data is closed (as a MessageHandler) that simply 
> run a full Processor (defined in the handler configuration, with it's 
> own spoolrepository) and if the message is GHOSTED consider it a 
> succesfull delivery, if the message is sent to ERROR it can reply an 
> SMTP error to the data.
> 
> SMTP specifications says that a similar process should take a small 
> amount of time (to avoid duplicate send).
> 
> This would not give us fastfail at MAIL or RCPT commands but would give 
> an administrator one more level of control.
> 
> Stefan

Hmm, i don't think that do such tinks after the data is accepted is the
right way. I often hat issues with remote servers that did such thinks
and so my mailserver thought we lost the connection cause it get no
answer for long time on high load. The data should be accepted as fast /
soon as possible.
But i understand the problem we have with the current mailet and matcher
support. But anyway we should try to find a better fastfail support.

bye
Norman



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Virtual User Tables


Serge Knystautas wrote:

On 5/26/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:

Is what you propose a service like:

public class RewritingService {
public MailAddress[] rewrite(MailAddress address);
}


Just to throw it out there... one thing that makes sendmail rather
strong is that since it's aliases are quite structured, it can know
(and thus reject during SMTP protocol) recipients that it cannot
handle for authoritative domain.  So perhaps add both a rewrite() and
a handles() method?


Sendmail merges aliases, virtualusertable, users entries to fill in a 
single map for the matching.


We can't do this because we have mailets.

Let's say I have this mailet as my first mailet:

 ..repository infos..


In the SMTPHandler we are not able to understand that the mailet will 
introduce some sort of whitelist for particular senders.


If we want to provide full fastfailing to the SMTPHandler we ask the 
users to move much of their logic from Mailets processed by the 
SpoolManager to Handlers processed by the SMTPServer.


I could also have mailets that allow only specific combinations of 
sender/recipients and so on.


So we can support facilities for site administrators to manually insert 
"filters" in the SMTPhandler to fastfail, but we'll never automagically 
do that if we don't remove the Mailet support.


A middle step would be the "in-handler" processor: add a processor that 
is executed after the data is closed (as a MessageHandler) that simply 
run a full Processor (defined in the handler configuration, with it's 
own spoolrepository) and if the message is GHOSTED consider it a 
succesfull delivery, if the message is sent to ERROR it can reply an 
SMTP error to the data.


SMTP specifications says that a similar process should take a small 
amount of time (to avoid duplicate send).


This would not give us fastfail at MAIL or RCPT commands but would give 
an administrator one more level of control.


Stefano


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven2 opinions


Bernd Fondermann wrote:
Having no real project experience with maven2 I'm nevertheless impressed 
how highly modularized projects using maven2 build & test.


The Postage build is tightly dependend on James, since the code is 
dependend on a few parts of James. It includes james-2.3-dev.jar (or 
another version of it) and a few other jars from /lib.
So this is a situation where one project depends on the artefacts of 
another project which I'd expect to be much easier to handle using maven2.


We should probably split james in many modules, so you can add only 
small part of James as dependency for postage.


You could also have postage splitted in 2 modules: the main module not 
depending on James and the secondary module that contains the james 
integration.


Btw I think that we should proceed by steps.

Also Maven2 has its own problems, mostly related to the shared 
repositories and we'll probably hit that problems one day, but I think 
the features we get from m2 worth this problems.


Stefano


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven2 opinions


Søren Hilmer wrote:
I am a +1 for Maven. 
I believe that Maven greatly simplifies build, test, documentation. 
Of course you have to buy it's POM, but I do not consider that to be a major 
drawback, since it is close to what we got and is well designed.
It is my opinion that if you try to bend your own POM to Maven instead of 
adopting Maven's POM you are in for a bumpy ride, and in that case I would be 
-1 on the subject.


--Søren


Hi Søren,

Just to be sure I understood your comment when you say "POM" you mean 
the SDL ?


If I understood your message you are +1 to change our current layout to 
match the default maven2 layout and have a simple pom.xml because we 
"refactor" our repository to match the maven2 standard.
You are instead -1 to introduce maven2 as a complicate pom.xml that 
override every default to match our current build model.


Is this correct or is this the opposite of your thought?

Stefano

PS: I think that SDL (Standard Directory Layout) is one of the best 
thing introduced by the maven project. When I look to new projects using 
the SDL I feel home, I understand much more thing at a glance than what 
I understand from non SDL projects.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Virtual User Tables

2006-05-26 Thread Noel J. Bergman

Serge Knystautas wrote:

> one thing that makes sendmail rather strong is that since
> it's aliases are quite structured, it can know (and thus
> reject during SMTP protocol) recipients that it cannot
> handle for authoritative domain.  So perhaps add both a
> rewrite() and a handles() method?

Something like that, yes.  We have the same notion in our scheme, except
that it currently results in delivery notices, since we can't do it
in-protocol.

--- Noel

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Virtual User Tables


On 5/26/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:

Is what you propose a service like:

public class RewritingService {
public MailAddress[] rewrite(MailAddress address);
}


Just to throw it out there... one thing that makes sendmail rather
strong is that since it's aliases are quite structured, it can know
(and thus reject during SMTP protocol) recipients that it cannot
handle for authoritative domain.  So perhaps add both a rewrite() and
a handles() method?

--
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]

Re: Virtual Users, Aliases and Forwards

On 5/26/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:

Serge Knystautas wrote:
> I didn't have anything to do with the user repositories. :)  I think
> James is lacking on a lot of what I consider basic mailbox features...

Can you name a few features you miss? (I just want to be sure I
understood the right features)

Obviously we don't have to support all of these... this is out of the
commercial IMAP server I use:
- Real name
- password
- created date
- encryption
- use external authentication
- mailbox (size) quota
- mailbox (count) quota
- delay new mail if X% full
- send alert if X% full
- send notice if X% full
- aliases
- mail processing rules (I guess like jSieve)
- vacation message
- fetchmail (configured for each user, rather than at server-level)
- pending alerts

There are actually a bunch of other ones since you can control the
webmail interface, but those aren't really relevant given our current
scope.

There are defaults for all of these at the server and domain level, so
for the most part on an individual user you can pick a specific value
or use the default.

--
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]

Re: Maven2 opinions

2006-05-26 Thread Bernd Fondermann

Having no real project experience with maven2 I'm nevertheless impressed
how highly modularized projects using maven2 build & test.

The Postage build is tightly dependend on James, since the code is
dependend on a few parts of James. It includes james-2.3-dev.jar (or
another version of it) and a few other jars from /lib.
So this is a situation where one project depends on the artefacts of
another project which I'd expect to be much easier to handle using maven2.

CI would be another important step ahead for the James project
infrastructure.

I am cautiously +1.

Bernd

Stefano Bagnara wrote:
I was writing this to ask Noel for some more explanations about why he
doesn't like Maven2, but I'd like to know the opinion of all committers
about this.

What is your opinion about switching our build system to maven2 ?

I'm +0.5 for the following reasons:

1. using a "standard" directory layout simplify the use of third party
tools

2. At least Eclipse and maybe even IDEA and NetBeans have a maven2
plugin that simplify the import/configuration of a maven2 project.

3. We can try to remove libraries from our repository

4. It will allow us to split James in subprojects: mailet-api,
mailet-impl, core, smtp, pop3, nntp, fetchmail, mailets, spoolmanager
having well-defined dependencies between modules. This will improve the
self-documentation provided by james sourcecode (it makes much more
clear the modules and the dependencies) and maybe a step towards OSGi
bundles.

5. It simplify the integration in continuous integrations environments.

6. It should be easier to create a website integrating James Server and
our subprojects (jSPF, jSieve, Mime4J, Postage).

I know we can achieve some of the tasks even not using Maven2: in this
case I would like to know what you propose as an alternative.

About the "website skin" if anyone does not like the maven2 default skins:
Stylus: http://maven.apache.org/
Default: http://www.mime4j.org/
We can even write our own skin to match as close as possible the current
james style.

I would also like to know what is the opinion about the usage of the
Standard Directory Layout
(http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html)
and the splitting of James in modules.

Can we do the latter without switching to Maven2 ?

Stefano

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven2 opinions

2006-05-26 Thread Søren Hilmer

I am a +1 for Maven. 
I believe that Maven greatly simplifies build, test, documentation. 
Of course you have to buy it's POM, but I do not consider that to be a major 
drawback, since it is close to what we got and is well designed.
It is my opinion that if you try to bend your own POM to Maven instead of 
adopting Maven's POM you are in for a bumpy ride, and in that case I would be 
-1 on the subject.

--Søren

On Wednesday 24 May 2006 11:58, Stefano Bagnara wrote:
> I was writing this to ask Noel for some more explanations about why he
> doesn't like Maven2, but I'd like to know the opinion of all committers
> about this.
>
> What is your opinion about switching our build system to maven2 ?
>
> I'm +0.5 for the following reasons:
>
> 1. using a "standard" directory layout simplify the use of third party
> tools
>
> 2. At least Eclipse and maybe even IDEA and NetBeans have a maven2
> plugin that simplify the import/configuration of a maven2 project.
>
> 3. We can try to remove libraries from our repository
>
> 4. It will allow us to split James in subprojects: mailet-api,
> mailet-impl, core, smtp, pop3, nntp, fetchmail, mailets, spoolmanager
> having well-defined dependencies between modules. This will improve the
> self-documentation provided by james sourcecode (it makes much more
> clear the modules and the dependencies) and maybe a step towards OSGi
> bundles.
>
> 5. It simplify the integration in continuous integrations environments.
>
> 6. It should be easier to create a website integrating James Server and
> our subprojects (jSPF, jSieve, Mime4J, Postage).
>
> I know we can achieve some of the tasks even not using Maven2: in this
> case I would like to know what you propose as an alternative.
>
> About the "website skin" if anyone does not like the maven2 default skins:
> Stylus: http://maven.apache.org/
> Default: http://www.mime4j.org/
> We can even write our own skin to match as close as possible the current
> james style.
>
> I would also like to know what is the opinion about the usage of the
> Standard Directory Layout
> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-d
>irectory-layout.html) and the splitting of James in modules.
>
> Can we do the latter without switching to Maven2 ?
>
> Stefano
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-- 
Søren Hilmer, M.Sc., M.Crypt.
wideTrail   Phone:  +45 25481225
Pilevænget 41   Email:  [EMAIL PROTECTED]
DK-8961  Allingåbro Web:www.widetrail.dk

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Help needed for jSPF & Gump


I would like to add jspf to Gump but I have no idea about where to start.

I think I have to write something similar to:


  Apache James jSPF library
  http://james.apache.org/jspf/"/>



  

  

  











  



Maybe we also have to change our pom.xml to be @@DATE@@ aware, I don't 
know how, also...


Is there a place where to test such descriptor?

If I understood the final place is 
https://svn.apache.org/repos/asf/gump/metadata/project, right? And I 
don't have permissions on that folder...


Any hint is welcome!

Thank you,
Stefano

http://issues.apache.org/jira/browse/JSPF-8


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (JAMES-508) Make MailetContext.isLocalUser domain aware

2006-05-26 Thread Stefano Bagnara (JIRA)

 [ http://issues.apache.org/jira/browse/JAMES-508?page=all ]
 
Stefano Bagnara resolved JAMES-508:
---

Resolution: Fixed

> Make MailetContext.isLocalUser domain aware
> ---
>
>  Key: JAMES-508
>  URL: http://issues.apache.org/jira/browse/JAMES-508
>  Project: James
> Type: Improvement

>   Components: James Core
> Reporter: Stefano Bagnara
> Assignee: Stefano Bagnara
>  Fix For: 2.4.0

>
> Trying to resume an old task:
> Currently we run MailetContext.isLocalServer(domain) and in the following
> call MailetContext.isLocalUser(local-part).
> Having 2 different calls does not allow us to check users associated to a
> specific domain.
> The proposed solution is:
> 1) change the isLocalUser documentation saying that you MUST provide the
> full email address
> 2) eventually allowing to use names without @ (the system will consider
> automatically @localhost)
> This would replace the current client code:
> mailetContext.isLocalServer(recipient.getHost()) &&
> mailetContext.isLocalUser(recipient.getUser())
> With 
> mailetContext.isLocalEmail(recipient)
> IMHO this is a good improvement over the current API way to resolve local
> users (double call) and this would allow us to implement automatic
> virtualhosting support.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (JAMES-509) Cleanup/Refactor FetchMail code

2006-05-26 Thread Stefano Bagnara (JIRA)

 [ http://issues.apache.org/jira/browse/JAMES-509?page=all ]

Stefano Bagnara updated JAMES-509:
--

Attachment: fetchmail-refactoring2

This is an updated version. Not too much differences from the previous, but I 
did it, so I think it is better to talk about the latest.

> Cleanup/Refactor FetchMail code
> ---
>
>  Key: JAMES-509
>  URL: http://issues.apache.org/jira/browse/JAMES-509
>  Project: James
> Type: Improvement

>   Components: FetchMail
> Versions: 2.4.0
> Reporter: Stefano Bagnara
> Assignee: Stefano Bagnara
>  Fix For: 2.4.0
>  Attachments: fetchmail-refactoring1, fetchmail-refactoring2
>
> Current FetchMail code is really hard to read and manage.
> I loose too much time looking around its code to understand how things works.
> So I put my hands in, and applied a few refactoring.
> I already removed 2200 lines of code (50Kbytes of code) while keeping the 
> same functionality (only refactorings).
> Of course refactorings like this are not always an easy change: I also remove 
> the StoreProcessor/FolderProcessor/MessageProcessor granular creation by 
> refactoring them to top level reentrant objects that take things to process 
> as arguments to their "process" method.
> MessageProcessor is still a mess, but I think this is more selfdocumenting 
> than before.
> I can clean up things much more and update documentation and so on, but I 
> would like to know if this kind of update is welcome or not, before loosing 
> too much time.
> Stefano

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (JAMES-509) Cleanup/Refactor FetchMail code

2006-05-26 Thread Joachim Draeger (JIRA)

[ 
http://issues.apache.org/jira/browse/JAMES-509?page=comments#action_12413407 ] 

Joachim Draeger commented on JAMES-509:
---


I haven't had my hands in the fetchmail code so I only can do a fast review. 
And the patch makes sense to me. For example there are getters an setters for 
variables only used locally in one method. If you don't have them local you 
always have to check for references and side effects when reading that code. 
IMHO it looks a bit over-designed to me. 


> Cleanup/Refactor FetchMail code
> ---
>
>  Key: JAMES-509
>  URL: http://issues.apache.org/jira/browse/JAMES-509
>  Project: James
> Type: Improvement

>   Components: FetchMail
> Versions: 2.4.0
> Reporter: Stefano Bagnara
> Assignee: Stefano Bagnara
>  Fix For: 2.4.0
>  Attachments: fetchmail-refactoring1
>
> Current FetchMail code is really hard to read and manage.
> I loose too much time looking around its code to understand how things works.
> So I put my hands in, and applied a few refactoring.
> I already removed 2200 lines of code (50Kbytes of code) while keeping the 
> same functionality (only refactorings).
> Of course refactorings like this are not always an easy change: I also remove 
> the StoreProcessor/FolderProcessor/MessageProcessor granular creation by 
> refactoring them to top level reentrant objects that take things to process 
> as arguments to their "process" method.
> MessageProcessor is still a mess, but I think this is more selfdocumenting 
> than before.
> I can clean up things much more and update documentation and so on, but I 
> would like to know if this kind of update is welcome or not, before loosing 
> too much time.
> Stefano

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Commented: (JAMES-509) Cleanup/Refactor FetchMail code

2006-05-26 Thread Joachim Draeger

Steve Brewin (JIRA) schrieb:

For me, this is a prime example of why people have said we need to discuss
first, achieve consensus, then act.

There is a patch, that we can discuss. If it makes sense it should be
included.

I'm afraid I don't understand why this wasn't discussed first on the lists. Is
it something we need to do? What is the motivation for such a major
refactoring? We all know that major changes are prone to creating new issues.
What functional issues are being solved? Are they of sufficient importance to
outweigh the risk of destabilisation such a radical change engenders? What
additional features are provided?

The argument for change seems to be "Current FetchMail code is really hard to read and
manage". Others have commented how well structured it is (I don't have time to look up the
references). This is a matter of style. I'm biased as I refactored the original code into the
structure you see now and added a heap of functionally. I don't want to get into an argument about
style or how virtuous having "removed 2200 lines of code (50Kbytes of code)" is.

I think that the changes are so radical that we are in effect replacing the current implementation of fetchmail and need to ask why? Unlike when I refactored it, it isn't broken and no new features are added so we are not satisfying any user requirements.

In making these changes, without even a safety net of unit tests, we are
destabilising a component for no more than a matter of style. To me, this
doesn't seem wise. There are no obvious benefits that outweigh the risks.

I think saving time is a very serious argument. This is my own
experience: Sometimes there are components which aren't subject of big
changes but you always have to go through of them and maybe make small
changes. And when the code is hard to read and hard to understand it
costs a lot of time. At the end you could have rewrite it from scratch
and you would have saved much time and that means a lot of money in the
commercial world. Sometimes I do this step and refactor/rewrite and
sometimes I am annoyed that I haven't done it. Yes it can be reasonable
touching code without bringing features for the end user.
Of course there are risks and it has to be discussed that things don't
get worse. So demanding unit tests maybe an argument. On the other hand
keeping hard to manage code is a risk, too, because it is error-prone
when you have to do changes.
Time isn't money in the open source world although time of volunteers it
the most valuably. We should not waste it.

I haven't had my hands in the fetchmail code so I only can do a fast
review. And the patch makes sense to me. For example there are getters
an setters for variables only used locally in one method. If you don't
have them local you always have to check for references and side effects
when reading that code. IMHO it looks a bit over-designed to me.

Joachim

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Updated: (JAMES-509) Cleanup/Refactor FetchMail code


Stefano Bagnara wrote:
To me it's something like obfuscated: I feel worst than browsing 
decompiled code ;-)


And here is the pratical example:

Take this code:

-

/**
 * Answer if aMessage has been SEEN.
 * @param aMessage
 * @return boolean
 * @throws MessagingException
 */
protected boolean isSeen(MimeMessage aMessage) throws MessagingException
{
boolean isSeen = false;
if (isMarkSeenPermanent().booleanValue())
isSeen = aMessage.isSet(Flags.Flag.SEEN);
else
isSeen = handleMarkSeenNotPermanent(aMessage);
return isSeen;
}

/**
 * Answer the result of computing markSeenPermanent.
 * @return Boolean
 */
protected Boolean computeMarkSeenPermanent()
{
return new Boolean(
getFolder().getPermanentFlags().contains(Flags.Flag.SEEN));
}

/**
 * Handler for when the folder does not support the SEEN flag.
 * The default behaviour implemented here is to answer the value of the
 * SEEN flag anyway.
 *
 * Subclasses may choose to override this method and implement their own
 *  solutions.
 *
 * @param aMessage
 * @return boolean
 * @throws MessagingException
 */
protected boolean handleMarkSeenNotPermanent(MimeMessage aMessage)
throws MessagingException
{
return aMessage.isSet(Flags.Flag.SEEN);
}

/**
 * Returns the isMarkSeenPermanent.
 * @return Boolean
 */
protected Boolean isMarkSeenPermanent()
{
Boolean markSeenPermanent = null;
if (null == (markSeenPermanent = isMarkSeenPermanentBasic()))
{
updateMarkSeenPermanent();
return isMarkSeenPermanent();
}
return markSeenPermanent;
}

/**
 * Returns the markSeenPermanent.
 * @return Boolean
 */
private Boolean isMarkSeenPermanentBasic()
{
return fieldMarkSeenPermanent;
}

/**
 * Sets the markSeenPermanent.
 * @param markSeenPermanent The isMarkSeenPermanent to set
 */
protected void setMarkSeenPermanent(Boolean markSeenPermanent)
{
fieldMarkSeenPermanent = markSeenPermanent;
}

/**
 * Updates the markSeenPermanent.
 */
protected void updateMarkSeenPermanent()
{
setMarkSeenPermanent(computeMarkSeenPermanent());
}


---

The only method used from the remaining FetchMail code is isSeen.

How much long does it take to understand the you can replace the whole 
thing with:


--

protected boolean isSeen(MimeMessage aMessage) throws MessagingException {
return aMessage.isSet(Flags.Flag.SEEN);
}

--

!??!?

I can't find any good reason to keep the old code: One could say that 
this is a facility for subclasses, but I think that we shouldn't 
obfuscate our classes to provide facilities to subclasses.
In fact you can do anything you can do in the original code also in my 
refactored code (isSeen is protected).



This is just an example to make more clear why I loose to much time on 
that code and I think it should be changed, even at the code of 
introduce a few bugs we can anyway fix.


Stefano


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Virtual User Tables

Am Freitag, den 26.05.2006, 09:42 +0200 schrieb Stefano Bagnara:
> Noel J. Bergman wrote:
> > Actually, the virtual user code is just about what it ought to be, although
> > what I proposed earlier would be a useful change.  A few discussions that
> > haven't been implemented are largely because some people just don't
> > understand how SMTP and POP3 work.  For example, the POP3 RFC says:
> > 
> >   USER name
> > Arguments:
> >   a string identifying a mailbox (required), which is of
> >   significance ONLY to the server
> > 
> > It need *NOT* be the user's e-mail address.  We could look at expanding the
> > range of possible mailbox identifiers, but there is no need.
> 
> I agree: in fact we currently don't use the email address but tha name 
> of the mailbox (often the localpart of the email address).
> 
> I also think that we should at least support a "fullemail" accounts 
> option. This would be without configuration and would allow to create 
> users using the full email address and check their mail separately using 
> "USER fullemail" via POP3. I would have lost much less hours replying to 
> users of this list if we had a component or a configuration for this 
> easy to understand, easy to implement scenario.
> 
> But you know I don't like features themselves, I instead prefer to 
> refactor the code and to expose services that allow us to modularize an 
> aspect... [continue...]
> 
> > This is not the problem with JAMES-426.  The issue with JAMES-426 is that it
> > neither takes into account that we can have non-JDBC virtual tables, nor the
> > fact that we can have multiple virtual user tables.  If implemented, it
> > would, at best, be a temporary solution for a sub-set of users.
> > 
> > Exposing a virtual user mapping service, and then querying that service,
> > would resolve both issues.
> > 
> > --- Noel
> 
> About http://issues.apache.org/jira/browse/JAMES-426 I assigned it to 
> me, and I explained that I don't like the proposed solution itself, and 
> I started working on a modular way to implement it. My first comment 
> explain the first part of the refactoring.
> 
> Btw isLocalUser does not (and will never do) take in consideration the 
> whole spooling and the possible AbstractVirtualUserTable, 
> AbstractRedirect, AbstractNotify, ToRepository and any other mailet that 
> allow to do something locally even with an email address not associated 
> to a local user.
> 
> This is in part related to the fastfailing for rcpts just proposed by 
> Norman: Imho we can add that handler, but it should be optional, and 
> should be carefully described that the handler is not aware of the full 
> processing but of the only virtualuser table.
> 
> Unfortunately you don't know if an email address is valid or not until 
> you process the full processors/matchers/mailets.
> I agree we should modularize and move to top level service the most 
> important mailet services (like the virtusertable you propose).
> 
> Stefano

Sure the rcphandler should be optional. I could write an Handler which
check for existens and use the setBlockListed(true) and
setBlockListedDetail() for this needs. Emails on invalid recipients
increase the traffic and blacklists like spamcop often block servers
which accept email for not valid recipients and send bounces after that.

So if someone want to use this feature he must put this emailaddress
which is used on Matchers in the special table. But it should also be
possible to lookup for local recipients via isLocalEmail() method and
reject recipients which not valid after isLocalEmail() address is
checked and the special table.

Thats just my thoughts.

bye
Norman


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

svn commit: r409588 - in /james/server/trunk/src: java/org/apache/james/ java/org/apache/james/transport/matchers/ java/org/apache/mailet/ test/org/apache/james/test/mock/mailet/

2006-05-26 Thread bago

Author: bago
Date: Fri May 26 01:35:29 2006
New Revision: 409588

URL: http://svn.apache.org/viewvc?rev=409588&view=rev
Log:
Renamed MailetContext.isLocalUser(MailAddress) to isLocalEmail (JAMES-508)

Modified:
james/server/trunk/src/java/org/apache/james/James.java

james/server/trunk/src/java/org/apache/james/transport/matchers/AbstractStorageQuota.java

james/server/trunk/src/java/org/apache/james/transport/matchers/RecipientIsLocal.java
james/server/trunk/src/java/org/apache/mailet/MailetContext.java

james/server/trunk/src/test/org/apache/james/test/mock/mailet/MockMailContext.java

Modified: james/server/trunk/src/java/org/apache/james/James.java
URL: 
http://svn.apache.org/viewvc/james/server/trunk/src/java/org/apache/james/James.java?rev=409588&r1=409587&r2=409588&view=diff
==
--- james/server/trunk/src/java/org/apache/james/James.java (original)
+++ james/server/trunk/src/java/org/apache/james/James.java Fri May 26 01:35:29 
2006
@@ -715,9 +715,9 @@
 }
 try {
 if (name.indexOf("@") == -1) {
-return isLocalUser(new MailAddress(name,"localhost"));
+return isLocalEmail(new MailAddress(name,"localhost"));
 } else {
-return isLocalUser(new MailAddress(name));
+return isLocalEmail(new MailAddress(name));
 }
 } catch (ParseException e) {
 log("Error checking isLocalUser for user "+name);
@@ -726,9 +726,9 @@
 }
 
 /**
- * @see 
org.apache.mailet.MailetContext#isLocalUser(org.apache.mailet.MailAddress)
+ * @see 
org.apache.mailet.MailetContext#isLocalEmail(org.apache.mailet.MailAddress)
  */
-public boolean isLocalUser(MailAddress mailAddress) {
+public boolean isLocalEmail(MailAddress mailAddress) {
 if (!isLocalServer(mailAddress.getHost())) {
 return false;
 }

Modified: 
james/server/trunk/src/java/org/apache/james/transport/matchers/AbstractStorageQuota.java
URL: 
http://svn.apache.org/viewvc/james/server/trunk/src/java/org/apache/james/transport/matchers/AbstractStorageQuota.java?rev=409588&r1=409587&r2=409588&view=diff
==
--- 
james/server/trunk/src/java/org/apache/james/transport/matchers/AbstractStorageQuota.java
 (original)
+++ 
james/server/trunk/src/java/org/apache/james/transport/matchers/AbstractStorageQuota.java
 Fri May 26 01:35:29 2006
@@ -81,7 +81,7 @@
  */
 protected boolean isRecipientChecked(MailAddress recipient) throws 
MessagingException {
 MailetContext mailetContext = getMailetContext();
-return super.isRecipientChecked(recipient) && 
(mailetContext.isLocalUser(recipient));
+return super.isRecipientChecked(recipient) && 
(mailetContext.isLocalEmail(recipient));
 }
 
 /** 

Modified: 
james/server/trunk/src/java/org/apache/james/transport/matchers/RecipientIsLocal.java
URL: 
http://svn.apache.org/viewvc/james/server/trunk/src/java/org/apache/james/transport/matchers/RecipientIsLocal.java?rev=409588&r1=409587&r2=409588&view=diff
==
--- 
james/server/trunk/src/java/org/apache/james/transport/matchers/RecipientIsLocal.java
 (original)
+++ 
james/server/trunk/src/java/org/apache/james/transport/matchers/RecipientIsLocal.java
 Fri May 26 01:35:29 2006
@@ -29,6 +29,6 @@
 public boolean matchRecipient(MailAddress recipient) {
 MailetContext mailetContext = getMailetContext();
 //This might change after startup
-return mailetContext.isLocalUser(recipient);
+return mailetContext.isLocalEmail(recipient);
 }
 }

Modified: james/server/trunk/src/java/org/apache/mailet/MailetContext.java
URL: 
http://svn.apache.org/viewvc/james/server/trunk/src/java/org/apache/mailet/MailetContext.java?rev=409588&r1=409587&r2=409588&view=diff
==
--- james/server/trunk/src/java/org/apache/mailet/MailetContext.java (original)
+++ james/server/trunk/src/java/org/apache/mailet/MailetContext.java Fri May 26 
01:35:29 2006
@@ -147,7 +147,7 @@
  * @param userAccount - user identifier.
  * @return true if the acount is a local account
  * 
- * @deprecated use isLocalUser(MailAddress) instead
+ * @deprecated use isLocalEmail(MailAddress) instead
  * 
  * @since James 2.4.0 this method expect to receive also the domain
  * name within the userAccount string ([EMAIL PROTECTED]).
@@ -163,7 +163,7 @@
  * 
  * @since James 2.4.0
  */
-boolean isLocalUser(MailAddress mailAddress);
+boolean isLocalEmail(MailAddress mailAddress);
 
 /**
  * Writes the specified message to a mailet log file, usually an event

Modified: 
james/server/trunk/src/test/org/apache/james/test/mock/mai

Re: Virtual User Tables


Sorry Noel,

After a second read I understand you're proposing something new 
(different). I'm just a bit bored of too much discussions and no code 
(did you notice this? ;-) ) that I undervalued your statements.


Is what you propose a service like:

public class RewritingService {
public MailAddress[] rewrite(MailAddress address);
}

or even:

public class RewritingService {
public MailAddress[] rewrite(MailAddress[] addresses);
}

The last give us more option to optimize, but less control.
At a first thought I prefer the first.

Furthermore, if we use a single rewrite per james instance we can create 
a service and a top level component, otherwise we should create a store 
for named rewriting services.


Our JamesUsersRepository would provide both services: UsersRepository 
and RewritingService (for the aliasing forwarding stuff).


Stefano

Noel J. Bergman wrote:

Stefano Bagnara wrote:


Noel J. Bergman wrote:

That requires a bit of thought, rather than rushing into coding



I have lost the count of discussions with no end, with no conclusions



I'm sure I can find discussions about virtual users at least 3 years old


Actually, the virtual user code is just about what it ought to be, although
what I proposed earlier would be a useful change.  A few discussions that
haven't been implemented are largely because some people just don't
understand how SMTP and POP3 work.  For example, the POP3 RFC says:

  USER name
Arguments:
  a string identifying a mailbox (required), which is of
  significance ONLY to the server

It need *NOT* be the user's e-mail address.  We could look at expanding the
range of possible mailbox identifiers, but there is no need.

This is not the problem with JAMES-426.  The issue with JAMES-426 is that it
neither takes into account that we can have non-JDBC virtual tables, nor the
fact that we can have multiple virtual user tables.  If implemented, it
would, at best, be a temporary solution for a sub-set of users.

Exposing a virtual user mapping service, and then querying that service,
would resolve both issues.

--- Noel


-
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: Virtual Users, Aliases and Forwards


Noel J. Bergman wrote:

Serge,

What did you have in mind when implementing forward and alias as part of the
user repository record?  Just the "obvious"?  And why both?  I'd like some
concept of what you had in mind.

I am asking because when we revise user repositories, I am wondering if we
should discard those in favor of further integration with the virtual user
mapping.

--- Noel


The current aliasing/forwarding implemented in the our 
JamesUsersRepository is like a virtusertable applied just before the 
local persistence. I splitted LocalDelivery in 
UsersRepositoryAliasingForwarding and ToMultiRepository because I 
thought it was too much hardcoded in James.
ToMultiRepository is the real LocalDelivery, while 
UsersRepositoryAliasingForwarding is an email rewriting service (like 
the virtusertable) and should be modularized.


What would you like? To create a service for the "email rewriters" and 
configure the services as top level components, used by the mailets and 
anyone else?


Stefano


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Virtual Users, Aliases and Forwards


Serge Knystautas wrote:

I didn't have anything to do with the user repositories. :)  I think
James is lacking on a lot of what I consider basic mailbox features...


Can you name a few features you miss? (I just want to be sure I 
understood the right features)


Stefano


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Virtual User Tables


Noel J. Bergman wrote:

Actually, the virtual user code is just about what it ought to be, although
what I proposed earlier would be a useful change.  A few discussions that
haven't been implemented are largely because some people just don't
understand how SMTP and POP3 work.  For example, the POP3 RFC says:

  USER name
Arguments:
  a string identifying a mailbox (required), which is of
  significance ONLY to the server

It need *NOT* be the user's e-mail address.  We could look at expanding the
range of possible mailbox identifiers, but there is no need.


I agree: in fact we currently don't use the email address but tha name 
of the mailbox (often the localpart of the email address).


I also think that we should at least support a "fullemail" accounts 
option. This would be without configuration and would allow to create 
users using the full email address and check their mail separately using 
"USER fullemail" via POP3. I would have lost much less hours replying to 
users of this list if we had a component or a configuration for this 
easy to understand, easy to implement scenario.


But you know I don't like features themselves, I instead prefer to 
refactor the code and to expose services that allow us to modularize an 
aspect... [continue...]



This is not the problem with JAMES-426.  The issue with JAMES-426 is that it
neither takes into account that we can have non-JDBC virtual tables, nor the
fact that we can have multiple virtual user tables.  If implemented, it
would, at best, be a temporary solution for a sub-set of users.

Exposing a virtual user mapping service, and then querying that service,
would resolve both issues.

--- Noel


About http://issues.apache.org/jira/browse/JAMES-426 I assigned it to 
me, and I explained that I don't like the proposed solution itself, and 
I started working on a modular way to implement it. My first comment 
explain the first part of the refactoring.


Btw isLocalUser does not (and will never do) take in consideration the 
whole spooling and the possible AbstractVirtualUserTable, 
AbstractRedirect, AbstractNotify, ToRepository and any other mailet that 
allow to do something locally even with an email address not associated 
to a local user.


This is in part related to the fastfailing for rcpts just proposed by 
Norman: Imho we can add that handler, but it should be optional, and 
should be carefully described that the handler is not aware of the full 
processing but of the only virtualuser table.


Unfortunately you don't know if an email address is valid or not until 
you process the full processors/matchers/mailets.
I agree we should modularize and move to top level service the most 
important mailet services (like the virtusertable you propose).


Stefano


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Commented: (JAMES-511) Add quota support for mailboxes

Whe i wrote that i thought about diffrent qouta per user etc. I thought
about a "addquota username quota" in the remoteManager.

bye
Norman
 
Am Freitag, den 26.05.2006, 07:35 + schrieb Vincenzo Gianferrari
Pini (JIRA):
> [ 
> http://issues.apache.org/jira/browse/JAMES-511?page=comments#action_12413389 
> ] 
> 
> Vincenzo Gianferrari Pini commented on JAMES-511:
> -
> 
> What about the available AbstractQuotaMatcher, AbstractStorageQuota and 
> RecipientIsOverFixedQuota matchers?
> 
> > Add quota support for mailboxes
> > ---
> >
> >  Key: JAMES-511
> >  URL: http://issues.apache.org/jira/browse/JAMES-511
> >  Project: James
> > Type: New Feature
> 
> >   Components: MailStore & MailRepository
> > Reporter: Norman Maurer
> 
> >
> > We should add the support of quotas
> 


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

[jira] Commented: (JAMES-511) Add quota support for mailboxes

2006-05-26 Thread Vincenzo Gianferrari Pini (JIRA)

[ 
http://issues.apache.org/jira/browse/JAMES-511?page=comments#action_12413389 ] 

Vincenzo Gianferrari Pini commented on JAMES-511:
-

What about the available AbstractQuotaMatcher, AbstractStorageQuota and 
RecipientIsOverFixedQuota matchers?

> Add quota support for mailboxes
> ---
>
>  Key: JAMES-511
>  URL: http://issues.apache.org/jira/browse/JAMES-511
>  Project: James
> Type: New Feature

>   Components: MailStore & MailRepository
> Reporter: Norman Maurer

>
> We should add the support of quotas

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Virtual User Tables

Am Donnerstag, den 25.05.2006, 18:47 -0400 schrieb Noel J. Bergman:
> Norman commented:
> 
> > a modular virtual hosting support whould be a really nice thing.
> > The current way the virtual user table support is not the best.
> 
> In what way?  Actually, I would say that the current virtual user table code
> is in pretty good shape, and is very powerful.  The major thing that I would
> do is factor out the virtual user table code to make it a service that can
> be used by other components in the system.  That way we can check to see if
> I particular user would have a valid mapping, and if the mapping would be
> local.
> 
> That requires a bit of thought, rather than rushing into coding, because we
> can configure multiple virtual user tables, implying that any client of the
> service would need to make sure that the desired mapping was being applied.
> 
>   --- Noel

This exactly why i start this issue. I want to hear other thoughts etc.
Maybe its just me who not like the current handling ;-)

bye
Norman


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

[jira] Created: (JAMES-511) Add quota support for mailboxes

2006-05-26 Thread Norman Maurer (JIRA)

Add quota support for mailboxes
---

 Key: JAMES-511
 URL: http://issues.apache.org/jira/browse/JAMES-511
 Project: James
Type: New Feature

  Components: MailStore & MailRepository  
Reporter: Norman Maurer


We should add the support of quotas

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Virtual Users, Aliases and Forwards