0

This is actually a question from an exam, but I believe it could help others troubleshooting a similar situation.

In a system, an e-mail needs to be sent to a certain mailbox. The following Java code, which is part of a larger system, was developed for that. Assume that "example.com" corresponds to a valid registered internet domain.

 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);
  }
}

The execution of this code, within the testing environment of an application server, does NOT work as expected. The mailbox of the "example.com" server never receives the email, even tough all string values in the code are correctly attributed.

The output for the command "netstat -np TCP" in the application server during execution is shown bellow:

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

With the exception of the lines that were NAT'd, all others are associated with the Java application server, which created them after the execution of the code above.

The e-mail server used in this environment is the production server, which is online and does not require any authentication for internal connections.

Based on this situation, point out three possible causes for the problem.

1 Answers1

1

I gave my shot as follows:

1 - There's a firewall between the application server (192.168.5.5) subnet and the internal mail server (192.168.7.1) blocking port 25.

2 - The DNS entry for "mx.intranet" is incorrectly configured in the internal DNS server. It is pointing to 192.168.7.1, which is not the SMTP server.

3 - The application server's deployment descriptors are configured in such a way that it redirects SMTP connections to the wrong server (192.168.7.1 is not the production email server).

Do these seem reasonable causes?

Thanks if anyone could comment... :)