SMTP connection check rejects hosts resolving to RFC 1918 addresses with no apparent way to allow them

### Current Behavior

### Current Behavior

Testing the Email notification publisher fails when the configured SMTP host
resolves to a private (RFC 1918) address:

```
Check "connection" failed: The configured host resolves to a local address,
but local connections are not allowed
```

The check appears to run before any connection attempt is made. The SMTP server
is reachable from inside the API server container:

```
$ docker exec dt_apiserver sh -c 'nc -zv 172.16.x.x 25'
172.16.x.x (172.16.x.x:25) open

$ docker exec dt_apiserver getent hosts smtp.internal.example.com
172.16.x.x

smtp.internal.example.com
```

Entering the IP address directly instead of the hostname produces the same
error, so this is not a DNS resolution problem.

I could not find a configuration property to allow this. I searched the
Configuration Properties reference for `local`, `ssrf`, `private` and
`loopback`, and checked the v5.0.5 and v5.1.0 upgrade guides and the
notification guides, without finding anything relevant.

An internal SMTP relay on a private address seems like a common enough
deployment that I would expect an opt-in escape hatch to exist. If one does,
it would help to reference it from the error message itself.

### Steps to Reproduce

1. Deploy the API server with an SMTP relay reachable at an RFC 1918 address.
2. Go to Administration → Notifications → Publishers → Email.
3. Set SMTP Host to a hostname resolving to that address (or the IP directly),
port 25, no credentials, SSL/TLS and STARTTLS disabled, and a sender address.
4. Click Test.

### Expected Behavior

Either the check succeeds, or the error names the configuration property that
permits connections to private address ranges.

### Dependency-Track Version

5.1.0

### Distribution

Container

### BOM Format & Version

N/A

### Database Server

PostgreSQL

### Database Server Version

16.10

### Browser

Google Chrome

### Additional Details

Migrated from 4.14.3 via v4-migrator, then upgraded 5.0.5 → 5.1.0. Email
notifications worked against the same relay on 4.14.3.

### Steps to Reproduce

1.

### Expected Behavior

Either the check succeeds, or the error names the configuration property that
permits connections to private address ranges.

### Dependency-Track Version

5.x

### Browser

Google Chrome

### Checklist

- [x] I have read and understand the [contributing guidelines](https://github.com/DependencyTrack/dependency-track/blob/main/CONTRIBUTING.md#filing-issues)
- [x] I have checked the [existing issues](https://github.com/DependencyTrack/dependency-track/issues) for whether this defect was already reported

Start at the Email notification publisher's connection test and trace the check that rejects SMTP hosts resolving to RFC 1918 addresses. Compare hostname and direct-IP behavior, then inspect how configuration properties are surfaced. Done means an internal relay can be tested with an explicit opt-in, or the error identifies the property that permits private address ranges.

Written by the indexing model from the issue text.