thank you:)
Should I migrate these keys to new message and session scope maps and
remove *OLD* state hashmap??
// Keys used to store/lookup data in the internal state hash map
private final static String CURRENT_HELO_MODE = "CURRENT_HELO_MODE"; // HELO
or EHLO
private final static String SENDER
> sorry I sent a wrong version that didnot compile It should
> be session.getState().get(MESG_FAILED) as the existing Keys
> MESG_FAILED, SENDER and so on would continue to use the state
> variable in the SMTPHandler.
> -- Anagha
Fixed, thank you again,
Stefano
-
sorry I sent a wrong version that didnot compile
It should be session.getState().get(MESG_FAILED) as the existing Keys
MESG_FAILED, SENDER and so on would continue to use the state variable in
the SMTPHandler.
-- Anagha
On 8/30/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>
> > Stef
> Stefano,
>
> I am still working on 2 and 3. I thought I could release one
> patch with the following changes
>
> 1. UnknownCommandHandler.java
> a) Added
> //If there was message failure, don't consider it as
> an unknown command
> if (state.get(MESG_FAILED) != null) {
>
Stefano,
I am still working on 2 and 3. I thought I could release one patch with the
following changes
1. UnknownCommandHandler.java
a) Added
//If there was message failure, don't consider it as an unknown command
if (state.get(MESG_FAILED) != null) {
return;
> > - Now SMTPhandler implements SMTPSession interface. Remove
> the inner
> > class implementation
> > - Removed unecessary interfaces from SMTPSession interface
> > - Made changes to SMTPHandlerChain that doenot allow the server to
> > start if there are no commandHandlers registered or if the
Attached the patch that has following changes
- Now SMTPhandler implements SMTPSession interface. Remove the inner
class implementation
- Removed unecessary interfaces from SMTPSession interface
- Made changes to SMTPHandlerChain that doenot allow the server to
start if there are no commandHandl
> > If you like any of this ideas I can help you identifying james
> > services you need and how to use Avalon lifecycle
> interfaces to gain
> > access to the user db or to the repositories.
>
> I like all of them. To begin with I will work on these
> 1.
> MAILHandler that allow to specify ba
On 8/25/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> IMHO any effort to be able to use Mathers/Mailets or even full processors
> from the MessageHandlers would be useful.
>
> > Do you want me to work on something specific for my next release?
>
> We could change the default "command unknown"
> > I've just tested that it runs and it accept a message in smtp.
> > I won't have time this week to do more than this.
>
> I am doing thorough testing. I am planning to refactor some
> more and start work on MatcherMessageHandler.
IMHO any effort to be able to use Mathers/Mailets or even full
On 8/22/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> > Stefano,
> >
>> Hi Anagha,
>
> I just committed your update!
>
> I fixed a "blocklisted = blocklisted;" that should have been
> "this.blocklisted = blocklisted;" in SMTPHandler.
oops I missed that!
>
> I also did a few dummy changes:
> Stefano,
>
> Attached the patch that has following changes
>
> - Now SMTPhandler implements SMTPSession interface. Remove
> the inner class implementation
> - Removed unecessary interfaces from SMTPSession interface
> - Made changes to SMTPHandlerChain that doenot allow the
> server to start
Updated the JIRA
http://issues.apache.org/jira/secure/attachment/12311884/Aug22JamesFastFail.patch
--anagha
On 8/22/05, Anagha Mudigonda <[EMAIL PROTECTED]> wrote:
> Stefano,
>
> Attached the patch that has following changes
>
>
> - Now SMTPhandler implements SMTPSession interface. Remove the
Stefano,
Attached the patch that has following changes
- Now SMTPhandler implements SMTPSession interface. Remove the inner
class implementation
- Removed unecessary interfaces from SMTPSession interface
- Made changes to SMTPHandlerChain that doenot allow the server to
start if there are no com
Danny and Noel,
I would like to contribute in arriving at a
lightweight in-protocol
framework that is *reasonably* extensible and
configurable. I tweaked
the interfaces little bit and there are two major
deviations from the
proposals put forth at
http://wiki.apache.org/james/FastFail.
1
Hello, Danny and Other James Developers!
I have just updated my james-fastfail proposal
http://wiki.apache.org/james/SummerOfCode2005/SergeyLubinskiyFastFail#preview
Now it says more what I wanted to say
rather than what my fingers were able to type late at night :-)
Danny Angus <[EM
server-dev@james.apache.org
|
| cc:
|
| Subject: [SummerOfCode2005] [james-fa
Hello, James developers!
I think I'm late like a Rabit from "Alice In The Wonderland"
http://wiki.apache.org/james/SummerOfCode2005/SergeyLubinskiyFastFail#preview
I fear the proposal is a little too wordy - due to lack of time.
Do you think anybody there could sponsor me?
Sergey
P.S. Anybody
Helo, James developers!
What a shame that it has been so late that I've been told about
[SummerOfCode2005] programm.
For it is just the right thing at the right time - I'm a student at Department
Of Physics,
Moscow State University http://www.msu.ru/en/ and I'm really keen on
programming.
Two
Noel,
I like the design you proposed for the protocol
handler framework so that Fast fail is a mere
extension to it. Moreover the rest of protocols can be
rewritten around the new framework. Here is my design
proposal very much on the lines on yours and Danny's.
Please review and let me know your
Anagha Mudigonda wrote:
> If MAIL FROM validation passed SPF then no need to Validate RCPT TO
> If MAIL FROM, RCPT TO Passed then no need to validate DATA
Well, I'm not so sure about those rules, but that's separate from how one
might do them.
> We not only need session state but some kinda rule
Hi,
I have been actively following the Fast fail design
discussions. I was wondering it may be necessary to
configure rule as the following:
If MAIL FROM validation passed SPF then no need to
Validate RCPT TO
If MAIL FROM, RCPT TO Passed then no need to validate
DATA
We not only need session sta
On Thursday 09 June 2005 11:58, Danny Angus wrote:
> Are you going to ApacheConEU? We could arrange to brainstorm the
> implementation details.
Unfortunately not ;-(
Great, we are totally on the same track then!
--Søren
--
Søren Hilmer, M.Sc.
R&D manager Phone: +45 72 30 64 00
T
Soren,
> I like your proposal for fastfail, very much in line with my own
thoughts.
> I only have minor comments.
Yeah I think with Noel's comments and your's we seem to be approaching a
consensus on this one.
Are you going to ApacheConEU? We could arrange to brainstorm the
implementation details
Hi Danny,
>
> My own idea config would look like:
>
>
>
>
>
> MAIL
>
>
> FROM
>
>
>
> 5xx
> foo-barred
>
>
>
> 220
> OK
>
>
>
>
>
I like your proposal for fastfail, very mu
> 550 5.7.1 User unknown
Yeah OK.
> I think (as I said in past) that allowing full smtp reply code control at
> this level will be an error.
I don't think it is up to us to dictate how James users chose their
installations to behave.
OTOH I don't think we need to mandate configuration of respon
> By the way, did I miss a patch where you changed the bounce
> mailet? I'm seeing the DSNStatus inner class still there, as
> well as the new copy of it that is in mail/dsn/DSNStatus.
>
> --- Noel
My DSNBounce is totally different from the one in trunk. Actually I named my
bounce handli
Stefano,
> I wouldn't like the SMTP server to read the "code" that an handler returns
> and decide how to behave dependently on the first char of that code.
I agree with that concern, which isn't generally exposed in the my version
of the fast-fail proposal. In the case where I show a general ca
> your configuration example:
>
>
>
>
> [...]
> 220
>
>
> [..]
>
> 5xx
>
>
> 220
>
> [..]
I just added ENHANCEDSTATUSCODES support to james smtp server. So you should
take care to add a DSN status to every smtp reply and not only
Alexander,
your configuration example:
MAIL FROM
accept
220
...
Looks just fine, very close to what I imagined.
What I can't understand is how you could use "Matchers" before you have a
complete "Mail".
My own idea config would look
Noel wrote:
> Although the scope of "validation" covers that neccessary to determine
that
> we will accept the responsibility for delivery, which can lead to some
other
> things. For example, I would probably configure virtual user mapping
within
> the protocol handler, which would allow me to r
Alexander Botov wrote:
> thanks for the update. It really clarifies the fast-fail mechanism for me.
> I have couple of questions (regarding fast-fail):
> - Which branch from the svn should I checkout?
We've recently moved into subversion and completed a version merger so that
trunk/ is the curre
On Sat, 4 Jun 2005 16:10:49 -0400, Noel J. Bergman wrote
> Alexander (and others interested in Fast-Fail),
>
> Danny has some information on http://wiki.apache.org/james/FastFail
> for his proposal. That is one of several that have come up over the
> past couple of years. I j
your eligibility.
Regardless of the Summer of Code, we encourage anyone who is interested to
contribute to JAMES. There is a lot that can be done with JAMES, and we are
always interested in growing the developer community.
> I would be interested in the project 'james-fastfail&#x
for me to
subscribe to a project of 'summer of code'. What do you think?
I would be interested in the project 'james-fastfail'. In this project I
could learn a lot of the protocols. And you wrote that there is a good
background material available. So I could study this firs
> I would probably configure virtual user mapping within the
> protocol handler, which would allow me to reject unknown
> users in-protocol instead of via bounce notices. But this
> should be a configurable choice, ideally using the same code.
If you run VirtuserTable in the protocol handler
Danny Angus wrote:
> In my opinion (There may be some disagreement about where we're going
> with this!) Fast Fail is about extending the SMTP protocol to include
> validations
+1
Although the scope of "validation" covers that neccessary to determine that
we will accept the responsibility for de
Alexander (and others interested in Fast-Fail),
Danny has some information on http://wiki.apache.org/james/FastFail for his
proposal. That is one of several that have come up over the past couple of
years. I just posted mine there, too.
Danny and I are largely in agreement on on having some
OK, there are many enthusiastic people out there willing to contribute to
James project, so I'm wondering if there is need for more, but still...
My name is Alexander Botov and I'm undergraduate student studying computer
science in Technical University of Sofia, Bulgaria. I've been using James in
HI,
> Handler receives data, and forms
> approriate commands and call doXXX to handle these commands. One
> possible clustering approach here is to distribute these
> commands to different processes (in different JVM as well).
We currently assign each socket conenction to a handler and each
handl
> Could any developers verify my observations and give some
> comments ? I am really interested in implementing clustering
> feature for James.
I would look here, too: http://sourceforge.net/projects/james-ha/
Stefano
-
To un
I dont know the intention of james clustering proposal but I have been
reading james source code for 2 days and trying to
find places that clustering can be applied.
As far as I know, each Handler of any kind represents socket connection
with other party. Handler receives data, and forms
approri
I suggest you subscribe to server-dev@james.apache.org
and get involved in the discussions there.
I don't know anything about the clustering proposal.
I think the google summer of code is intended to be a three month
"engagement" and I suspect that three months full-time is more than
plenty time t
43 matches
Mail list logo
