1. Home
  2. Network Vulnerabilities
  3. How to remediate – NTMail3 Arbitrary Mail Relay

How to remediate – NTMail3 Arbitrary Mail Relay

1. Introduction

NTMail3 Arbitrary Mail Relay is a vulnerability where an SMTP server allows unrestricted mail relaying, specifically when the source address is set to ‘<>‘. This means anyone can send emails through your server, potentially flooding your network and causing blacklisting of your email infrastructure. Affected systems are typically those running older versions of NTMail3 email software. Impact on confidentiality is low, integrity is medium due to potential message alteration, and availability is high as bandwidth is consumed.

2. Technical Explanation

The root cause is a lack of proper access controls on the SMTP server, allowing any host to relay emails without authentication if they spoof the source address to ‘<>‘. An attacker can exploit this by sending emails through your server to any recipient, making it appear as though the email originated from your domain. This relies on an open port 25 (SMTP) and no restrictions on relaying.

  • Root cause: Missing or insufficient access controls for SMTP relaying.
  • Exploit mechanism: An attacker connects to the SMTP server, provides a source address of ‘<>‘, and sends an email to any target recipient. The server relays the message without verification. For example, using telnet 192.168.1.100 25, then sending commands like ‘MAIL FROM:‘ followed by ‘RCPT TO:‘.
  • Scope: NTMail3 email server versions prior to a specific patch (version details not provided in context).

3. Detection and Assessment

You can confirm vulnerability by testing if your SMTP server accepts relay requests with a spoofed source address. A quick check is to examine the SMTP server configuration for open relay settings.

  • Quick checks: Check the NTMail3 configuration file (location not provided) for any lines allowing unrestricted relaying or accepting connections from all sources.
  • Scanning: Nessus vulnerability ID 10874 is known to detect this issue. Other scanners may have similar signatures.
  • Logs and evidence: Examine SMTP server logs (location not provided) for successful relay transactions originating from unexpected source IP addresses. Look for entries where the ‘MAIL FROM’ address is ‘<>‘.
telnet <your_smtp_server> 25
Trying <your_smtp_server>...
Connected to <your_smtp_server>.
EHLO example.com
250 OK
MAIL FROM:<>
250 OK
RCPT TO:[email protected]
250 OK
DATA
.
250 OK: queued as 123456789
QUIT
221 Bye.

4. Solution / Remediation Steps

To fix this issue, reconfigure your SMTP server to prevent indiscriminate relaying and enforce appropriate access controls.

4.1 Preparation

  • Ensure you have administrator credentials for the SMTP server. A roll back plan is to restore the original configuration file and restart the service.
  • A change window may be needed, depending on your environment. Approval from a senior IT admin might be required.

4.2 Implementation

  1. Step 1: Open the NTMail3 configuration file in a text editor.
  2. Step 2: Locate any settings related to SMTP relaying.
  3. Step 3: Modify these settings to only allow relaying from trusted hosts or authenticated users.
  4. Step 4: Save the changes to the configuration file.
  5. Step 5: Restart the NTMail3 service.

4.3 Config or Code Example

Before

relay_open = yes

After

relay_open = no
allowed_relayers = 192.168.1.0/24, localhost

4.4 Security Practices Relevant to This Vulnerability

  • Practice 1: Least privilege – limit the number of users and systems that can access the SMTP server.

4.5 Automation (Optional)

No suitable automation script is provided in context.

5. Verification / Validation

  • Post-fix check: Run the same telnet command as in detection (see section 3) and confirm it now returns an error message indicating relay access is denied.
  • Re-test: Re-run the Nessus scan to verify that the vulnerability is no longer detected.
  • Smoke test: Ensure legitimate users can still send and receive emails through the server.
  • Monitoring: Monitor SMTP server logs for failed relay attempts from unauthorized sources.
telnet <your_smtp_server> 25
Trying <your_smtp_server>...
Connected to <your_smtp_server>.
EHLO example.com
250 OK
MAIL FROM:<>
550 Relay access denied

6. Preventive Measures and Monitoring

  • Baselines: Update your security baseline to include a requirement for secure SMTP configuration, such as CIS control 13.
  • Pipelines: Implement automated checks in your CI/CD pipeline to validate the SMTP server configuration during deployment.
  • Asset and patch process: Establish a regular patch review cycle for all email servers.

7. Risks, Side Effects, and Roll Back

  • Roll back: Restore the original NTMail3 configuration file and restart the service.

8. References and Resources

Updated on December 27, 2025

Was this article helpful?

Related Articles