normanmaurer / niosmtp Goto Github PK

I've been using this library in production for about a year now with almost no issues. Thanks for writing this great library!

Recently, I noticed some emails were failing with a 500 error code ("5.3.3 Unrecognized command"). Upon inspection of the actual packets being sent outbound to the mail server, I noticed the SMTP commands in the pipeline requests were being split mid-command.

Pipleline Message 1 (approx 2780 bytes)

MAIL FROM:<server.com>\r\n
RCPT TO: \r\n
RCPT TO: \r\n
. . .
RCPT TO: <user 91>\r\n
RCP

Pipleline Message 2 (approx 350 bytes)

T TO: <user 92>\r\n
. . .
RCPT TO: <user 100>\r\n
DATA\r\n

Notice the last command from the first pipeline message ("RCP") and the first command from the 2nd pipeline message ("T TO: \r\n") are being split up. The remote mail server is interpreting these as invalid commands.

How can we ensure the SMTP commands remain whole in Netty 4? I looked at the SMTPClientPipelineInitializer and I didn't see anything suspicious.

When the SMTPClientFutureListener get notified about a ready future its needed to make sure an unchecked Exception is cached if its thrown while execute the listener. Otherwise this may lead to a situation were not all added listeners get executed

As Netty 4.0.0 is getting more stable it would be nice to use it. Eat your own dogfood ;)

At the moment when the server supports PIPELINING we just send all the commands that are needed via SMTPClientSession.send(..). This works but does nothing to optimize this. Better would be to pass a SMTPPipeliningRequest to the SMTPClientSession and let it handle in a more performant way

NOTE: This issue was encountered while using the Netty 4.x branch.

I encountered a problem while using SMTPDeliveryAgent with a configuration of PipeliningMode.TRY. Our exchange mail server has a whitelist of allowed IPs, and if not allowed the server responds to EHLO request with a "530 5.7.1 Client was not authenticated" response. In my development environment, I encountered this scenario and was surprised that the SMTPClientFuture never completed. This problem is specific to PIPELINING as when I use PipeliningMode.NO, everything works OK and the future is completed.

I think I have tracked down the issue to be within the NettySMTPClientSession#addCollectionFutureHandler, where if a 530 is encountered (which short-circuits the other expected responses from RCPT, DATA, etc), the expected 'responsesCount' is never reached and thus never removes itself from the pipeline.

When using NioSmtp to send a group of e-mails via the SMTPDeliveryAgent, the agent allows processing the results of the sends via a SMTPClientFuture<Collection<FutureResult<Iterator<DeliveryRecipientStatus>>>> that is returned on the call to deliver.

However, DeliveryRecipientStatus gives almost no contextual information to allow the caller to match up the results with one of the original messages sent. The envelope recipient can be obtained, but that may not be unique -- it is possible the group of e-mails that is being sent contained two e-mails with the same recipient.

If the server supports PIPELINGING we should make use of it by send more then one command at the same time

Currently NIOSMTP will happily open any number of connections to a single host. We should have the ability to limit the number of connections that NIOSMTP makes to each host.

Create an implementation of javax.mail.Transport that would use niosmtp underneath?

At the moment the SMTPClient api only supports to send one message per connection. Creating a connection can have some overhead so it would be nice to allow to send more then one message per connection if needed

During testing I saw that if the SMTP server closes the connection in the middle of an SMTP transaction, niosmtp never executes the SMTPClientFutureListener.operationComplete method.

I am investigating how to fix this with an extra component in the Netty pipeline to detect this condition.