Hi guys,
as you (hopefully) all know the current Quota code is very ineffectiv
and can cause many problems when using JDBC based mailrepository.
See:
http://issues.apache.org/jira/browse/JAMES-717
http://issues.apache.org/jira/browse/JAMES-718
For me there are 2 possible solutions at the moment
I just reread my message and notice that my answer is a bit confusing :-(
Here is what i tried to say:
I agree that we should follow the way how the XMLVirtualUserTable work.
If we really want to add a check in the mailet for local domain then we
should use the mailetContext.isLocalServer(String)
Hi,
first i think all of the needed information are allready provided in the
bounce.
But if he really want todo diffrent things on diffrent bounce message he
could check the exception message which get thrown if the mail could not
delivert. See exceptionToLogString method in RemoteDelivery (trunk)
Author: norman
Date: Sun Dec 17 22:56:42 2006
New Revision: 488141
URL: http://svn.apache.org/viewvc?view=rev&rev=488141
Log:
Add comment for mail.smtp.localhost option. See JAMES-735
Modified:
james/server/branches/v2.3/src/conf/james-config.xml
Modified: james/server/branches/v2.3/src/conf
Author: norman
Date: Sun Dec 17 22:54:58 2006
New Revision: 488140
URL: http://svn.apache.org/viewvc?view=rev&rev=488140
Log:
Add comment for mail.smtp.localhost option. See JAMES-735
Modified:
james/server/trunk/src/conf/james-config.xml
Modified: james/server/trunk/src/conf/james-config.xm
Author: norman
Date: Sun Dec 17 22:51:21 2006
New Revision: 488138
URL: http://svn.apache.org/viewvc?view=rev&rev=488138
Log:
Revert fix i commited for heloname usage in RemoteDelivery. This fix is not
needed cause its possible to set the heloname with
some.host.name . Backport needed
changes f
Author: norman
Date: Sun Dec 17 22:48:12 2006
New Revision: 488136
URL: http://svn.apache.org/viewvc?view=rev&rev=488136
Log:
Revert fix i commited for heloname usage in RemoteDelivery. This fix is not
needed cause its possible to set the heloname with
some.host.name (Thx Stefano for
reporting)
I just reviewed. It makes really more sense. I will revert and backport
the other change.
bye
Norman
Stefano Bagnara schrieb:
> -0
>
> In trunk we already have the option to use:
> some.host.name
> inside the RemoteDelivery.
> So this patch simply add another way to do the same thing.
>
> If you
Stefano Bagnara schrieb:
> Looking at the virtualusertable query I see that if I only add the rule
> user=bago
> domain=%
> [EMAIL PROTECTED]
>
> It will never alias any recipient: neither [EMAIL PROTECTED] nor
> [EMAIL PROTECTED]
>
> If I instead add another generic mapping referring to the domain
Mornin,
i will review the stuff again. Thx for reporting ;-)
bye
Norman
Stefano Bagnara schrieb:
> -1 for 2 reasons:
>
> 1) I explained in reply to r487278 that in trunk we already had a
> solution that required no code changes, so I think we should backport
> that one and not r487278.
>
> 2) Th
Joachim Draeger wrote:
> 1. Backport features from trunk to 2.3 branch (AKA next-minor)
> 2. Create a config/storage compatible release from trunk (AKA next-major)
> 3. Work on a non-compatible release from trunk (AKA next-greater)
Why only one?
We should (and should have already) released v2.3.
Noel J. Bergman wrote:
> I would have put out JAMES 2.3.1 over a month ago were it not for
> obstructions. JAMES 2.3.0 has a critical defect that I fixed, but
> Stefano vetoed the change
This is a statement of fact, not an accusation, nor an implication of
anything other than the fact. Nor shou
> > 1. Backport features from trunk to 2.3 branch (AKA next-minor):
> +0 I see no need for such a release. If we want to make a release
> soon then we should release a 2.3.1 with only should contain bugfixes.
I would have put out JAMES 2.3.1 over a month ago were it not for
obstructions. JAMES 2.
I think you should wait, wait that previous vetoes are resolved.
We could even make all the backport for 2.3.1 when we decide that we
really want to (need to) do a 2.3.1.
Imho if someone thinks we are ready for 2.3.1 please post a list of
patch you think should be backported to 2.3 to make th
-1 for 2 reasons:
1) I explained in reply to r487278 that in trunk we already had a
solution that required no code changes, so I think we should backport
that one and not r487278.
2) The previous commit to v2.3 received a veto from me. I think we
should at least resolve a veto before backpor
-0
In trunk we already have the option to use:
some.host.name
inside the RemoteDelivery.
So this patch simply add another way to do the same thing.
If you think this helloName deserve more attention then imho we should
better add a comment about the configuration option.
Stefano
[EMAIL PROT
Looking at the virtualusertable query I see that if I only add the rule
user=bago
domain=%
[EMAIL PROTECTED]
It will never alias any recipient: neither [EMAIL PROTECTED] nor
[EMAIL PROTECTED]
If I instead add another generic mapping referring to the domain like:
user=nonexistinguser
domain=som
robert burrell donkin wrote:
JAMES is a complex, mature application but now contains many youthful
components. perhaps these new components would benefit from a quicker
release cycle than the main application.
perhaps it might be worth considering decoupling the spring support
from the normal ja
Bernd Fondermann wrote:
For the next release I would like to
+ have basic (whatever than means) IMAP stable, perfoming and
functional, and well integrated with the rest of James architecture.
+ have more online management and monitoring features done
+ have a Spring distribution besides the other
Joachim Draeger wrote:
Hi all,
Because something went wrong I think we need a cut and a complete restart of
discussion / collecting opinions. Because I suppose everything has already been
said, it should be possible to finish this part soon.
AFAIK there have only been mentioned three different
Am Sonntag, den 17.12.2006, 09:32 +0100 schrieb Joachim Draeger:
> 1. Backport features from trunk to 2.3 branch (AKA next-minor)
> - this includes only backporting and testing, a release may be done
>very soon
This is possibly the safest way of releasing a few features very quickly
From: [EMAIL PROTECTED]
Subject: Ich bin nicht im Büro - I am not in the office
English Version below...
Sehr geehrter Geschäftspartner,
ich bin vom 04.12.2006 bis einschließlich 15.12.2006 nicht im Büro. In
dringenden Fällen erreichen Sie meinen Kollegen Jürgen Hoffmann telefonisch
unter der
MBoxMailRepository can't parse mboxrd files
Key: JAMES-744
URL: http://issues.apache.org/jira/browse/JAMES-744
Project: James
Issue Type: Bug
Components: MailStore & MailRepository
Hi Joachim,
here are my VOTES (?) :-)
1. Backport features from trunk to 2.3 branch (AKA next-minor):
+0 I see no need for such a release. If we want to make a release soon then we
should release a 2.3.1 with only should contain bugfixes.
2. Create a config/storage compatible release from tru
Hi all,
Because something went wrong I think we need a cut and a complete restart of
discussion / collecting opinions. Because I suppose everything has already been
said, it should be possible to finish this part soon.
AFAIK there have only been mentioned three different possibilities:
1. Backp
25 matches
Mail list logo
