james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: SMTP Transport?
Date Sat, 30 Jan 2010 17:46:30 GMT
Norman Maurer wrote:
> Hi Oleg,
> 
> no need to be sorry ;) Anyway I thought more of writing lmtp protocol
> implementation which not depends on any nio framework directly. Just
> like the smtp-protocol-library (in james server trunk). The protocol
> should be independent of the transport. So the protocol should be
> usable with "every" transport framework.
> 
> So at the moment we have a mina-socket-library but the
> smtp-protocol-library would also work with (for example)
> lightnio-socket-library ;)
> 

That would truly be the best case scenario, but I doubt this can be done 
without a significant loss of efficiency. I was not able to do that for 
our HTTP transport. It is worth a try, though.

Anyhow, feel free to re-use whatever bits of my code you may find useful.

I would be so happy to deprecate my stuff in favor of something backed 
by a larger community.

Cheers

Oleg


> Bye,
> Norman
> 
> 2010/1/30 Oleg Kalnichevski <olegk@apache.org>:
>> Norman Maurer wrote:
>>> Hi Oleg,
>>>
>>> sorry for takin so long but I had many other stuff on my blade. I
>>> would really like to get a LMTP implementation into james (using MINA
>>> for NIO), is there any interest in this for you ?
>>>
>> Hi Norman
>>
>> I am sorry to say what I am about to say, but, if using MINA, no, there
>> would be no interest on my part. I took a very close look at MINA internals
>> some time ago, and while there were some really great design ideas in MINA,
>> I personally found its memory management flawed to a point making it
>> unsuitable for data intensive protocols, such as HTTP and SMTP. This is one
>> of the reasons why we opted for writing our own NIO framework for HttpCore.
>> There were other reasons as well.
>>
>> Having written a NIO framework of my own, I fully admit being biased about
>> the issue, though.
>>
>> Sorry.
>>
>> Oleg
>>
>>
>>
>>> Bye,
>>> Norman
>>>
>>> 2009/11/23 Norman Maurer <norman.maurer@googlemail.com>:
>>>> Hi Oleg,
>>>>
>>>> I will have a look soon. Thx for keeping us in the loop :)
>>>>
>>>> Bye,
>>>> Norman
>>>>
>>>> 2009/11/23 Oleg Kalnichevski <olegk@apache.org>:
>>>>> Norman Maurer wrote:
>>>>>> Hi Oleg,
>>>>>>
>>>>>> I would be very interested in this :-)
>>>>>>
>>>>>> Bye,
>>>>>> Norman
>>>>>>
>>>>> Folks,
>>>>>
>>>>> I finally have the library in a fairly usable (or shall I rather say
>>>>> testable) state. I can now send messages to the postfix daemon using
my
>>>>> SMTP
>>>>> client transport and have the messages passed onto the local LMTP agent
>>>>> based on the same transport code for local delivery.
>>>>>
>>>>> In essence I have a reasonably complete SMTP/LMTP transport library that
>>>>> implements RFC 2821 (minimum implementation), RFC 2033, plus a number
of
>>>>> extensions required by LMTP: RFC 2034 (ENHANCEDSTATUSCODES), RFC 1854
>>>>> (PIPELINING), RFC 1652 (8BITMIME).
>>>>>
>>>>> The code is still very experimental but good enough for getting the feel
>>>>> of
>>>>> the API.
>>>>>
>>>>> Here's the sample of the LMTP transfer agent
>>>>>
>>>>>
>>>>> http://code.google.com/p/lightmtp/source/browse/trunk/src/examples/java/com/ok2c/lightmtp/examples/LocalMailServerTransportExample.java
>>>>>
>>>>> Envelop validation / message delivery can be fully asynchronous. Long
>>>>> running processes such as DB or LDAP queries can be executed without
>>>>> blocking the I/O transport.
>>>>>
>>>>> The client side transport can either be event (callback) driven
>>>>>
>>>>>
>>>>> http://code.google.com/p/lightmtp/source/browse/trunk/src/examples/java/com/ok2c/lightmtp/examples/LocalMailClientTransportExample.java
>>>>>
>>>>> or future driven
>>>>>
>>>>>
>>>>> http://code.google.com/p/lightmtp/source/browse/trunk/src/examples/java/com/ok2c/lightmtp/examples/MailUserAgentExample.java
>>>>>
>>>>> http://code.google.com/p/lightmtp/source/browse/trunk/src/examples/java/com/ok2c/lightmtp/examples/SendMailExample.java
>>>>>
>>>>> The mail user agent can maintain a pool of persistent connections that
>>>>> can
>>>>> be reused for subsequent delivery requests.
>>>>>
>>>>> The NIO framework is basically a fork of Apache HttpCore with all HTTP
>>>>> dependencies removed.
>>>>>
>>>>> http://code.google.com/p/lightnio/
>>>>>
>>>>> You would have to get the latest snapshots of both libraries in order
to
>>>>> run
>>>>> samples.
>>>>>
>>>>> I developed this code for my private use. If you do not think this is
>>>>> something that can be potentially useful for a larger user base, just
>>>>> ignore
>>>>> my message.
>>>>>
>>>>> Cheers
>>>>>
>>>>> Oleg
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> 2009/6/12 Oleg Kalnichevski <olegk@apache.org>:
>>>>>>> On Thu, Jun 11, 2009 at 04:30:58PM +0200, Markus Wiederkehr wrote:
>>>>>>>> I've written a class SmtpTransport that can be used to send
a Mime4j
>>>>>>>> message to an SMTP server.
>>>>>>>>
>>>>>>>> Currently it is very simple. Meaning it is not yet capable
of
>>>>>>>> authentication or TLS or other extensions.
>>>>>>>>
>>>>>>>> Would it be worth to include this code in Mime4j?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Markus
>>>>>>>>
>>>>>>>> PS: Testing is a bit of a PITA with sockets and all.. Robert,
could
>>>>>>>> MPT help with that? I haven't looked into it yet..
>>>>>>> Markus et al
>>>>>>>
>>>>>>> _Coincidentally_, I have been working on a LMTP agent and LMTP
client
>>>>>>> with
>>>>>>> support for mandatory extensions required by LMTP [1]: PIPELINING,
>>>>>>> ENHANCEDSTATUSCODES and 8BITMIME. The implementation is based
a NIO
>>>>>>> framework
>>>>>>> derived from HttpCore NIO and should be quite scalable. This
is my
>>>>>>> private
>>>>>>> project, but if there is interest in such work, I am willing
to
>>>>>>> contribute it
>>>>>>> to James. Alternatively you are very welcome to contribute to
the
>>>>>>> effort.
>>>>>>> It is
>>>>>>> ASLv2 licensed.
>>>>>>>
>>>>>>> Cheers
>>>>>>>
>>>>>>> Oleg
>>>>>>>
>>>>>>> [1] http://www.ietf.org/rfc/rfc2033.txt
>>>>>>>
>>>>>>>
>>>>>>>
>>
> 


Mime
View raw message