Health actuator mail details shows the port as -1 when using the default port

[OrangeDog]

When mail is autoconfigured and spring.mail.port is not defined, the health contributor shows the port as -1 instead of what is actually used.

"mail": {
  "status": "UP",
  "details": {
    "location": "smtp.example.com:-1"
  }
}

[OrangeDog]

This doesn't seem to have worked. Now it shows smtp.example.com, while the changelog implies it should be e.g. smtp.example.com:25 depending on the protocol settings.

[wilkinsona]

Now it shows smtp.example.com

That's intentional. The port isn't shown when using the default, just as it typically isn't shown on web addresses that are using port 80.

the changelog implies it should be e.g. smtp.example.com:25

I've retitled the issue and updated the changelog to match. Hopefully that removes the confusion.

[OrangeDog]

Ah ok. I was hoping it would confirm which port it's ended up using. We can tell for a web address because it says http: or https:, but SMTP it depends on the other settings (which can also be defaults).

[wilkinsona]

Unfortunately, that information isn't readily available. We'd need to be able to call org.springframework.mail.javamail.JavaMailSenderImpl.getTransport(Session) and then getURLName().getPort() but getTransport is protected so we cannot do so. The best we can do is get the port with which the mail sender has been configured. That's either a positive value or -1 to indicate that the default port for the protocol should be used.

[OrangeDog]

A ticket with spring-core to make it public then perhaps? Or a cheeky subclass.

[wilkinsona]

A sub-class won't be reliable as someone may define their own bean. If this is something that'd like to see, I think a Framework issue is the next step you should take.

[sbrannen]

We'd need to be able to call org.springframework.mail.javamail.JavaMailSenderImpl.getTransport(Session) and then getURLName().getPort()

Based on preliminary inspection, it appears that transport.getURLName().getPort() might always return -1 for the default port scenario.

At least, based on a quick glance at the code (com.sun.mail.smtp.SMTPTransport.protocolConnect(String, int, String, String) and com.sun.mail.smtp.SMTPTransport.openServer(String, int)) it doesn't appear that the "actual port used" is available after the connection has been opened.

@wilkinsona, were you able to verify that getURLName().getPort() returns the actual port with a running mail service?

[sbrannen]

As a side note, what happens with regard to what MailHealthIndicator reports as the port if the user has configured JavaMailSenderImpl with a Java Mail Properties file containing an entry for mail.smtp.port/mail.smtps.port which differs from the default?

[wilkinsona]

I thought I had, but it looks like I was mistaken. Looking at the code again now and stepping through things in the debugger, I agree with your assessment, Sam. As far as I can tell, the port is updated locally for logging purposes but isn't updated in any state that can be subsequently accessed. This leaves the URLName with a port of -1. Sorry for the wild goose chase here.

[sbrannen]

As far as I can tell, the port is updated locally for logging purposes but isn't updated in any state that can be subsequently accessed.

That was the same conclusion I came to.

Sorry for the wild goose chase here.

No worries. Thanks for confirming there's nothing we can do here. I'll close spring-projects/spring-framework#30507 accordingly.

Though I'm still curious about #35247 (comment).

[wilkinsona]

what happens with regard to what MailHealthIndicator reports as the port if the user has configured JavaMailSenderImpl with a Java Mail Properties file containing an entry for mail.smtp.port/mail.smtps.port which differs from the default?

The health indicator uses the values returned from getHost() and getPort() on JavaMailSenderImpl. As those accessors don't take into account property-based configured, the health indicator will show the wrong values. Thankfully, that's unlikely to occur in a Boot app where, from what I've seen, Properties are rarely used to configure the sender.

[sbrannen]

Thankfully, that's unlikely to occur in a Boot app where, from what I've seen, Properties are rarely used to configure the sender.

Fair enough. 👍

Thanks for elaborating.