MINA SMTP handler Was: James IMAP @ Google SOC: not too late, I hope?

[Mike Heath <mh...@avaloninc.com>]

<snip>

> > I'm continuing to develop MINA based protocol handlers.  In fact,
the 
> > project is moving to safehaus.org and is really gaining momentum.  I
> > think the MINA architecture would serve JAMES well as much of the talk
> > regarding fast-fail overlaps work already done in MINA itself.
>
> If you want to contribue to JAMES, which I believe is the mutual desire,
> doing development elsewhere just makes it a longer road to get into our
> codebase.

Here is my reasoning for developing a MINA based SMTP framework at
Safehaus.  What I really need is a lightweight, embeddable SMTP server.
I don't need a full email server (at least, not yet.)  I just need to be
able to receive SMTP messages and process them.  I also wanted to learn
how to use MINA.  In the process, a lot of people have expressed similar
desires for either a lightweight SMTP server or a MINA based SMTP
server.  Working at Safehaus helps us to accomplish these goals.

Certainly I would like my code to be used in JAMES but it would take a
lot of effort to rewire everything.  Also, considering the fact that any
TLS over NIO would require J2SE 5 (or a custom SSL engine which would be
a waste of time IMO) I'm not sure how MINA and JAMES fit together right
now.  When JAMES is ready to move to J2SE 5, I would be more than happy
to help in the migration to MINA if that's what JAMES really wants to
do.

> As for MINA, I agree with the approach to use a NIO-based framework, and I
> like what we're doing with MINA, but I believe that it would be a mistake to
> tie our fast-fail to MINA.  It isn't necessary as far as I can see, and I
> believe that Trustin concurs.  As far as I can see, all we need from MINA is
> RFC compliant handling to deliver properly terminated lines, which we'll
> take from there.

Please forgive me if I'm mistaken but I get the strong impression that
you don't really understand what MINA is all about.  If all you want is
"RFC compliant handling to deliver properly terminated lines" over NIO
than MINA provides much more than what you want.

Danny has talked a lot about providing a SMTP command chain for fast
fail.  (This is, of course, a great simplification of what Danny has
proposed.)  MINA provides a protocol filter chain out of the box.  If
you look through my code, you will see that I use this as part of my
STARTTLS implementation.  If the "TLS is required" option is set, I have
a MINA protocol filter that checks to see if TLS is enabled and if it
iss not, it only let the STARTTLS, EHLO, NOOP and QUIT commands through
per RFC 1854.

Danny also stated very clearly in an email he sent May 13 that: "Fast
fail is, by definition, a protocol handling issue.  We consider fast
fail to be the termination of the protocol session with an error and a
message before the message has been received."  MINA is a protocol
framework.  It's NOT just a NIO framework.  Trustin is working on
providing regular socket support in MINA.  There is also work for
providing RFC232 support in MINA.  MINA is a protocol framework.  It
greatly simplifies the process of writing protocol handlers.  So, I'm
going to have to call BS on Trustin concurring that MINA not be used to
provide fast-fail.  I doubt he would implement such a flexible protocol
framework and then tell people not to use it.

-Mike


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

RE: MINA SMTP handler

["Noel J. Bergman" <no...@devtech.com>]

> > As for MINA, I agree with the approach to use a NIO-based framework,
> > and I like what we're doing with MINA, but I believe that it would
> > be a mistake to tie our fast-fail to MINA.

> Please forgive me if I'm mistaken

You're mistaken.  :-)  It isn't a question of whether MINA *can* do it, but
finding the right way for JAMES.

> If all you want is "RFC compliant handling to deliver properly
> terminated lines" over NIO than MINA provides much more than
> what you want.

Agreed.  :-)

> Danny has talked a lot about providing a SMTP command
> chain for fast fail.

Yes.  As have I, which you can see if you look at my proposal.  But how the
chains are managed and implemented can vary.  And I'm really not sure that
we want to hardcode that aspect of JAMES to MINA.  At the moment, tightly
intertwining our functional code with our platform support code isn't
meeting with favor in my mind.

> > [Using MINA's filter architecture for fast-fail] isn't necessary
> > as far as I can see, and I believe that Trustin concurs.

> MINA provides a protocol filter chain out of the box.  If you
> look through my code, you will see that I use this as part of
> my STARTTLS implementation.  If the "TLS is required" option
> is set, I have a MINA protocol filter that checks to see if
> TLS is enabled and if it is not, it only let the STARTTLS,
> EHLO, NOOP and QUIT commands through per RFC 1854.

That would define an interface between our code and platform code.

> Trustin is working on providing regular socket support in MINA.

Yes, I know.  I'm the one who instigated it.

> I'm going to have to call BS on Trustin concurring that MINA
> not be used to provide fast-fail.

I didn't say that it cannot be used, but I don't believe that we want to
entwine our application code too tightly with the platform layer, unless we
commit to MINA as *the* network solution.  Trustin and I had a long
discussion about MINA filters in early May.  One of Trustin's ideas was to
create a MINA Filter that would act as a bridge, so that the bulk of our
code remains platform layer neutral.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org