voodoodyne / subethasmtp Goto Github PK

There are three calls to String.getBytes which use the default locale and 
relate to SMTP keywords. It is safer to explicitly specify the required 
character set (US-ASCII). At least it limits the effect of unexpected 
problems.

http://code.google.com/p/subethasmtp/source/browse/trunk/src/main/java/org/subet
hamail/smtp/command/DataCommand.java#81

After receiving the DATA portion of an email, DataCommand.execute calls 
sess.resetMessageState() which sets Session.helo to null.  This means that 
subsequent received emails in the same session get "Received: from null" in 
their headers, instead of "Received: from <hostname>".

There is already a property that allows for setting requireTLS=false. 
There is also a property for displayTLS={true|false}.
Some people, even if using TLS, want to suppress advertising that fact, and
displayTLS=false will do that.  But if the client sends STARTTLS,
subethasmtp will switch to TLS.  
Other people do not wish to use TLS (e.g. internal use and wanting to avoid
configuring TLS/SSL, certificate, etc.).  
Setting both these properties:
requireTLS=false and displayTLS=false 
...allows them to use subethasmtp without configuring TLS.
However, if the client sends a STARTTLS, subethasmtp attempts to switch to
TLS regardless of the value of requireTLS, and an exception results if TLS
has not been configured.

I've modified subethasmtp to support a third property:  allowTLS.
When set to false, this property results in subethasmtp returning a 454
response to the STARTTLS command, thereby avoiding the exception when TLS
is not configured.

I'd like to propose this change as an enhancement for subethasmtp.

For our archiving application we make the assumption, that emails are kept 
identical each time they are delivered through SMTP and no information is 
added. This is broken for us since 3.1. 

A patch is included, which preserves the default behavior.

The attached patch provides a simple timeout mechanism in the SMTPClient 
class. I have run into a relatively popular mail service, libero.it, which 
has at least two MTAs behaving incorrectly. They also have several good 
ones. The bad MTAs wait before sending the welcome message until the 
client sends at least a single character. But the client of course won't 
send any character, because it is waiting for the welcome message. The 
connection hangs forever. The patch works according to my test: SMTPClient 
timeouts, and the server eventually finds a good libero.it MTA.

RFC 5321 recommends configurable and different timeout values, depending 
on the command. The patch is more primitive, it applies the longest of 
these timeout values, 10 minutes. If it becomes necessary, it wouldn't be 
difficult to create an interface covering the timeout mechanism, following 
the Strategy pattern. An implementation could check the command to be 
sent, and if it recognizes it, then it sets the SO_TIMEOUT accordingly, 
otherwise it sets a default value.

The patch also sets the connection timeout, this is only for completeness, 
as I see it does not really necessary. Windows timeouts within a few 
seconds, Ubuntu after 3 minutes. So the set value, 5 minutes, never kicks 
in. 

patch attached

What steps will reproduce the problem?
Because there's no way to replace the creation of the initial client socket its 
nearly impossible to extend the SmartClient to use SSL. 

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
3.1.5

Please provide any additional information below.
I've attached a modified version of SMTPClient with a new public method called 
"Socket createSocket()" which allows overriding when SSL is used. This should 
also make it easier to support STARTTLS from the client side as well.

Both RFC 5322 and the comment in the code 
(org.subethamail.smtp.io.ReceivedHeaderStream) specifies a textual month 
in the date. Currently numeric month is used.

A patch is attached agains the current trunk (344).

The day name is printed in the default locale, while RFC 5321 mandates 
specific English names. For example if the locale of the server is 
Hungarian isntead of "Mon" a "H" is displayed.

Logger instances are stored in static fields in SubEthaSMTP. This was the 
standard practice (although not with SLF4J), because it is a bit faster and 
requires less memory. On the other hand, it causes inconvenience when using 
JMockit, see http://code.google.com/p/jmockit/issues/detail?id=103 . Static 
loggers are also problematic if the library is shared by more web applications. 

I believe in an IO related library like SubEthaSMTP the performance and memory 
advantages are negligible. I use instance loggers in much finer grained 
objects, without any noticeable effect. If you agree, I prepare a patch which 
converts static to instance log variables.

This is a feature request.

For my current project client certificates are required. However, it is
currently not possible to configure this.

The attached path makes it possible to override the creation of the SSL
socket. This enables one to configure the SSL handshake without too much
hassle for normal operation.

The patch was hand modified to remove changes from the path of issue 19.
Please let me know if I should create another patch, if issue 19 has been
committed.

Wiser class has a Close method.

It would be handy for it to implement the Closeable interface, to allow
"automatic" management on the close.

BTW, JDK 7 may as well introduce Disposable (cf
http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000011.html)
for a better usability.

As you're well aware subethasmtp creates a new thread for each incoming mail 
message.

I wanted to use a custom ExecutorService I have with subethasmtp, because of 
the JMX metrics the ExecutorService I have exposes.
Secondarily, it may (or may not) be of benefit to reuse threads.

To do so I created a patch, which is attached.

I've used it for a mail proxying (no disk IO involved) at up to 200 concurrent 
threads with 150 messages per second and it seems to work well so far.

Side note: This was using JRE 7u1.  JRE 6_26 seemed to leak off-heap memory 
~~for my application~~ before and after this patch.

Cheers,
Eric

[deleted issue]

The current PlainAuthenticationHandlerFactory always assumes that the first 
character is null, i.e. that there is no authorization identity provided. Some 
clients including postfix will pass an authorization identity, which will 
totally break the handler.

Have attached a patch that processes according to spec, causing no breakage. 
Future implementations can consider whether storing/passing along authorization 
identity would be useful -- for now I kept it low-impact and it just ignores it.

What steps will reproduce the problem?
1. The built in System.Net.Mail.SmtpClient in .NET always issues its AUTH LOGIN 
command with the username (base64 encoded) as part of the same command. I can't 
find a spec that says they can do this - but it's built into the .NET libraries 
since 2.0 so it seems like a good idea to be able to support it (I need to in 
my server).

The .NET client does this:
AUTH LOGIN c29tZVVzZXJuYW1l

Instead of issuing a:
AUTH LOGIN
and then waiting for the:
334 VXNlcm5hbWU6

What version of the product are you using? On what operating system?
3.1.6

Please provide any additional information below.

I've modified LoginAuthenticationHandlerFactory.auth() to look for the username 
in the AUTH LOGIN command and then use that and issue a challenge for the 
respone. I've attached my modified version of the source file.

At least the Turkish locale converts ASCII characters in different way 
then the English locale. There are a few toUpperCase calls in the code 
which relies on the system locale. For example if a server runs under 
Turkish locale the command "mail" will not be accepted, becaue "i" is 
converted to another character then ASCII "I".

RT.

I hava implements a wrapper to fix it. I think this is a big problem.

CharTerminatedInputStream, which is used in the DATA command, removes the CRLF 
ending of the last line of the message body. This is incorrect, actually it (or 
some other class) should add a CRLF if it is missing. See RFC 5321 4.1.1.4. 
second paragraph.

I attach a test case, which currently fails on the second assertion.

This is a feature request.

When issue 19 and 20 are implemented, and client authentication is
requested, it would be useful to have access to the client certificates.

The attached patch contains:
- changes for issue 19 (Add option to require TLS)
- changes for issue 20 (Add ability to override ssl socket creation)
- changes for this issue
- replaces all indentation spaces with indentation tabs

We have shared continuous integration servers and we want to use subetha smtp 
as mock mail server. IN order to not clash with ports in other projects we use 
port 0 for all our ports in tests so that they JVM will bind to any free port 
and then we pass a reference to the resolver port. For example in Spring I 
would like to be able to do:

    <bean id="mailSender" class="org.springframework.mail.javamail.JavaMailSenderImpl">
        <property name="host" value="#{mockSMTPServer.server.hostName}" />
        <property name="port" value="#{mockSMTPServer.server.port}" />
    </bean>

    <bean id="mockSMTPServer" class="org.subethamail.wiser.Wiser" init-method="start">
       <property name="port" value="0" />
    </bean>

Unfortunately #{mockSMTPServer.server.port} will report 0 back to me still 
because it doesn't take into account the port the JVM resolved to. This could 
be solved in one of two ways:

1. Expose the ServerSocket via a getter in SMTPServer, then the above config I 
showed would look like:

    <bean id="mailSender" class="org.springframework.mail.javamail.JavaMailSenderImpl">
        <property name="host" value="#{mockSMTPServer.server.hostName}" />
        <property name="port" value="#{mockSMTPServer.server.serverSocket.localPort}" />
    </bean>

    <bean id="mockSMTPServer" class="org.subethamail.wiser.Wiser" init-method="start">
       <property name="port" value="0" />
    </bean>

2. Change the implementation of SMTPServer.createServerSocket to be:

    protected ServerSocket createServerSocket() throws IOException {
        InetSocketAddress isa;

        if (this.bindAddress == null) {
            isa = new InetSocketAddress(this.port);
        } else {
            isa = new InetSocketAddress(this.bindAddress, this.port);
        }

        ServerSocket serverSocket = new ServerSocket();
        // http://java.sun.com/j2se/1.5.0/docs/api/java/net/ServerSocket.html#setReuseAddress(boolean)
        serverSocket.setReuseAddress(true);
        serverSocket.bind(isa, this.backlog);

        if (this.port == 0) {
            this.port = serverSocket.getLocalPort();
        }

        return serverSocket;
    }

What steps will reproduce the problem?
1. Starting the server
2. Starting a new instance

What is the expected output? What do you see instead?
The expected output is an error message, saying port is already in use.
Instead, the server starts normally.


What version of the product are you using? On what operating system?
subethamail.smtp.server.SMTPServer version 3.1.6 Windows 32-bit

Please provide any additional information below.
I'm developing in Eclipse, I'll start it once, and then start it again after 
modifying my code not thinking about it. Then my messages won't be received, 
since I have an underlying server running.
I would expect an error message telling me the socket could not be binded, as 
that's what is spat out when you try to create a TCP ServerSocket that's 
already being used.

Bad guys don't terminate the connection with a QUIT command, but simply 
disconnect when they see that they have no luck with the server. This is 
so frequent that it fills my log. Its logged on warn level, but until 
recently only if debug logging was switched on. In any case I don't want 
to see a stack trace even on debug level. Because of its regular 
appearance, this is something like a pseudo SMTP statement. Moreover, in 
such cases not one but two events are logged, it is a bit misleading 
(SubEthaSMTP tries to send an error message).
The attached patch logs these events separately. The logging event does 
include the exception for safety, but filtering the unique message text 
the logger can and should be configured to strip the stack trace.

The SmartClient constructor calls the SMTPClient constructor, which opens a TCP 
socket. If the server responds with an error message in place of the welcome 
message, or the welcome message is syntactically invalid, or if it sends an 
error to HELO, etc., then the SmartClient constructor leaves the exception to 
go up, but does not close the TCP connection or issue a quit command. 

Erik van Oosten ✆ to smtp
show details 12:37 AM (10 hours ago) 
Hi,

I just found out that I accidentally excluded a test case in the TLS patch.
Here it is.

Regards,
   Erik.

Subethasmtp should support the SIZE extension. I've implemented the
following, please see the attached patch:
- Server: Have an int field that specifies the maximum size of the message.
- EHLO command: Advertise the maximum message size of the server if it's
larger than 0.
- MAIL command: Parse the parameters. If it contains a SIZE parameter,
compare it to the server max and reject the message if larger.
- Implement unit tests. Regression/Bug in "invalid adress" fixed.
- Session: Remember the value the client has given.

I believe the parsing of the MAIL FROM argument was wrong, I corrected it
in EmailUtils. I hope the comments in the code are helpful.

I would like to know what the maintainers think about this code.
Furthermore I would like to make the SIZE argument available to the API
user (MessageHandler). The user can then reject the message for specific
recipients (see RFC 1870).
Idea: Extend MessageHandler to include a callback in case the client
supplies a SIZE parameter.

Plus the Data Command could be made aware of the maximum message size
(server default and user supplied) and reject the message if it is too large. 

Comments welcome!

http://www.subethamail.org/se/archive_msg.jsp?msgId=59719

Hi everyone,

Great project!
I'm pretty sure that ReceivedHeaderStream.read(byte[] b, int off, int  
len) works incorrectly when off > 0.
If you try the following code:

    int BUF_SIZE = 10000;
    int offset = 10;
         ByteArrayInputStream in = new ByteArrayInputStream("hello  
world".getBytes());
         ReceivedHeaderStream hdrIS = new ReceivedHeaderStream(in,  
"ehlo", InetAddress.getLocalHost(), "foo");
         byte[] buf = new byte[BUF_SIZE];
         int len = hdrIS.read(buf, offset, BUF_SIZE-offset);
         System.out.println(new String(buf, offset, len));

It prints:

  Received: from ehlo (192.168.20.2 [kasper-langers-macbook-pro.local/ 
192.168.20.2])
         by foo with SMTP;
         Thu, 11 Feb 2010 10:14:57 +01hello world

instead of the expected:

Received: from ehlo (192.168.20.2 [kasper-langers-macbook-pro.local/ 
192.168.20.2])
         by foo with SMTP;
         Thu, 11 Feb 2010 10:15:43 +0100 (CET)
hello world

If you change the offset to 0 the output is correct.

FIX:
Change ReceivedHeaderStream:96 from
int additionalRead = super.read(b, countRead, remainder);
to:
int additionalRead = super.read(b, off + countRead, remainder);

Cheers,

-Kasper

What steps will reproduce the problem?
1. Start SmtpServer
2. Connect to the server and issue "MAIL From: test@test" directly
3.

What is the expected output? What do you see instead?
Some sort of a protocol error. HELO or EHLO has to be issued first by the
client as per RFC5321, 4.1.1.1: "In any event, a" client MUST issue HELO or
EHLO before starting a mail transaction.

What version of the product are you using? On what operating system?
3.0, Linux, JRE1.6

Please provide any additional information below.
I was drawn to the project by its bold claim:"We hate reinventing wheels.
This should be the LAST FREAKING JAVA SMTP IMPLEMENTATION." The last one
should really implement the protocol well.

I'm also missing hooks for each command in the SMTP dialogue.

In my application, I need to accept multiple mails, store them to database, and 
sync changes to disk. So, I need not just MessageHandlerFactory, but also 
something like ConnectionHandlerFactory with methods like connect, disconnect.

Could someone please tag the correct revisions for Versions > 3.0, or. at
least, the current stable Version 3.1.1? Thanks!

This prevents using RejectException to provide custom SMTP error code.

Any chance we could get 3.0 published to the central Maven repository?  Thanks!

If several SMTP sessions are running at the same time 
it is difficult to relate the different statements and 
replies to a single session in the log file.  
The attached patch seems to be the simplest solution 
to this issue. It assigns a unique name to each 
Session thread. By configuring the logging system to 
include the thread name in log entries the problem is 
solved.

Another solution could be to use MDCs of the logging 
system. Neither of these exclude the other.

What steps will reproduce the problem?
1. running the JARs with JDK 1.5 does not work

What is the expected output? What do you see instead?
I expect to use the JARs with Java 1.5.
Instead I get class version errors.

What version of the product are you using? On what operating system?
the latest on windows

Please provide any additional information below.
The source is JDK 1.5 compliant but the binaries are compiled with JDK 1.6.
Please compile with JDK 1.5.

Thank you.

Attached patch will add the option to require TLS.

Currently the debug log doesn't contain information about the client. The 
attached patch logs the ip address and host name of the client when it is 
connecting to the SubEthaSMTP server.

If more then one SMTPServer instances are running in the same process, 
then it is impossible to differentiate between them. 
The attached patch contains the following changes:
-servers are identified by a string consisting of an interface address and 
a port 
-starting and stopping log messages are complemented with the above server 
name. Actually in case of the started and stopped message this is 
redundant (see MDC later), but it was symmetric this way.
-the missing "started" log message is added
-an SLF4J MDC variable is set to the above server name. This is valid not 
only in the server threads but in child (client connection) threads too. 
The variable should be included in the log layout.

(I run into an unrelated obsolete comment in Session.java, and updated it 
too)

The attached patch adds SMTP conversation logging to 
SMTPClient. SMTP statements, responses, connection, 
disconnection are logged on debug level, exactly like 
in Session.

The method Wiser.getMessages() returns a reference to the internal array of 
messages. This can be demonstrated with the following unit test added to 
MessageContentTest

    public void testDoesNotExposeInternalRep() throws Exception
    {
        MimeMessage message = new MimeMessage(this.session);
        message.addRecipient(Message.RecipientType.TO, new InternetAddress("[email protected]"));
        message.setFrom(new InternetAddress("[email protected]"));
        Transport.send(message);
        List<WiserMessage> messages = this.wiser.getMessages();
        assertFalse(messages.isEmpty());
        messages.clear();
        assertFalse(this.wiser.getMessages().isEmpty());
    }



This problem is also related to issue 37, in that the client currently needs to 
synchronize on the reference to lower the risk of 
ConcurrentModificationException when iterating the list. If issue 37 is fixed 
by using CopyOnWriteArrayList or similar, then getMessages could be fixed as 
follows.

public List<WiserMessage> getMessages()
    {
        return new ArrayList<WiserMessage>(this.messages);
    }

(However, if the synchronized wrapper class is used as present then the copy 
code needs to in a block synchronised on this.messages).

What steps will reproduce the problem?
1. Simply process an email

First invocation of done() handler:
Thread [org.subethamail.smtp.server.Session-/127.0.0.1:52903] (Suspended 
(breakpoint at line 41 in MessageHandlerImpl))  
    MessageHandlerImpl.done() line: 41  
    Session.endMessageHandler() line: 467   
    Session.resetMessageState() line: 451   
    DataCommand.execute(String, Session) line: 81   
    RequireTLSCommandWrapper.execute(String, Session) line: 27  
    CommandHandler.handleCommand(Session, String) line: 98  
    Session.runCommandLoop() line: 222  
    Session.run() line: 125 

Second invocation of done() handler:
Thread [org.subethamail.smtp.server.Session-/127.0.0.1:52903] (Suspended 
(breakpoint at line 41 in MessageHandlerImpl))  
    MessageHandlerImpl.done() line: 41  
    Session.endMessageHandler() line: 467   
    Session.run() line: 164 

Note: The second invocation is actually done on a NEW instance of the handler 
since a Session.resetMessageState() invocation happened in between the two 
calls above.

The second invocation is obviously unnecessary.

What version of the product are you using? On what operating system?
Mac OSX
subethasmtp v3.1.6

What steps will reproduce the problem?
1.start wiser
2.send large number of message to wiser
3.check wiser memory

What is the expected output? What do you see instead?
expected:  wiser memory usage is normal.
acturally: wiser used too much memory and restart about an hour

What version of the product are you using? On what operating system?
subethasmtp 3.1 on RedHat Enterprise 5.3

Please provide any additional information below.

Is there any chance to implement this feature in future? My problem is that
subethasmtp do not answer "250-DSN" to the EHLO command so i can't forward
the "rcpt to: [email protected] notify=success, failure" Header to another SMTP
Server. Thats the only reason, i need this DSN Support. Maybe, someone has
another solution for my problem.

Regards,
Rob

Our application process accept e-mail using subethasmtp, extract text using 
apache tika and index it with lucene. But profiler show, that a lot of time 
spent in subethasmtp socket reading (about 50% of total time, tika takes just 
17%, for example). 

Is the any way to improve socket handling performance ? 

PS. We use Linux x64, 8 cores, 24 GB RAM.

The documentation claims that the only dependency is slf4j, but this is false. 
org.subethamail.smtp.util.EmailUtils depends on javax.mail.internet classes, 
which are in mailapi.jar.

This was hard to find because Session.run() doesn't catch and log exceptions - 
the thread just silently dies.

DEBUG - Client: MAIL FROM:<[email protected]> SIZE=431
Exception in thread "org.subethamail.smtp.server.Session-/192.168.109.1:44544" 
java.lang.NoClassDefFoundError: javax/mail/internet/AddressException
    at org.subethamail.smtp.command.MailCommand.execute(MailCommand.java:56)
    at org.subethamail.smtp.server.RequireTLSCommandWrapper.execute(RequireTLSCommandWrapper.java:27)
    at org.subethamail.smtp.server.CommandHandler.handleCommand(CommandHandler.java:78)
    at org.subethamail.smtp.server.Session.run(Session.java:149)
Caused by: java.lang.ClassNotFoundException: 
javax.mail.internet.AddressException
    at java.net.URLClassLoader$1.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClassInternal(Unknown Source)
    ... 4 more

SPF uses the helo name for whatever reason. The name is already stored in 
Session. The attached one line plus comments patch makes it accessible 
through MessageContext.

I process a lot of message and after a few hrs application crash with 
OutOfMemory exception in 3.1.4 (I've attached profiler screenshot):

MessageHandler class looks like this:
=
public class MyMessageHandler implements MessageHandlerFactory {

    public MessageHandler create(MessageContext ctx) {
        return new Handler(ctx);
    }

    class Handler implements MessageHandler {
        MessageContext ctx;

        public Handler(MessageContext ctx) {
            this.ctx = ctx;
        }

        public void from(String from) throws RejectException {
        }

        public void recipient(String recipient) throws RejectException {
        }

        public void data(InputStream data) throws IOException {
            Logger logger = LoggerFactory.getLogger(MyMessageHandler.class);
            final IndexImpl ii = new IndexImpl();

            // We cannot read InputStream twice, so convert to ByteArray
            byte[] dataArr = toByteArray(data);
            data.close();

// other code
            } catch (Exception e) {
                logger.error("Cannot save message", e);
                throw new RejectException(450, e.getMessage());
            }
        }


        public void done() {
        }
    }


    private static byte[] toByteArray(InputStream is) throws IOException {
        ByteArrayOutputStream bos = new ByteArrayOutputStream();
        int size;
        byte[] cBuf = new byte[4096];
        while ((size = is.read(cBuf)) != -1) {
            bos.write(cBuf,0,size);
        }
        bos.close();
        return bos.toByteArray();
    }
}
===

The Wiser class does not correctly synchronize access to its messages property, 
resulting in ConcurrentModificationException.

This problem occurs in our automated multi-threaded acceptance tests which use 
Wiser. However this problem can be demonstrated in a single thread by adding 
this test to MessageContentTest. 

  public void testDoesNotThrowConcurrentModificationException() throws Exception
    {
        MimeMessage message = new MimeMessage(this.session);
        message.addRecipient(Message.RecipientType.TO, new InternetAddress("[email protected]"));
        message.setFrom(new InternetAddress("[email protected]"));
        Transport.send(message);
        List<WiserMessage> messages = this.wiser.getMessages();
        Iterator<WiserMessage> iterator = messages.iterator();
        Transport.send(message);
        iterator.next();
        assertEquals(2, this.wiser.getMessages().size());
    }


The simplest fix would be to change the property declaration in Wiser.java to 
    List<WiserMessage> messages = new CopyOnWriteArrayList<WiserMessage>();

Currently there are a few versions up to 2.1.0 in the repository. I don't
know who deployed them. Making newer ones available would spare people of
stumbling over old bugs (2.1.0 has a very, very nasty bug I won't bother to
report, since this version is quite old and the bug is not present in 3.x).

Please let me know if you want my pom.xml for this project.

Make it possible to specify the local socket address to which SMTPClient 
will bind. Currently the wildcard address is used always.

Patch is attached. It adds a new constructor to both SMTPClient and 
SmartClient. Another solution could be to create a non-connecting empty 
constructor and set all parameters in setters and in a new connect method. 
That would be similar to SMTPServer and the Java Socket class, and it is 
preferable if one or more additional parameters are needed. 
It is also interesting that the already supplied helo name usually equals 
the desired bind address.

SubEthaSMTP server implementation creates a thread (Session class) for each 
incoming mail message to read from the open socket.  Session instances are 
tracked by use of a shared ThreadGroup defined in the server instance.  The 
ThreadGroup is using a relatively unsafe method call to activeCount().

From Java's Javadoc for ThreadGroup.activeCount() method:
   "Returns an estimate of the number of active threads in this thread group. The result might not reflect concurrent activity, and might be affected by the presence of certain system threads.  Due to the inherently imprecise nature of the result, it is recommended that this method only be used for informational purposes."

The call to activeCount() is used to determine if too many connections to the 
server exist (based on defined property max connections).  The value returned 
from activeCount() is not reliable and does not work effectively to determine 
if too many connections exist.

This design also has major issues when combined with any sort of 
multi-threading implemented by users of SubEthaSMTP.  For example, a 
MessageHandler instance may pass processing of the inbound message data to a 
thread pool of worker threads, relieving the Session thread to handle the next 
incoming message.  Threads created in the worker pool will by default exist in 
the same ThreadGroup as the Session thread, causing the activeCount() method to 
report the worker thread as a connection thread.  This leaves the server in an 
invalid state.  If threads in the worker pool are not reclaimed after 
performing their work, then the current connection count in the SMTP server 
instance will remain invalid/inconsistent.

In order to test this issue, simple create a MessageHandler implementation 
which spawns a new Thread which continues to run in a loop and then check the 
number of current connections to the SMTP.

One suggested fix is to have the SMTP server manage it's own pool of current 
Session instances, rather than relying on ThreadGroup.  Each created Session 
instance should be registered in a pool, and removed from the pool when 
completed.