У нас есть устаревшее веб-приложение, созданное на Java 1.7, mail1.4.jar и развернутое в Tomcat 7. При отправке письма с вложением в SMPT (сейчас все перемещается в облако Microsoft) мы получаем ошибку ниже.
javax.mail.MessagingException: невозможно отправить команду на SMTP-хост; вложенное исключение: javax.net.ssl.SSLHandshakeException: нет подходящего протокола (протокол отключен или наборы шифров не подходят) по адресу com.sun.mail.smtp.SMTPTransport.sendCommand(SMTPTransport.java:1420) по адресу com.sun.mail.smtp.SMTPTransport.sendCommand(SMTPTransport.java:1408) по адресу com.sun.mail.smtp.SMTPTransport.ehlo(SMTPTransport.java:847) по адресу com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:384) в javax.mail.Service.connect(Service.java:297)
Получение всех сведений из файла свойств и установка объекта свойств, например, SMPT.HOST: office365, SMPT.PORT: 587, SMPT.AUTH=true и т. д. Детали ПФБ.
Фрагмент кода:
final String username = ConfReader.getPropertyValue("mail.username");
final String passwd = ConfReader.getPropertyValue("mail.password");
from = ConfReader.getPropertyValue("mail.from");
String port = ConfReader.getPropertyValue("mail.port");
Properties props = new Properties();
props.put("mail.smtp.host", ConfReader.getPropertyValue("mail.smtp.host"));
props.put("mail.smtp.auth", "true");
props.put("mail.smtp.port", port);
props.put("mail.smtp.starttls.enable", "true");
props.put("mail.debug", "true");
Session session = Session.getInstance(props, new Authenticator() {
@Override
protected PasswordAuthentication getPasswordAuthentication() {
LogWriter.logErrorMessage("username :: "
+ username + "passwd ::"+passwd);
return new PasswordAuthentication(username, passwd);
}
});
Message message = new MimeMessage(session);
try
{
message.setFrom(new InternetAddress(from));
final InternetAddress[] toAddress =
InternetAddress.parse(toEmails);
final InternetAddress[] ccAddress =
InternetAddress.parse(ccEmails);
message.setRecipients(Message.RecipientType.TO, toAddress);
message.setRecipients(Message.RecipientType.CC, ccAddress);
message.setSubject(subject);
/*
* Multipart to create the mail content.
*/
final Multipart multipart = new MimeMultipart();
/*
* html body part to set in multipart
*/
final MimeBodyPart htmlBodyPart = new MimeBodyPart();
htmlBodyPart.setContent(htmlBody, "text/html");
multipart.addBodyPart(htmlBodyPart);
/*
* source to read attachment content
*/
DataSource source =
new ByteArrayDataSource(bytes, "application/excel");
/*
* MimeBodyPart to hold the attachment content.
*/
MimeBodyPart attachmentBodyPart = new MimeBodyPart();
DataHandler handler = new DataHandler(source);
attachmentBodyPart.setHeader("Content-Disposition",
"attachment;filename = " + attachmentName);
attachmentBodyPart.setDataHandler(handler);
attachmentBodyPart.setFileName(attachmentName);
multipart.addBodyPart(attachmentBodyPart);
message.setContent(multipart);
/*
* following line to send email, if it fails, corresponding catch
* block executes, which is logged to let know user if any error
*/
Transport.send(message);
}
catch (AddressException e)
{
/*
* email sending failed, logging the information
*/
LogWriter
.logErrorMessage("Address Exception : " + e.getMessage());
}
catch (MessagingException e)
{
/*
* email sending failed, logging the information
*/
LogWriter.logErrorMessage("Messaging Exception : "
+ e.getMessage());
}
Мы попробовали варианты ниже
Мы обновили Mail.14.7.jar
добавлены ниже свойства в коде props.put("mail.smtp.starttls.enable", "true"); props.put("mail.debug", "истина");
удалено свойство безопасности «jdk.tls.disabledAlgorithms» в папке jre файла java.security, установленной на развернутом сервере.
Изменил порт: 25 и сделал "mail.smtp.starttls.enable" = true.
добавлены ниже свойства в коде props.put("mail.smtp.ssl.protocols", "TLSv1.2"); props.put("mail.smtps.ssl.protocols", "TLSv1.2");
Но тем не менее мы сталкиваемся с той же проблемой.
Не могли бы вы помочь нам предложить любое другое решение, которое решит эту проблему.
Заранее спасибо.
Это приложение отлично работало два месяца назад, сейчас оно не работает. Мы не изменили ни версию Java, ни версию почтового jar-файла. Как вы упомянули, если он не поддерживает набор шифров. С любой настройкой конфигурации мы можем заставить это работать? В настоящее время мы не можем обновить версию Java, поскольку получаем множество ошибок компиляции, поскольку приложение использует старые классы и пакет, которые не поддерживаются в последней версии Java.
Провайдеры регулярно обновляют безопасность своих систем и могут прекратить поддержку старых протоколов и наборов шифров, которые считаются небезопасными. Обычно клиент обязан быть в курсе событий. В этом случае вопрос не содержит достаточно подробностей, чтобы понять, в чем заключается конкретная проблема. Я рекомендую включить больше протоколов SSL в Java и протестировать новые версии Java, Tomcat и любые необходимые библиотеки.
Большое спасибо. Мы выполнили шаги, о которых рассказал Конор О'Нил в комментарии ниже. Теперь это работает.
У меня была аналогичная проблема в прошлом. Как уже говорили другие, это может тонко зависеть от самых разных вещей.
Изменения, которые я внес в то время и которые сработали для меня, заключались в том, чтобы установить для свойства mail.smtps.ssl.protocols
значение TLSv1.2
(как вы уже сделали), но мне также пришлось изменить версию библиотеки javax.mail
:
старая версия javax.mail:mail:1.4
новая версия: com.sun.mail:javax.mail:1.6.2
[Да, теоретически это неоптимально, поскольку теперь вы используете конкретную версию реализации вместо общего API. Но с прагматической точки зрения в таких обстоятельствах, как мои и ваши, это может быть необходимо.]
Я знаю, что javax.mail
API устарел и заменен более новой библиотекой, но вам почти наверняка потребуются другие изменения исходного кода при переходе на замену jakarta.mail
библиотеки.
Мы последовали тому же, и теперь все работает нормально. Спасибо за помощь.
Вы пробовали использовать текущую версию Java? Поддержка Java 1.7 прекращена с 2015 года. Вероятно, она не поддерживает текущие наборы шифров. Кроме того, использование такой старой неподдерживаемой версии представляет собой большой риск для безопасности.