Both Outlook and Outlook Express do support it.
Vincenzo
-Original Message-
From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
Sent: mercoledi 29 ottobre 2003 0.01
To: James Developers List
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: RE: [proposal] Doco
Changes from previous patch:
i) All accept methods in SpoolRepository and implementing classes now returns
a Mail instance instead of the key (should that have been MailImpl instances
?)
ii) JamesSpoolManager changed as it calls one of the accept method mentioned
above.
iii) For performance
Really the biggest hurdle is a stable Avalon release. :)
I would use the latest release packages from Avalon, and once we get merged,
I think it makes sense for Stephen to add configuration files for a James
package using Merlin as well as our Phoenix packaging.
--- Noel
Noel J. Bergman wrote:
Really the biggest hurdle is a stable Avalon release. :)
I would use the latest release packages from Avalon, and once we get merged,
I think it makes sense for Stephen to add configuration files for a James
package using Merlin as well as our Phoenix packaging.
So to just
Serge Knystautas wrote:
Noel J. Bergman wrote:
Really the biggest hurdle is a stable Avalon release. :)
I would use the latest release packages from Avalon, and once we get
merged,
I think it makes sense for Stephen to add configuration files for a
James
package using Merlin as well as our
I nominate Steve Brewin as a James Committer. Steve contributed quite a bit
of work on Fetchmail, provided the original impetus behind the use of XML
entities to simplify out configuration file(s), has other pending
contributions (e.g., BSF integration), helps out on the user list, has been
easy
I nominate Soren Hilmer as a James Committer. Soren has contributed several
significant changes (Mail Attribiutes and RemoteDelivery scheduling) , has
been easy to collaborate with, and generally appears to know his stuff.
I'll start off with a +1.
--- Noel
2. Discuss and resolve the mailet API changes.
I propose we abandon many of the changes made to the HEAD, and adopt only
those changes made to the branch as well.
The repository access and database access is likely to be superceded by
JNDI.
I propose that we keep whatever additional
Everything from Avalon on which James is dependent has gone though an
official release.
Your list (Freudian slip? :-)) is missing Phoenix, although I believe that
there is a release later than we are using.
I assume that all of the new ones are currently in our MAIN branch?
James is
So to just get to a merged 3.0 release, we could do the following
Are you proposing that what is currently v2.2.0 test builds be released as
v3?
1. Move to latest release packages from Avalon.
I think that we already have them in the MAIN branch. If not, we should.
Steve is running James
+1 also from me!
Vincenzo
-Original Message-
From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
Sent: mercoledi 29 ottobre 2003 17.35
To: James-Dev Mailing List
Subject: [VOTE] Steve Brewin
I nominate Steve Brewin as a James Committer. Steve contributed
quite a bit
of work on
+1 also from me!
Vincenzo
-Original Message-
From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
Sent: mercoledi 29 ottobre 2003 17.35
To: James-Dev Mailing List
Subject: [VOTE] Soren Hilmer for Committer
I nominate Soren Hilmer as a James Committer. Soren has
contributed
Noel J. Bergman wrote:
So to just get to a merged 3.0 release, we could do the following
Are you proposing that what is currently v2.2.0 test builds be released as
v3?
Err, no... I mean merge from a codebase perspective, not overwrite.
Feature-wise, I don't believe there is much in 3.0 that isn't
Serge Knystautas wrote:
I think that will be messy since there has been so much changes on
each, but I don't have a better suggestion. grunt grunt grunt.
This really could expose our Archiles heel though, which is a lack of
adequate testing to make sure the merged version works well. Have
I think it causes more trouble then benefit if it delays a mail for not
less
then 5 days _without_ notifying the sender after 24 hours, saying that I
am
James, your email is delayed, but I am still trying to deliver.
I understand your thought about DSN (something still pending to be done),
but
So to just get to a merged 3.0 release, we could do the following
Are you proposing that what is currently v2.2.0 test builds be
released as v3?
Err, no... I mean merge from a codebase perspective, not overwrite.
Feature-wise, I don't believe there is much in 3.0 that isn't in 2.2.
IMAP.
Noel J. Bergman wrote:
As for formal testing, we still don't have much. Bench and live testing,
basically. For example, when I get home, I'll test Soren's patch by setting
up a schedule, and sending mail to a dead gateway. I don't know what Avalon
has done in terms of facilitating component
I am not against this patch, actually this was one of the most important
missing features for me. The current configuration is better in one (and
only one) issue, it does provide feedback after about a day to the sender.
I have no idea about the implementation of DSN, but sending bounces to a
2. Do an api/impl split (which will make me happy)
Where do you see that we don't? I'm not saying that there aren't such
cases, but I'm curious as to what you see as concerns.
3. Use the AbstractMerlinTestCase to deploy james in a container with
services accessible to your unit test - you
Excalibur IO is depricated in favour of Commons IO. However, the
cornerstone-store package used a number of IO utilities not available
within the commons-io package
So we need commons-io, plus the additional set of classes necessary to
support Cornerstone Store, and you've moved the latter
(on bounces I also mean failed attempts, before the configured retry attemps
ended, this event could be used for such a notification)
- Original Message -
From: Hontvari Jozsef [EMAIL PROTECTED]
To: James Developers List [EMAIL PROTECTED]
Sent: Wednesday, October 29, 2003 9:43 PM
Can you fill me in on BSF?
I'm not Steve, but ...
http://jakarta.apache.org/bsf/
Also:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
.orgmsgNo=9147
That has a BSF matcher and a BSF mailet written by Steve. We want to get
them into v3.
In terms of what I'm proposing, think of
I am not against this patch, actually this was one of the most important
missing features for me. The current configuration is better in one (and
only one) issue, it does provide feedback after about a day to the sender.
Actually, the feedback is when it fails. If you want total failure, you
This is a small patch which makes possible to specify a reversePath in
descendant classes. Until now postmaster was used always and the bounces got
on my nerves :)
It is against the 2.1 branch.
-
To unsubscribe, e-mail: [EMAIL
Now again in zip.
- Original Message -
From: Hontvari Jozsef [EMAIL PROTECTED]
To: James Developers List [EMAIL PROTECTED]
Sent: Wednesday, October 29, 2003 10:38 PM
Subject: [PATCH] GenericListServ, reversePath can be specified
This is a small patch which makes possible to specify a
Hi all,
I'm still setting up my new server and I'm trying to deploy a custom
mailet to it, but running into problems.
I following the directions here:
http://james.apache.org/custom_mailet_2_1.html
I copied my jar into /usr/local/james-server/lib and executed:
cd /usr/local/james-server
cp
Noel J. Bergman wrote:
Can you fill me in on BSF?
I'm not Steve, but ...
http://jakarta.apache.org/bsf/
Also:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=9147
That has a BSF matcher and a BSF mailet written by Steve. We want to get
them into v3.
Thanks - penny has
But something I'm still not clear on. Under a unit test
the BSF mailet would be declared under the James
configuration.
I was just using those matchers as examples. For testing, I think you want
to have similar code available within Merlin, itself, able to access
whatever needs testing.
If you don't add your jar to build.xml, it won't be included. Look around
line 390.
Please feel free to submit a patch for the directions. Also, that page will
be changed with the next release of James.
--- Noel
-
To
29 matches
Mail list logo
