Le 06/01/2011 23:24, Bill Shannon a écrit :
> 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.
Thanks for replying.
Javamail did actually send the STARTTLS (step 5 above).
The initialization code is pretty simple, always set "mail.smtp.starttls.required",
uses Session.getInstance(props), get the Transport and then connect with host, port,
login and passwd.
My analysis is that in the above steps, at step 12 the server stopped the ssl handshake
and resent a 220 which is ignored by javamail that just goes on with the usual EHLO as
if TLS was completely established.