Назад | Перейти на главную страницу

Приложение JavaMail не отправляет электронную почту на внешний SMTP-сервер

На самом деле это вопрос экзамена, но я считаю, что он может помочь другим в устранении подобной ситуации.

В системе электронная почта должна быть отправлена ​​на определенный почтовый ящик. Для этого был разработан следующий код Java, который является частью более крупной системы. Предположим, что example.com соответствует действительному зарегистрированному интернет-домену.

 public void sendEmail(){

 String s1=”Warning”;
 String b1=”Contact IT support.”;
 String r1=”warning@example.com”;
 String d1=”admin@example.com”;
 String h1=”mx.intranet”;

 Properties p1 = new Properties();

 p1.put(“mail.host”, h1);

 Session session = Session.getDefaultInstance(p1, null);
 MimeMessage message = new MimeMessage(session);

try {
   message.setFrom(new InternetAddress(r1));
   message.addRecipient(Message.RecipientType.TO,
   new InternetAddress(d1));
   message.setSubject(s1);
   message.setText(b1);
   Transport.send(message);
  }
  catch (MessagingException e){
   System.err.println(e);
  }
}

Выполнение этого кода в тестовой среде сервера приложений НЕ работает должным образом. Почтовый ящик сервера example.com никогда не получает письмо, даже если все строковые значения в коде правильно присвоены.

Результат выполнения команды netstat -np TCP на сервере приложений во время выполнения показан ниже:

Src Add         Src Port    Dest Add         Dest Port   State
192.168.5.5  54395      192.168.7.1         25      SYN_SENT
192.168.5.5  54390      192.168.7.1         110     TIME_WAIT
192.168.5.5  52001      200.218.208.118     80      CLOSE_WAIT
192.168.5.5  52050      200.218.208.118     80      ESTABLISHED
192.168.5.5  50001      200.255.94.202      25      TIME_WAIT
192.168.5.5  50000      200.255.94.202      25      ESTABLISHED

За исключением строк, которые были преобразованы в NAT, все остальные связаны с сервером приложений Java, который создал их после выполнения приведенного выше кода.

Сервер электронной почты, используемый в этой среде, является рабочим сервером, который находится в сети и не требует какой-либо аутентификации для внутренних подключений.

Исходя из этой ситуации, укажите три возможных причины проблемы.

Я дал свой шанс следующим образом:

1 - Между подсетью сервера приложений (192.168.5.5) и внутренним почтовым сервером (192.168.7.1) есть брандмауэр, блокирующий порт 25.

2 - DNS-запись для «mx.intranet» неправильно настроена на внутреннем DNS-сервере. Он указывает на 192.168.7.1, который не является SMTP-сервером.

3 - Дескрипторы развертывания сервера приложений настроены таким образом, что он перенаправляет SMTP-соединения на неправильный сервер (192.168.7.1 не является рабочим почтовым сервером).

Кажется ли это разумным причинам?

Спасибо, если кто-нибудь может прокомментировать ... :)