[erlang-questions] smtp server

Ingela Andin ingela.andin@REDACTED
Thu Feb 2 18:25:00 CET 2012


2012/2/2, Steve Davis <steven.charles.davis@REDACTED>:
> Hi Kaiduan,
> For sure, with "old ssl", I could never get a reliable socket upgrade at
> all. Comparatively, new ssl is indeed far more advanced than old ssl.
> Nonetheless, for the qualification of "awesome" in a platform comparison
> (i.e. with NOT erts version X versus erts version Y) there's a massive
> task that perhaps you can't appreciate without reviewing the following
> document...
> http://www.iana.org/assignments/tls-parameters/tls-parameters.xml
> ...and test suite referenced here...
> http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html

We use this test suite to verify our PKIX-path-validation code,
granted we do not yet support CRL-handling but that is on its
way. Our verify_fun will let you work around the problem that it
is not yet supported. (Not so fun for you perhaps but a possible
solution for now).

The somewhat optional policy mapping extension is further into the
future, if we see a strong enough argument to implement it, but
even this can be handled by the verify_fun if you really need it.

We are working on supporting the latest TLS-version on the other
hand as far as I know OpenSSL 1.0 only supports TLS v1.0. The
development version has experimental support for TLS v1.1 and no
version currently supports TLS v1.2.

We do not support all possible optional extensions as
Kerberos-cipher-SUITES, but hey feel free to contribute.

> There's also connection cost/memory overhead to take into account, and
> possibly process spawning cost under high load (which I have not
> measured but "wonder about")... but I digress.

Spawning erlang processes is cheap, but speculation is fairly
uninteresting if you have
concerns you should make measurments. Also check out the hibernate
option that will
make your ssl-processes garbage-collected earlier.

Regards Ingela Erlang/OTP team - Ericsson AB

> I think the team at Ericsson that we rely on have made incredible
> strides with tls, but the overall task is undeniably huge and will take
> quite some time yet to settle into a mature implementation. Fortunately,
> the motivation to solve these issues appears to be higher now than it
> was a couple of years ago, and will definitely benefit all (also note
> that some of the earlier application-level enterprise platforms e.g.
> ejabberd had even gone to the extent of implementing their own ssl
> processes).
> Well, that's where I am with this but feel free to disagree/correct, as
> I still feel there's a ways to go :)
> regards,
> /s
> On 2/1/2012 9:50 AM, Kaiduan Xie wrote:
>> "For instance, START_TLS is still not "easy" in erlang owing to the
>> long, and continuing, struggle
>> to get good TLS protocol support."
>> Steve, do you mean the TLS support in Erlang is not good? Can you
>> explain a bit more? I think the new SSL in Erlang is awesome compared
>> with the old openSSL based implementation.
>> /Kaiduan
>> On Tue, Jan 31, 2012 at 8:21 PM, Steve Davis
>> <steven.charles.davis@REDACTED>  wrote:
>>> I have noticed that a great number of SMTP projects fail with a
>>> whimper. In particular, I observed that the JBoss project ran an SMTP
>>> project for a long, long time before even barely having something
>>> reasonable, and it's still not really "production quality". While the
>>> underlying protocol for SMTP is straightforward, I think things run
>>> aground owing to the teams initially underestimating the number of
>>> rfcs and protocol extensions that you are essentially *required* to
>>> support (especially wrt authentication etc) to have a production level
>>> server; and also the storage issues such as the user directory and
>>> message store.
>>> There's no reason it couldn't be done, of course, but there's a lot of
>>> moving parts that need to come together to make it a real production
>>> competitor to the venerable sendmail or servers like MS exchange.
>>> As far as Erlang is concerned, it's hard to see it happening until
>>> certain requisite libraries are mature. For instance, START_TLS is
>>> still not "easy" in erlang owing to the long, and continuing, struggle
>>> to get good TLS protocol support.
>>> Assuming that does get "finished" (and there's a whole raft of crypto
>>> work still to do), perhaps a good start towards such a goal would be
>>> to integrate, at the very least, an LDAP client into the base
>>> libraries...
>>> ok before I ramble too much, I'll leave my 2c there.
>>> regards,
>>> /s
>>> On Jan 29, 12:56 am, Roberto Ostinelli<robe...@REDACTED>  wrote:
>>>> dear list,
>>>> are you aware of any existent production-ready SMTP server in Erlang?
>>>> I've
>>>> only found, maintained:https://github.com/Vagabond/gen_smtp
>>>> thank you,
>>>> r.
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

More information about the erlang-questions mailing list