Gilles Gaillard wrote on 01/06/2011 12:40 PM:
> Hi,
>
> We're using javamail in an application that occasionally needs to send e-mails
> and it's usually just working fine.
>
> However, there's one case where connecting to the smtp server fails with
> javamail although sending the mail succeeds with another app (EmailTest.exe)
>
> Debugging the situation with wireShark shows the following steps - with the
> successful application (c is the client, s is the server):
>
> 1. c -> connect
> 2. s <- 220
> 3. c -> EHLO
> 4. s <- 250-mx.., 250-SIZE, 250-8BIMIME, 250-STARTTLS, 150 ENHANCEDSTATUSCODES
> 5. c -> STARTTLS
> 6. s <- 220 2.0.0 Ready to start TLS
> Here the SSL handshake and key exchange: Note that seems incomplete.
> 7. c -> Client Hello
> 8. s <- Server Hello
> 9. s <- Certificate. Server Hello Done.
> 10. c -> Client Key exchange
> 11. c -> Change cipher spec, Encrypted Handshake message
> 12. s <- 220 mx-..
> 13. c -> EHLO
> 14. s <- 250-mx.., 250-SIZE, 250-8BIMIME, 250-STARTTLS, 150 ENHANCEDSTATUSCODES
> 15. c -> STARTTLS
> 16. s <- 220 2.0.0 Ready to start TLS
> Then the SSL handshake again
> 17. c -> Client Hello
> 18. s <- Server Hello
> 19. s <- Certificate. Server Hello Done.
> 20. c -> Client Key exchange
> 21. c -> Change cipher spec, Encrypted Handshake message
> 22. s <- Change cipher spec, Encrypted Handshake message
> 23. Then the data transmission.
>
> Connecting to the same mail server with javamail gives the following:
> - connecting from the same machine:
> at step 15, instead of starting the TLSS, javamail just send 'mail from' which
> causes the server to refuse.
> c -> MAIL FROM:<xxx_at_yy>
> s <- 539 5.7.0 Must issue a STARTTLS first
> c -> RSET
> - connecting from another machine: works fine. Steps 12 to 21 do not show.
>
> My current guessing is that the TLS handshake failed which the successful
> application worked around by restarting the 'protocol connection'.
> I imagine that would be equivalent to calling again
> SMTPTransport.protocolConnect another time.
> On the other hand it seems that javamail just goes on without detecting the
> issue in the SSL handshake.
If JavaMail is never sending the STARTTLS command, it's probably because
you haven't enabled STARTTLS support by setting the appropriate property.
If you're always sending email to the same server, and some times it's
correctly using STARTTLS, then you should look for some error in your
application logic related to how you manage the Properties object that
the Session is initialized with.
Also, make sure you're using Session.getInstance instead of
Session.getDefaultInstance; the peculiar semantics of the latter can
often be the source of problems such as this.