Java mail API produces segmented IP packet avoiding EHLO to SMTP

Question

we are currently experiencing a rather strange problem with a JavaMail application running inside a Tomcat 7 container. The Java Mail API is used in a classic way and not too fancy (just send email notification, no attachments etc.). In the testing environment, this code successfully sends email to a MSExchangeServer.

The application is running on a Xen Hypervisor, guest is Windows 2008R2, the Xen and Windows versions are the same for test and production. We are running on JDK7u17 (latest, downloaded yesterday).

The communication with the SMTP server breaks on the EHLO/HELO phase with

javax.mail.MessagingException: Failure sending HELO command to SMTP server

We have then tried to send email using the blat commandline utility this works.

We have tried with putty, and we can reproduce the issue when connecting to the mailserver using putty in telnet mode, if connecting with putty in RAW we can send the EHLO command.

So, we added a sniffer into the game and recorded the following (reproducable) failing session session data:

00000000  32 32 30 20 2a 2a 2a 2a  2a 2a 2a 2a 2a 2a 2a 2a 220 **** ********
00000010  2a 2a 2a 2a 2a 2a 2a 2a  2a 2a 2a 2a 2a 2a 2a 2a ******** ********
00000020  2a 0d 0a                                         *..
00000000  45                                               E
00000001  48 4c 4f 20 53 52 56 2d  46 50 53 2d 30 32 0d 0a HLO SRV- FPS-02..
00000023  35 30 32 20 75 6e 69 6d  70 6c 65 6d 65 6e 74 65 502 unim plemente
00000033  64 20 28 23 35 2e 35 2e  31 29 0d 0a             d (#5.5. 1)..
00000011  48                                               H
00000012  45 4c 4f 20 53 52 56 2d  46 50 53 2d 30 32 0d 0a ELO SRV- FPS-02..
0000003F  35 30 32 20 75 6e 69 6d  70 6c 65 6d 65 6e 74 65 502 unim plemente
0000004F  64 20 28 23 35 2e 35 2e  31 29 0d 0a             d (#5.5. 1)..
00000022  51                                               Q
00000023  55 49 54 0d 0a                                   UIT..
0000005B  35 30 32 20 75 6e 69 6d  70 6c 65 6d 65 6e 74 65 502 unim plemente
0000006B  64 20 28 23 35 2e 35 2e  31 29 0d 0a             d (#5.5. 1)..

Remark, that the EHLO command is split in two segments.

Now we recorded a session with blat:

00000000  32 32 30 20 2a 2a 2a 2a  2a 2a 2a 2a 2a 2a 2a 2a 220 **** ********
00000010  2a 2a 2a 2a 2a 2a 2a 2a  2a 2a 2a 2a 2a 2a 2a 2a ******** ********
00000020  2a 0d 0a                                         *..
00000000  45 48 4c 4f 20 73 72 76  2d 66 70 73 2d 30 32 0d EHLO srv -fps-02.
00000010  0a                                               .
00000023  32 35 30 2d 72 65 6c 61  79 2e 6d 65 64 69 61 6e 250-rela y.median
00000033  65 74 2d 77 6f 72 6c 64  2e 64 65 0d 0a 32 35 30 et-world .de..250
00000043  2d 50 49 50 45 4c 49 4e  49 4e 47 0d 0a 32 35 30 -PIPELIN ING..250
00000053  20 38 42 49 54 4d 49 4d  45 0d 0a                 8BITMIM E..

As you can see, the EHLO is not on a package boundary and thus the server replies with 250-...

We have tried another mailserver to see, if the mailserver recv function is possibly broken, but the other server exhibited the same behavior.

We have now realized that another JavaMail application is able to send mail over the exact same mailserver. On the first glance there is no difference in code, but the other application is using JavaMail 1.3, while the failing one uses JavaMail 1.4 (taken from Geronimo 1.4 -1.7.1).

Any ideas, why the packet segmentation has an influence on the mailserver? In my view, I shouldn't care about the IP packet segmentation when communicating with TCP.

Any help appreciated, thanks in advance!

Thomas

Answer 1

we were able to solve the issue, the main reason are the geronimo libs. Should have checked the maven central better :-(

We have now switched to javax.mail.mail:1.4 and this fixed the issue.

For the record:

The communication FAILED using:

        <dependency>
            <groupId>org.apache.geronimo.specs</groupId>
            <artifactId>geronimo-activation_1.1_spec</artifactId>
            <version>1.1</version>
        </dependency>
        <dependency>
            <groupId>org.apache.geronimo.specs</groupId>
            <artifactId>geronimo-javamail_1.4_spec</artifactId>
            <version>1.7.1</version>
        </dependency>
        <dependency>
            <groupId>org.apache.geronimo.javamail</groupId>
            <artifactId>geronimo-javamail_1.4_provider</artifactId>
            <version>1.8.3</version>
        </dependency>

The communication WORKS using:

<dependencies>
    <dependency>
        <groupId>javax.mail</groupId>
        <artifactId>mail</artifactId>
        <version>1.4</version>
    </dependency>
</dependencies>

Thank you for your time, maybe this will help someone else in the future. At least I could tell myself that my time was well invested :-)

Best regards,

Thomas