Noel J. Bergman wrote:
Sieve would be nice if there is the impression that other people are
familiar with it. That said, I'm not sure there really is.
A year ago, sieve wasn't an IETF RFC, and there were maybe two sieve related
projects on SourceForge, one of which was CMU libsieve. Things have
c
> Sieve would be nice if there is the impression that other people are
> familiar with it. That said, I'm not sure there really is.
A year ago, sieve wasn't an IETF RFC, and there were maybe two sieve related
projects on SourceForge, one of which was CMU libsieve. Things have
changed, although I
Noel J. Bergman wrote:
Still, what is the real value that a Sieve container brings? Sieve suport
would make James configuration more administrator friendly, a major area
concern for many.
As-is support of an IETF standard for common mail behavior where the full
power of James' custom matcher/mailet
Noel J. Bergman wrote:
I'm not adversely disposed to relaxing this but I'd like to know
why we'd choose a processor over a mailet for the role.
A language like Sieve, which is now an RFC, has its own notion of matching,
flow, and operation. As Steve pointed out, we could wrap all of that in a
Mail
> I believe that adding Jelly support to the current Mailet
> container is a better route than creating a new container.
Why? The current container knows, or will know when some code is moved out
of JamesSpoolManager, how to initialize its matchers and mailets from its
own XML configuration eleme
Jason Webb wrote:
Personal filtering should be personally configurable. How
might that be achieved? Using Sieve scripts associated with
each users mailbox.
Yes. When I finally get round to completing the work on user attributes
;)
You don't need user attributes for personal filtering. If/once we
> Mailet was the atomic unit of processing and that any escape from
> the Mailet API into any other system used to process the messages
> should be done using a Mailet as a gateway.
> I'm not adversely disposed to relaxing this but I'd like to know
> why we'd choose a processor over a mailet for t
Jason, Steve and Danny (who remembered),
> Spam is always personal.
> Therefore I think that users should have a processing pipeline as well.
> When LocalDelivery runs it should not just blindly deliver the mail, it
> should execute the user's mail pipeline as well.
See: http://nagoya.apache.org/
Noel J. Bergman wrote:
While on the subject of direction, what do we want to do before cutting the
next major release?
- Do we want to take the current code as-is?
- Do we want to take the current code + latest Avalon,
which means pulling in Component->Service changes?
- Do we want to do
Noel J. Bergman wrote:
I think that the ASF James project should formally endorse and host,
obviously with no responsibility, a site where users can store and
exchange matchers/mailets
+1
This is similar to what HTTPd had for contributed patches. I think that we
need to insist that the license be
+1
I was thinking the same thing. It would be awsome!
-Original Message-
From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
Sent: Mon 11/17/2003 7:49 PM
To: James Developers List
Cc:
Subject:Contributed Matcher/Mailet library sub-project
> I think that the ASF James pr
> > - No consensus on how to support more complex processing logic (matcher
> > params, BSD scripting, etc...)
> Let's start implementing
http://nagoya.apache.org/wiki/apachewiki.cgi?JamesV3/MailetConfiguration #1
in v2.2.
You want to do that now? Before we make the next major release?
By the w
> I think that the ASF James project should formally endorse and host,
> obviously with no responsibility, a site where users can store and
> exchange matchers/mailets
+1
This is similar to what HTTPd had for contributed patches. I think that we
need to insist that the license be the ASF license
While on the subject of direction, what do we want to do before cutting the
next major release?
- Do we want to take the current code as-is?
- Do we want to take the current code + latest Avalon,
which means pulling in Component->Service changes?
- Do we want to do additional refactoring
Hi,
I havent been able to find anything in the archives about this, but has
anyone got anywhere with list manager functionality on James? I'm
thinking of building something akin to Lyris Listmanager for a project but
using James, some custom mailets and a Java script processor like Dynamic
Jav
OK. Then next step.
Architecturally, this is a sound piece of refactoring. In my view, it is
only worth doing if we are going to have another container to support, and
further, that the new container adds real value.
To add real value the new container has to offer something that the current
Mail
Danny Angus wrote:
> Lots!
Danny,
I agree that where we are simply introducing support for expressing
conditional logic and evaluation in a scripted language, that this is best
done within the current Mailet container, so as to continue leveraging the
existing declarative mail flow.
I don't see
> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]
> Sent: 17 November 2003 15:11
> To: James Developers List
> Subject: RE: Future direction for James
>
>
>
>
>
>
> > Therefore I think that users should have a processing pipeline as
> > well. When LocalDelivery ru
> Therefore I think that users should have a processing pipeline as well.
> When LocalDelivery runs it should not just blindly deliver the mail, it
> should execute the user's mail pipeline as well.
W/O trawling through this discussion I think you've just resurected an idea
from days of yore.
> -Original Message-
> From: Steve Brewin [mailto:[EMAIL PROTECTED]
> Sent: 17 November 2003 14:28
> To: 'James Developers List'
> Subject: RE: Future direction for James
>
>
> Jason Webb wrote:
> > When LocalDelivery runs it should not just blindly deliver
> the mail,
> > it should
Jason Webb wrote:
> When LocalDelivery runs it should not just blindly deliver
> the mail, it
> should execute the user's mail pipeline as well.
Its perfectly legitimate for a company to have a system wide policy of what
it denotes as Spam and reject such mail in the mail server.
Its also conciev
Whilst we are on the subject of the processors and processing mail...
This is a bit of a rant, but I do eventually get to the point.
I notice that quite a few people have used the idea of a spam catching
matcher/mailet combination.
This made me think about where and when to catch spam.
All the exa
Hi,
Please read to the end before you reply, it may be dull but I believe it's
important..
> Ah! You mean that creates an instance of class
LinearProcessor,
> which currently is hardcoded to launch the Mailet container. We can add
> flexiblity, making it possible to launch other containers,
23 matches
Mail list logo
