Java Email Server 1.6.1 Released

A new version of Java Email Server (JES) is available.

The new version is mostly a cleanup release. However, this release does fix a major issue introduced in version 1.5 that caused issues when used without a default SMTP server.

You can download the new update from the JES homepage:

http://www.ericdaugherty.com/java/mailserver/

10 comments:

  1. Very nice, thank you.

    Do you have any plans to support secure SMTP (STARTTLS)?

    Demetrios.

    ReplyDelete
  2. How secure is JES (I would like to instal on a "www.mydomain.com"?

    I see only these options:

    1. relay.ipaddresses=x.x.x.x
    I can't use this since I (or other users) connect from ppp and the mail client has a different IP address all the time.

    2. relay.emailaddresses=me@mydomain.com
    This is of course a security hole, so it's not an option. You put a warning there, but the fact is that everybody can guess the email address, once one sends the first email. Also in case of a company, usernames like info@ sales@ or support@ are a must, so they're tried by spammers right away.

    3. relay.popbeforesmtp=true and relay.popbeforesmtp.timeout=10
    The problem with this option is that(10 is the right number) but
    if the email address is used allot to send mails, the relay is almost all the time open.
    Also for me is not a problem to config the client to use this option but it is a great problem for the normal users (for some clients this option is also hard to find).

    4. If JES were default secure, I set some security options in the client (like TLS, SSL) the response from the server is error (it doesn't seem to support them).

    I believe JES is wonderfull and very simple, but this shouldn't be to the cost of security.

    Isn't there no other solution to make a JES installation secure?

    Thank you very much,

    Tom.

    ReplyDelete
  3. You are correct about options 1 and 2, they are for specific cases and not great solutions for your case.

    However, on options 3, what this is doing is really dynamically setting option 1 for a limited amount of time. For example, you check your email from 127.0.0.1, JES will then allow relaying for the timeout period from that IP address only. So this option is pretty effective at prohibiting an open relay.

    For option 4, you seem to be talking about something else. TLS will secure the channel, to prohibit main in the middle attacks, etc. but does not impact relaying etc. unless you are suggesting using client certificates.

    ReplyDelete

  4. For example, you check your email from 127.0.0.1, JES will then allow relaying for the timeout period from that IP address only. So this option is pretty effective at prohibiting an open relay.

    The big problem is that many users also work behind another company's proxy , or they have open wireless networks at home, so there are many users with the same IP address :(.


    For option 4, you seem to be talking about something else.

    Well, I'm talking more from the users's perspective (I'm no mail server expert): in most mail clients there are options to make SMTP "secure" too, if I understand right. I suppose if the SMTP server is configured so (like google mail), to allow only secure connections, than it's not an "open relay", like in other cases, right?

    Thank you,

    Tom

    ReplyDelete
  5. Your first point is factually correct, but seems unlikely to be a major concern in the real world. They would need to be malicious, have physical access to the location (house, company), know you use this server, know it is employing this mechanism, etc. These are all 'obscurity' layers, but in the real world the risk seems low.

    I would love to add TLS to JES, but I simply don't have the time. If someone would like to work on it with me, I would be more than happy to guide them.

    ReplyDelete

  6. but seems unlikely to be a major concern in the real world.

    I think it is :(.
    Finding out what server is there it's very simple: You have hardcoded "Received: by Eric Daugherty's JES SMTP ....", and there are not so many email servers out there. A spammer would find out right away that the only scheme that works is popbeforesmtp and target it.
    Also don't underestimate the troians and worms: there are millions of them, so a potential "man in the middle" does not require a physical access (the most of the work I'm doing to the computers of my relatives is to constaly desinfect them :), so this problem is extremly common).


    If someone would like to work on it with me, I would be more than happy to guide them.

    I would be happy to do this but unfrotunately I don't have the required knowhow. I've taken a look at some of RFCs but I really don't get it how were the people able to implement that thing (I mean even simple POP) - I speak english, but those RFC don't look like specifications, nor human tailored :).

    In what I could help you would be a simple and quick web based admin interface: I did one for JAMES, and if you would like one for JES I could make it, just tell me (I suppose the questions I would have would be better on some maling list than here - maybe google groups?)

    Thank you,

    Tom.

    ReplyDelete
  7. I think ConfigurationManager.tokenize() method can be replaced with a simple call to String#split() (so a single line of code).

    Demetrios.
    P.S. Is it OK to post code related messages here? (you mentioned that you're not watching the sourceforge forum).

    ReplyDelete

  8. I would love to add TLS to JES, but I simply don't have the time. If someone would like to work on it with me, I would be more than happy to guide them.

    Do you have any pointers about what would be required to add TLS?
    I would like to take a look at it and see if I could do it, but for the moment (without more details), seems too vague for me to estimate the effort and make a promise.

    Demetrios.

    ReplyDelete
  9. Demetrios,

    Honestly, I looked into it several years ago but I don't really have much for you to start on. There is a STARTTTL command that needs to be supported and then an SSL library would need to be utilized (or is it in the JDK?) to actually encrypt/decrypt the channel.

    ReplyDelete

  10. There is a STARTTTL command that needs to be supported

    OK, but where is it documented?
    Also where should this command act and how?
    Also it's just one command? Nothing more?


    then an SSL library would need to be utilized (or is it in the JDK?) to actually encrypt/decrypt the channel.

    I think the JDK has all the required things for SSL (e.g. Tomcat and other application servers are using this too).
    There seems to be many code examples on how to encrypt/decrypt with java.

    Demetrios.

    ReplyDelete