| Version |
Bug Id |
Title |
| 1.0.6 |
0343 |
Asterisk in socket binding not handled correctly
When an asterisk occurs as a value in an endpoint binding property, it does not result in the creation of a socket acceptor that listens on all ports. Instead, due to a logic error, it results in an invocation of the resolver library to enumerate addresses matching the host "localhost", and then the first returned address is used for the binding.
The logic error in question is in SocketAcceptorFactory, where the errant code:
if (strBinding != null || !"*".equals(strBinding))
should read:
if (strBinding != null && !"*".equals(strBinding))
|
| 1.0.6 |
0342 |
Local interface binding lookups should not require resolver
When a binding is specified for a network acceptor, the resolver library is invoked via InetAddress to lookup addresses for the host "localhost". This fails on some unix systems when no DNS server is present. JDK 1.4 introduced the NetworkInterface class to enumerate local interfaces and their addresses, which should now be used for this, removing the unnecessary external dependency and associated unnecessary external I/O.
|
| 1.0.6 |
0341 |
TelnetConnectionHandler ignores socket timeout property
The TelnetConnectionHandler class does not correctly load the socket timeout property.
|
| 1.0.5a |
0336 |
No response sent after failure parsing MAIL FROM or RCPT TO args
The SmtpConnectionHandler.handleMail and handleRcpt command handlers correctly have ProtocolException catch blocks in the event that a failure occurs parsing the input stream for a reverse-path or forward-path. However, the catch blocks fail to send the response that they construct, leaving clients waiting upon a command response.
|
| 1.0.5a |
0333 |
FlagsHelper returns null for "system user flag" instead of asterisk
The FlagsHelper.toString method maps JavaMail Flags.Flag objects to strings. This method incorrectly returns null for Flags.Flag.USER, instead of [backslash + asterisk], which would be the correct representation.
|
| 1.0.5a |
0332 |
PropertiesPreferences.node() returns incorrect keys
When PropertiesPreferences is used to return a Preferences object for a child node, that node incorrectly returns invalid keys that contain delimiters and path prefixes.
Bug verified and fix validated with PreferencesHelperUT.testJob0332().
|
| 1.0.4d |
0184 |
endpoint buffer.in and buffer.out properties inoperative
The endpoint properties buffer.in and buffer.out are not being read from the Preferences configuration. The values are defaulting to their hard-coded default size of 4k.
The ConnectionHandler interface has been modified to expose a connection handler's configuration as a 2nd argument to the init(...) method.
All ConnectionHandler implementations need to modify their init method signature.
The ConfProperties class has been deprecated, which contained a bug that was relevant to this issue. The PropertiesPreferences class was able to subsume all the necessary functionality that was provided by ConfProperties.
A buffer inputstream max line length property has been added so that servers may override the RFC recommended 8k max line length.
|
| 1.0.4b |
0323 |
Cannot conveniently access returned SMTP capabilities
The SMTP client library should include a convenient accessor method for examining capabilities returned by the EHLO command.
The SmtpClient.sendEhlo() method returns a new SmtpEhloResponse class, providing convenient access to returned capabilities.
|
| 1.0.4a |
0320 |
Cannot disable TLS manager
The framework advertises that it will not attempt to load a TLS manager when the tls.protocol property is blank or null. Instead, currently the TlsManagerImpl default implementation is being loaded, resulting in confusing logging in servers with no endpoints.
The way the tls.manager property was being read is also corrected, so that a blank value as well as a null value indicates that the default TLS manager should be used.
|
| 1.0.4a |
0317 |
Excessive logging during network errors
When a network error occurs (IOException), the framework logs the exception and includes a stack trace. This is excessive, since the message of an IOException typically contains a fully descriptive summary of the problem, which is rarely if ever a programming error. Stack traces should be reserved for logging unhandled exceptions due to programming errors and the like.
|
| 1.0.4 |
0316 |
I/O performance suffers after STARTTLS
When a STARTTLS is performed, subsequent I/O operations over the secured channel occur in 17-byte blocks (a single byte payload plus the frame header). This can be seen by setting -Djavax.net.debug=all, and then performing an MUA session using the proxy sample server.
Two classes contribute to this problem. Both CounterOutputStream and RedirectingFilterOutputStream fail to extend the write(byte[]) and write(byte[], int, int) methods per J2SE recommendation. This causes the default implementations of those methods in FilterOutputStream to execute, which unwinds the buffer operations into a loop of single-byte write operations, instead of passing the block operation along to the underlying output stream.
|
| 1.0.3g |
0314 |
Proxy sample server's ANT script requires classpathref to ssdklib
When an evaluation distribution is used, the Java/src/sample/proxy sample server makes use of the Java/lib/smtp-ssdk.jar library for necessary classes. The build.xml build script is missing a classpathref to this library, and so "ant clean" followed by "ant" results in compilation errors.
Commercial distributions do not have this problem, since classes are resolved from the Java/classes directory, where they are placed by compilation of sources that are available.
|
| 1.0.3f |
0313 |
Evaluation distribution missing mailservant packages; sample server won't run
The evaluation distribution does not contain the necessary classes to run the proxy sample server. Performing "ant run" in the Java/src/sample/proxy folder results in a NoClassDefFoundError attempting to locate AuthenticateCapable.
The com.goodserver.mailservant.smtp package name was being obfuscated.
|
| 1.0.3e |
0311 |
Connection handler threads need more specific names
Threads created by ConnectionHandlerPool are assigned generic sequential names. They should be given more specific names, like other GoodServer SDK's which incorporate the service short name in the thread prefix, to assist in debugging within a runtime container.
|
| 1.0.3e |
0310 |
Acceptor thread doesn't survive OutOfMemoryError
Under low memory conditions, a service's AcceptorThread falls out of its run loop due to an uncaught Error. This results in the termination of network services. This should be enhanced so that recovery from a low memory event is possible, and new connections can be handled.
|
| 1.0.3e |
0309 |
TelnetInputStream skipToEOL() fails at start of stream
If TelnetInputStream.skipToEOL() is performed on a newly opened stream, it fails to skip any bytes from the input stream. This is due to a faulty initialization state.
|
| 1.0.3e |
0259 |
Network framework consumes 100% cpu
Under certain conditions, the network framework consumes 100% cpu. This has been traced to TelnetInputStream's skipToEOL() method, which reads characters from the input stream until a LF occurs, regardless of whether an end-of-stream occurs in the meanwhile, such as when a client disconnects.
Re-opened due to bug regression. Apparently this bug was never fixed because of a faulty unit test. The unit test TelnetInputStreamUT.testJob0259() method which was used to validate this bug, and to verify its fix, uses skipToEOL() at the beginning of a stream to determine whether that method will hang indefinitely. Bug 0309 has identified a different fault within that method whereby it fails to skip any bytes if it is invoked at the beginning of the stream. The unit test happened to be satisfying that condition, so the test was passing because no attempt was being made to read from the stream at all, since the stream's faulty initialization had it in an end-of-line state.
Re-closed in 1.2.3b.
|
| 1.0.3d |
0307 |
STARTTLS handshake error due to socket in client mode
The STARTTLS implementation in the proxy sample server fails when MUA's attempt to handshake. This has been traced to TlsManagerImpl, which creates a layered socket but fails to set it in server mode. The J2SE SSLSocketFactory creates layered sockets that are in client mode by default.
|
| 1.0.3c |
0298 |
Buffer overflow exceptions caused by rewind buffer
The new mark/reset capability offered by TelnetInputStream causes buffer overflow exceptions when large content is retrieved through the input stream after a mark is performed.
The rewind buffer should be discarded once it fills up, since it will no longer be able to perform a reset().
|
| 1.0.2g |
0284 |
Responses contain extraneous CRLF
Responses to all commands sent by the framework contain a redundant CRLF.
|
| 1.0.2g |
0283 |
HELO/EHLO command causes stack overflow
When the framework receives an EHLO or HELO command, the response generation causes a stack overflow due to recursive logic in the SmtpHelloResponseImpl class's write(Writer) method.
|
| 1.0.2f |
0280 |
SMTP server response sent incorrectly when no message is set
When a SMTP server or proxy sends a command response in which the message is unset, the response code is not transmitted, resulting in a malformed response.
|
| 1.0.2e |
0269 |
SMTP client library fails sending HELO/EHLO argument
The SmtpClient.sendEhlo(String) and sendHelo(String) methods are ignoring the String argument. A code review indicates that this bug was introduced in version 1.0.2b, when the request factory was created as a constructor for requests, including HelloRequest.
|
| 1.0.2c |
0263 |
SMTP client library requires ability to set AUTH initial response
The SMTP client library request factory requires the ability to assign a value for the initial response during an AUTH exchange. This accessibility is required when subclassing the SmtpClient class.
|
| 1.0.2 |
0224 |
SMTP Client Library requires AUTH support
The SmtpClient client library is missing a method to send an AUTH command to the target server, and to then perform the subsequent authenticate handshake.
AUTH support has been implemented in the client library. Two convenience classes are included (AuthenticateLoginClientHandshakeImpl and AuthenticatePlainClientHandshakeImpl), which hide the handshake while offering a convenient constructor that takes (user, pass) arguments. The proxy sample server now implements the AuthenticateCapable interface, and proxies AUTH requests to a target server.
|
| 1.0.1c |
0221 |
HELP argument inoperable
The HELP command should support an optional argument, which it does not.
The help command now supports an optional argument, encapsulated by the HelpRequest class.
The SmtpClient client library now supports sendHelp() and sendHelp(String) methods.
The proxy sample server now implements the HelpCapable interface, and delegates HELP commands to target servers.
|
| 1.0.1c |
0179 |
PropertiesPreferences fails returning intermediate nodes
The PropertiesPreferences class fails enumerating all nodes for a given dotted property set. The property set ("a", "a.b.c") fails to return a Properties node for the intermediary "a.b" node. A workaround is to create a dummy property "a.b = hack" so that the missing node is created.
|
| 1.0.1b |
0254 |
SmtpRecipientRequestImpl loses empty forward path of "<>"
The SmtpRecipientRequestImpl class encapsulates the RCPT TO forward-path argument as a string, but only provides access to this data member with the getAddress() method, which attempts to encapsulate the forward path as a JavaMail InternetAddress. This causes a loss of accessibility to the data when the forward-path is specified as "<>".
The getAddress() method in AddressRequest has been modified to return a String instead of an InternetAddress. SmtpClient has been updated to support String arguments to the sendExpn, sendRcptTo, and sendVrfy methods.
|
| 1.0.1 |
0246 |
TelnetInputStream should throw DisconnectException instead of returning null
When TelnetInputStream detects a disconnect, it should throw a DisconnectException instead of returning null.
|
| 1.0.0h |
0244 |
Server fails to detect client disconnect
Servers and proxies build with the framework fail to detect a client disconnect event. This occurs in the SmtpConnectionHandler.handleCommand() method, when the TelnetInputStream.readLine() method returns null to signal an EOS.
|
| 1.0.0g |
0241 |
Session throws NullPointerException during invalidate()
When the Session.invalidate() method is invoked for a session containing no session attributes, a NullPointerException is thrown.
The exception is caused because this class uses lazy allocation of the attribute map, while the invalidate() method assumes that the attribute map is always allocated.
|
| 1.0.0e |
0229 |
AUTH type argument parse error; whitespace not ignored
When an AUTH command is received, the auth-type parse fails because the parser does not skip the white space between the command and the first argument. This causes a ProtocolException, which also fails to be sent to the client.
|
| 1.0.0e |
0228 |
Input buffer contains CRLF in DATA command handler
When an SMTP connection handler receives a message in the doData command handler, it will typically construct an SMTPInputStream using getInputStream() as the filter stream argument. This input stream contains CRLF as the first two characters in the stream, before the message content. These CRLF characters are the line delimiters for the "DATA" command that has been received.
The framework now performs skipToEOL() on the input stream before any command handlers are invoked that involve continuation.
|
| 1.0.0d |
0226 |
AUTH arguments not separated correctly
When an AUTH command is received containing both auth-type and initial-response arguments, these two arguments are not parsed correctly. Instead, they are both assigned as the auth-type argument, while the initial-response argument remains null.
The SmtpSyntaxParser class now contains an authType() parser for RFC 2554 "auth_type" strings.
|
| 1.0.0d |
0220 |
MAIL and RCPT optional parameters inoperable
The optional ESMTP parameters to the MAIL FROM: and RCPT TO: commands are currently inoperable, due to a recent command parsing overhaul.
|
| 1.0.0d |
0016 |
MAIL command "RET" param not supported
"RET" parameter of the ESMTP MAIL command is not supported yet (RFC 1891).
|
| 1.0.0c |
0223 |
SmtpConnectionHandler.getCapabilities() not called by framework
The SmtpConnectionHandler getCapabilities() method is not being called by the framework. This method should be deprecated, since it is no longer in use. In its place, the SmtpMailServant doEhlo and doHelo methods should define a new SmtpHelloResponse response class interface, which provides assignment and accessor methods for an encapsulated list of server capabilities.
|
| 1.0.0c |
0222 |
SmtpReply class returns numeric response code
The SmtpReply class currently uses a numeric response code. This should be changed to use a class of type ResponseCode, which can also encapsulate an EnhancedStatusCode.
|
| 1.0.0a |
0185 |
Master build script missing from distribution
The master build script (build.xml) is missing from the src/ folder in the distribution zip file.
|
| 1.0.0a |
0180 |
Network listener shutdown synchronization errors
Successive rapid init() and destroy() operations for a service with a socket listener and connected clients results in a NullPointerExceptions being throw from TelnetConnectionHandler's shutdown routines. It appears that AcceptorThread is failing to shutdown the connection handler pool, which would provide the necessary shutdown synchronization.
|
| 1.0.0 |
0154 |
InternetRecipient returns null address
RCPT TO arguments are encapsulated in an InternetRecipient object, which extends the JavaMail InternetAddress class and adds encapsulation for optional RCPT TO arguments. Calling the base class getAddress() method returns null, instead of the RCPT TO internet address argument.
|