On 2/1/07, Andrew C. Oliver [EMAIL PROTECTED] wrote:
You know who is doing this really successfully and even made it a key
upselling point?
I imagine there are even performance numbers for it. I know I'm
speaking heresy...
yeh (but i'm trying to learn as little as possible about it). i
On 1/31/07, Andrew C. Oliver [EMAIL PROTECTED] wrote:
the resources that i think are of interest are emails, meta-data about
emails, collections of emails and meta-data about collections of
emails. these concepts already have natural correspondents in HTTP and
WebDAV
U/F it looks like
You know who is doing this really successfully and even made it a key
upselling point?
I imagine there are even performance numbers for it. I know I'm
speaking heresy...
had a talk with some of the DAV folks last year. AIUI the right way to
do it would be to standardize a small amount of
On 1/28/07, Andrew C. Oliver [EMAIL PROTECTED] wrote:
RESTfulness is a red herring.
not so much a red herring as an orthogonal kipper ;-)
yes, i admit i used a lie of juxaposition
It is not lack of RESTfulness that
makes IMAP suck. It is that it is a complex and inspecific protocol
with
smooth operation means being able to feed information about changes
back to the client which needs a little more thought
With HTTP 1.1 persistent connections this is possible and still allows
some of that pool magic. It can be a configurational pain (timeouts on
routers and stuff) but
and session
orientation was: Jsieve Configuration]
On 1/25/07, Serge Knystautas [EMAIL PROTECTED] wrote:
On 1/24/07, robert burrell donkin [EMAIL PROTECTED]
wrote:
On 1/23/07, Serge Knystautas [EMAIL PROTECTED] wrote:
snip
I would suggest looking briefly at the raw
On 1/25/07, Serge Knystautas [EMAIL PROTECTED] wrote:
On 1/24/07, robert burrell donkin [EMAIL PROTECTED] wrote:
On 1/23/07, Serge Knystautas [EMAIL PROTECTED] wrote:
snip
I would suggest looking briefly at the raw IMAP protocol. It makes
the protocol nasty, but every command gets a
burrell donkin [mailto:[EMAIL PROTECTED]
Gesendet: Samstag, 27. Januar 2007 12:37
An: James Developers List; Serge Knystautas
Betreff: RESTful email [WAS Re: MailboxManager API and session
orientation was: Jsieve Configuration]
On 1/25/07, Serge Knystautas [EMAIL PROTECTED] wrote:
On 1/24
On 1/27/07, Jürgen Hoffmann [EMAIL PROTECTED] wrote:
Hi Robert,
and who would want that sort of feature, when he can have imap?
IMAP is a great example of a very bad protocol totally unsuitable for
the internet
RSS/Atom is
more for webapps, which want to inform a user of site updates.
On 1/23/07, Serge Knystautas [EMAIL PROTECTED] wrote:
snip
I would suggest looking briefly at the raw IMAP protocol. It makes
the protocol nasty, but every command gets a unique token so that
requests and responses are asynchronous. I would presume this is why
someone like Andy will question
On 1/23/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
robert burrell donkin wrote:
commands that rely on or change message ID must be serialized and
executed in the order that the client has sent them.
Ok now I understand the issue. I started from the, now I understand
wrong, assumption that
Serge Knystautas wrote:
On 1/23/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
Can you make a common case example where the need of multiple concurrent
processors is needed for a single client? (if I have a concrete case I
remember better the issue in later discussions)
- You have 2 emails in
On 1/22/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
robert burrell donkin wrote:
Initially I thought this thread was about 3, while your diagrams seems
to me about 1: this is why I'm confused.
the diagram concerns the interface between the handler and processor
layers (as defined above)
On 1/24/07, robert burrell donkin [EMAIL PROTECTED] wrote:
On 1/23/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
robert burrell donkin wrote:
snip
(i've had a chance to take a look at the rfc)
What about multiple IMAP clients accessing the same imap folder? Are
message identifiers
On 1/24/07, robert burrell donkin [EMAIL PROTECTED] wrote:
On 1/23/07, Serge Knystautas [EMAIL PROTECTED] wrote:
snip
I would suggest looking briefly at the raw IMAP protocol. It makes
the protocol nasty, but every command gets a unique token so that
requests and responses are
On 1/22/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
robert burrell donkin wrote:
one of the tricky points about IMAP is that reasonable performance
requires that commands be executed in parallel but there are complex
rules that must be applied to the scheduling. to support concurrent
access
robert burrell donkin wrote:
commands that rely on or change message ID must be serialized and
executed in the order that the client has sent them.
Ok now I understand the issue. I started from the, now I understand
wrong, assumption that IMAP commands have to be executed synchronously
and
On 1/23/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
Can you make a common case example where the need of multiple concurrent
processors is needed for a single client? (if I have a concrete case I
remember better the issue in later discussions)
- You have 2 emails in your inbox. You move
robert burrell donkin wrote:
one of the tricky points about IMAP is that reasonable performance
requires that commands be executed in parallel but there are complex
rules that must be applied to the scheduling. to support concurrent
access to the same mailbox by multiple clients requires
robert burrell donkin wrote:
What you propose have IMAP all the way: I don't understand how you can
say it is more generic and less coupled. Am I missing the whole point?
perhaps one of them at least :-)
I was sure :-)
IMAP is a difficult protocol. making a implementation which performs
ok
robert burrell donkin wrote:
Initially I thought this thread was about 3, while your diagrams seems
to me about 1: this is why I'm confused.
the diagram concerns the interface between the handler and processor
layers (as defined above)
i think that i now understand the reason for this
robert burrell donkin wrote:
On 1/17/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
robert burrell donkin wrote:
snip
About the command pattern applied to our services we are already
working
on a common infrastructure to reuse part of our network layer between
services and prepare for
On 1/17/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
snip
I try to restart from scratch and summarize.
I think our main layers are
1) Protocol handling
2) Message processing
3) Message storage
Most of the Joachim work is about the message storage.
IMHO no
but at moment the implementation
On 1/17/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
robert burrell donkin wrote:
snip
About the command pattern applied to our services we are already working
on a common infrastructure to reuse part of our network layer between
services and prepare for asynchronous handling: you can
On 1/18/07, Norman Maurer [EMAIL PROTECTED] wrote:
I think our goal is to share as most handler-api code as possible. So
why we should not try to create an handler-api which fit all needs
(POP3,IMAP,SMTP) ?
In SMTP it is called fastfail but there are also needs for plugin
hooks in POP3 or
On 1/17/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
robert burrell donkin wrote:
snip
I think that a command pattern having an ImapCommand as the command
cannot be the api to the backend (the MailboxManager). The
MailboxManager shoudl be able to provide results for Imap, for POP3, and
On 1/18/07, Steve Brewin [EMAIL PROTECTED] wrote:
Stefano Bagnara wrote:
Danny Angus wrote:
On 1/17/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
snipped/
PS: I don't understand why this thread seems a me against robert or
danny. I'm simply trying to understand robert ideas, and to ask him
On 1/18/07, Danny Angus [EMAIL PROTECTED] wrote:
On 1/18/07, Norman Maurer [EMAIL PROTECTED] wrote:
I think our goal is to share as most handler-api code as possible. So
why we should not try to create an handler-api which fit all needs
(POP3,IMAP,SMTP) ?
In SMTP it is called fastfail
On 1/17/07, robert burrell donkin [EMAIL PROTECTED] wrote:
from what i can tell from looking at the newer code, you seem to be
moving towards a messaging API but the interfaces suffer from the
usual faults (too complex, probably unmaintainable going forward).
+1.
ATM you have an inefficient
Danny Angus schrieb:
On 1/17/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
robert burrell donkin wrote:
I think this is a step back from the current design or it simply
regards
something we already trying to solve differently with the handlerapi.
the current API design is flawed: this is
On 1/18/07, Norman Maurer [EMAIL PROTECTED] wrote:
I think our goal is to share as most handler-api code as possible. So
why we should not try to create an handler-api which fit all needs
(POP3,IMAP,SMTP) ?
In SMTP it is called fastfail but there are also needs for plugin
hooks in POP3 or
Danny Angus wrote:
On 1/17/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
Let me better approach this discussion: what is your knowledge of the
whole james code (in particular the smtpserver/handler), how it changed
in 2.3.0, how it changed in trunk, then in the 2 experimental branches
and now in
On 1/18/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
IMHO handlerapi should not be smtp specific: we use handler for every
protocol. Maybe someone doesn't share this view, but I thought this was
the main intent in calling handler api. At least the pattern (if not
the code) can be (and IMHO
Stefano Bagnara wrote:
Danny Angus wrote:
On 1/17/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
snipped/
PS: I don't understand why this thread seems a me against robert or
danny. I'm simply trying to understand robert ideas, and to ask him
explanations. I did this with Joachim when he
robert burrell donkin wrote:
i've taken the liberty to create:
http://svn.apache.org/repos/asf/james/server/sandbox/design-doodles to
house speculations such as this.
i've added something very basic to
http://svn.apache.org/repos/asf/james/server/sandbox/design-doodles/imap/messaging-api/.
robert burrell donkin wrote:
I think this is a step back from the current design or it simply regards
something we already trying to solve differently with the handlerapi.
the current API design is flawed: this is just one way to fix it.
Let me better approach this discussion: what is your
-Original Message-
From: robert burrell donkin [mailto:[EMAIL PROTECTED]
Sent: 15 January 2007 20:30
To: James Developers List
Subject: Re: MailboxManager API and session orientation was: Jsieve
Configuration
On 1/13/07, Norman Maurer [EMAIL PROTECTED] wrote:
Steve Brewin
On 1/13/07, Norman Maurer [EMAIL PROTECTED] wrote:
Steve Brewin schrieb:
robert burrell donkin wrote:
snipped/
if there's interest, maybe i'll pull together some UML
Get on with it then :)
Cheers
-- Steve
+1
i've taken the liberty to create:
Am Samstag, den 13.01.2007, 10:53 + schrieb robert burrell donkin:
this is a good example of why i claim that state needs to considered
more carefully. hopefully it may also illustrate why i claim that
session is harmful.
That's not fair. :-( It's just an example for
On 1/13/07, Joachim Draeger [EMAIL PROTECTED] wrote:
Am Samstag, den 13.01.2007, 10:53 + schrieb robert burrell donkin:
this is a good example of why i claim that state needs to considered
more carefully. hopefully it may also illustrate why i claim that
session is harmful.
robert burrell donkin wrote:
manage the state more clearly. allow the backend access to more
information about the conversational state. the parsing layer should
manage the conversational state but this should be done through an
interface. the implementation should be provided by the backend
On 1/13/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
robert burrell donkin wrote:
manage the state more clearly. allow the backend access to more
information about the conversational state. the parsing layer should
manage the conversational state but this should be done through an
interface.
robert burrell donkin wrote:
snipped/
if there's interest, maybe i'll pull together some UML
Get on with it then :)
Cheers
-- Steve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Steve Brewin schrieb:
robert burrell donkin wrote:
snipped/
if there's interest, maybe i'll pull together some UML
Get on with it then :)
Cheers
-- Steve
+1
Norman
-
To unsubscribe, e-mail: [EMAIL
On 1/11/07, Joachim Draeger [EMAIL PROTECTED] wrote:
Am Mittwoch, den 10.01.2007, 20:50 + schrieb robert burrell donkin:
snip
Think of a mbox and pop3. The backend opens the file and indexes it.
that is not conversational state but an optimization
Right, but without a session there
Am Donnerstag, den 11.01.2007, 18:55 + schrieb robert burrell
donkin:
Think of a mbox and pop3. The backend opens the file and indexes it.
that is not conversational state but an optimization
Right, but without a session there is no possibility for that
optimization.
there
On 1/11/07, Joachim Draeger [EMAIL PROTECTED] wrote:
Am Donnerstag, den 11.01.2007, 18:55 + schrieb robert burrell
donkin:
Think of a mbox and pop3. The backend opens the file and indexes it.
that is not conversational state but an optimization
Right, but without a session
robert burrell donkin wrote:
On 1/11/07, Joachim Draeger [EMAIL PROTECTED] wrote:
Am Mittwoch, den 10.01.2007, 20:50 + schrieb robert
burrell donkin:
snip
Think of a mbox and pop3. The backend opens the file
and indexes it.
that is not conversational state but an
On 1/11/07, Joachim Draeger [EMAIL PROTECTED] wrote:
Am Mittwoch, den 10.01.2007, 20:50 + schrieb robert burrell donkin:
snip
In fact sessions bring a bit inconvenience for the developer. But in the
past stateless MailRepositories made problems. They were solved by
putting it into
Am Dienstag, den 09.01.2007, 21:59 + schrieb robert burrell donkin:
AFAIK SIEVE scripts conceptually operate once mail has been delivered
to a user. how do you see the configuration working?
The LocalDeliver Mailet is the point in the chain where the Mail gets
just delivered. In fact it is
Am Mittwoch, den 10.01.2007, 00:04 +0100 schrieb Stefano Bagnara:
there are various methods to get various
flavours of session.
Currently there are three.
The problem is that IMAP has many requirements to a backend. Many
backends successfully used for POP3 will probably never
On 1/9/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
robert burrell donkin wrote:
snip
IMAP as a protocol has some commands which are naturally stateful and
some which are more naturally stateless. superficially at least, it
seems more natural to me to think about a stateful session
On 1/10/07, Joachim Draeger [EMAIL PROTECTED] wrote:
Am Mittwoch, den 10.01.2007, 00:04 +0100 schrieb Stefano Bagnara:
there are various methods to get various
flavours of session.
Currently there are three.
The problem is that IMAP has many requirements to a backend. Many
Am Mittwoch, den 10.01.2007, 17:39 + schrieb robert burrell donkin:
when using IMAP, one way to do this is by issuing a SEARCH command
specifying mailbox and the criteria. AFIAK this command does not
depend on which mailbox has been selected or the current client state,
just the data.
Am Mittwoch, den 10.01.2007, 17:53 + schrieb robert burrell donkin:
On 1/10/07, Joachim Draeger [EMAIL PROTECTED] wrote:
For instance fetching a small subset of the headers of many messages has
to be done in an optimal way. (e.g. in one SQL query)
not just a single query but an
On 1/10/07, Joachim Draeger [EMAIL PROTECTED] wrote:
Am Mittwoch, den 10.01.2007, 17:53 + schrieb robert burrell donkin:
On 1/10/07, Joachim Draeger [EMAIL PROTECTED] wrote:
snip
clients are typically interested only in a subset of the headers
Right. For current implementation:
I
Joachim Draeger wrote:
Am Mittwoch, den 10.01.2007, 17:39 + schrieb robert burrell donkin:
this [the STATUS command] is basically an atomic, stateless operation. there
should be no
need to open a heavyweight session to execute it.
I don't understand how you can define the STATUS command
On 1/9/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
robert burrell donkin wrote:
snip
From the other side developers maybe just don't need a full featured
ImapSession for their needs and want to use an easier interface.
That was the intention for providing different flavors of sessions.
On 1/10/07, Joachim Draeger [EMAIL PROTECTED] wrote:
Am Dienstag, den 09.01.2007, 21:59 + schrieb robert burrell donkin:
snip
From the other side developers maybe just don't need a full featured
ImapSession for their needs and want to use an easier interface.
That was the
Am Mittwoch, den 10.01.2007, 20:50 + schrieb robert burrell donkin:
From the other side developers maybe just don't need a full featured
ImapSession for their needs and want to use an easier interface.
That was the intention for providing different flavors of sessions.
robert burrell donkin wrote:
AFAIK SIEVE scripts conceptually operate once mail has been delivered
to a user. how do you see the configuration working?
Can you elaborate?
What does it happens if I'm checking my pop3 inbox after a message has
been delivered there but before the sieve script
Am Freitag, den 05.01.2007, 19:56 +0100 schrieb Joachim Draeger:
Am Freitag, den 05.01.2007, 09:19 + schrieb Danny Angus:
The best way would be a native, logical, hierarchical mailbox access
through the Mailet API.
If you would like to expand on this idea I'd be interested in
On 1/8/07, Joachim Draeger [EMAIL PROTECTED] wrote:
Am Freitag, den 05.01.2007, 19:56 +0100 schrieb Joachim Draeger:
Am Freitag, den 05.01.2007, 09:19 + schrieb Danny Angus:
The best way would be a native, logical, hierarchical mailbox access
through the Mailet API.
If you would
(with danny's permission, moving this back on list after accidental
personal communication)
On 1/8/07, robert burrell donkin [EMAIL PROTECTED] wrote:
On 1/8/07, Danny Angus [EMAIL PROTECTED] wrote:
On 1/7/07, robert burrell donkin [EMAIL PROTECTED] wrote:
advanced email servers end up
On 1/6/07, Serge Knystautas [EMAIL PROTECTED] wrote:
On 1/6/07, robert burrell donkin [EMAIL PROTECTED] wrote:
sorting isn't good enough for me either: emails need to be tagged with
meta-data on the server. meta-data can then used to present a folder
based view to a client or for any other
On 1/6/07, Danny Angus [EMAIL PROTECTED] wrote:
On 1/6/07, Serge Knystautas [EMAIL PROTECTED] wrote:
On 1/6/07, robert burrell donkin [EMAIL PROTECTED] wrote:
sorting isn't good enough for me either: emails need to be tagged with
meta-data on the server. meta-data can then used to present a
On 1/5/07, Joachim Draeger [EMAIL PROTECTED] wrote:
snip
BTW: Integrating IMAP, jSieve and Mailboxmanager, is one important goal
for me. I personally find it very comfortable to get the mail sorted on
server side and access it from different computers via IMAP.
interesting :-)
this sounds
On 1/6/07, robert burrell donkin [EMAIL PROTECTED] wrote:
sorting isn't good enough for me either: emails need to be tagged with
meta-data on the server. meta-data can then used to present a folder
based view to a client or for any other purposes. i think that a rules
engine plus a domain
On 1/6/07, Serge Knystautas [EMAIL PROTECTED] wrote:
On 1/6/07, robert burrell donkin [EMAIL PROTECTED] wrote:
sorting isn't good enough for me either: emails need to be tagged with
meta-data on the server. meta-data can then used to present a folder
based view to a client or for any other
Am Donnerstag, den 04.01.2007, 21:24 + schrieb Steve Brewin:
Full integration is a pending James activity awaiting the
completion of our
IMAP implementation which will bring with it the required
infrastructure to
make jSieve truly useful.
The Sieve spec. is predicated on
On 1/5/07, Joachim Draeger [EMAIL PROTECTED] wrote:
The best way would be a native, logical, hierarchical mailbox access
through the Mailet API.
If you would like to expand on this idea I'd be interested in seeing
what it looks like when applied to sandbox/mailet-refactorings/. If
you want
Danny Angus schrieb:
On 1/5/07, Joachim Draeger [EMAIL PROTECTED] wrote:
The best way would be a native, logical, hierarchical mailbox access
through the Mailet API.
If you would like to expand on this idea I'd be interested in seeing
what it looks like when applied to
On 1/5/07, Norman Maurer [EMAIL PROTECTED] wrote:
Danny Angus schrieb:
On 1/5/07, Joachim Draeger [EMAIL PROTECTED] wrote:
The best way would be a native, logical, hierarchical mailbox access
through the Mailet API.
If you would like to expand on this idea I'd be interested in seeing
On 1/4/07, robert burrell donkin [EMAIL PROTECTED] wrote:
AFAIK you need to alter the master configuration files. be cool to be
able to have a new component packaged in a jar with some xml whatknot
and have james pick it up.
Ha! Yes, We've discussed this before in relation to deployment of
Am Freitag, den 05.01.2007, 11:24 + schrieb Danny Angus:
The best way would be a native, logical, hierarchical mailbox access
through the Mailet API.
If you would like to expand on this idea I'd be interested in seeing
what it looks like when applied to
Am Freitag, den 05.01.2007, 09:19 + schrieb Danny Angus:
The best way would be a native, logical, hierarchical mailbox access
through the Mailet API.
If you would like to expand on this idea I'd be interested in seeing
what it looks like when applied to sandbox/mailet-refactorings/.
Joachim Draeger wrote:
I guess jSieve just needs a possibility to access different
folders/mailboxes that can be accessed by the user through IMAP.
Today this would mean access to the MailboxManager. (the IMAP capable
backend, not the IMAP server itself)
Does it need access to a repository
robert burrell donkin wrote:
is there any way to drop in a new component ATM?
AFAIK you need to alter the master configuration files. be cool to be
able to have a new component packaged in a jar with some xml whatknot
and have james pick it up.
- robert
I think that Phoenix does not have
Steve Brewin wrote:
robert burrell donkin wrote:
AFAIK you need to alter the master configuration files. be cool to be
able to have a new component packaged in a jar with some xml whatknot
and have james pick it up.
In James? The mailet classloader will look in SAR-INF/classes and
SAR-INF/lib
Am Freitag, den 05.01.2007, 21:10 +0100 schrieb Stefano Bagnara:
I guess jSieve just needs a possibility to access different
folders/mailboxes that can be accessed by the user through IMAP.
Today this would mean access to the MailboxManager. (the IMAP capable
backend, not the IMAP server
Stefano Bagnara wrote:
Steve Brewin wrote:
robert burrell donkin wrote:
AFAIK you need to alter the master configuration files. be
cool to be
able to have a new component packaged in a jar with some
xml whatknot
and have james pick it up.
In James? The mailet classloader will look
Danny Angus wrote:
On 1/5/07, Joachim Draeger [EMAIL PROTECTED] wrote:
The best way would be a native, logical, hierarchical mailbox access
through the Mailet API.
If you would like to expand on this idea I'd be interested in seeing
what it looks like when applied to
Steve Brewin wrote:
Stefano Bagnara wrote:
Maybe this is not related, but I changed this from 2.2.0 to
2.3.0. After
the Phoenix update we could now rely on the classloader
phoenix provide
to James, that already lookup SAR-INF/classes and SAR-INF/lib. So we
don't have anymore a custom
Hi,
i have to integrate Jsieve with james mailserver,can anyone please provide
the process of jsieve integration with james mailserver/hmailserver.
regards,
Lokesh.
--
View this message in context:
http://www.nabble.com/Jsieve-Configuration-tf2918418.html#a8155943
Sent from the James - Dev
Lokesh Babu wrote:
Hi,
i have to integrate Jsieve with james mailserver,can anyone
please provide
the process of jsieve integration with james mailserver/hmailserver.
Take a look at package org.apache.jsieve.samples.james and be sure to read
package.html. As noted, this is a partial
On 1/4/07, Steve Brewin [EMAIL PROTECTED] wrote:
Lokesh Babu wrote:
Hi,
i have to integrate Jsieve with james mailserver,can anyone
please provide
the process of jsieve integration with james mailserver/hmailserver.
Take a look at package org.apache.jsieve.samples.james and be sure to
On 1/4/07, Steve Brewin [EMAIL PROTECTED] wrote:
Lokesh Babu wrote:
Hi,
i have to integrate Jsieve with james mailserver,can anyone
please provide
the process of jsieve integration with james mailserver/hmailserver.
Take a look at package org.apache.jsieve.samples.james and be sure to
robert burrell donkin wrote:
On 1/4/07, Steve Brewin [EMAIL PROTECTED] wrote:
Lokesh Babu wrote:
Hi,
i have to integrate Jsieve with james mailserver,can anyone
please provide
the process of jsieve integration with james
mailserver/hmailserver.
Take a look at package
robert burrell donkin wrote:
On 1/4/07, Steve Brewin [EMAIL PROTECTED] wrote:
Lokesh Babu wrote:
Hi,
i have to integrate Jsieve with james mailserver,can anyone
please provide
the process of jsieve integration with james
mailserver/hmailserver.
Take a look at package
Steve Brewin schrieb:
robert burrell donkin wrote:
On 1/4/07, Steve Brewin [EMAIL PROTECTED] wrote:
Lokesh Babu wrote:
Hi,
i have to integrate Jsieve with james mailserver,can anyone
please provide
the process of jsieve integration with james
90 matches
Mail list logo
