How to remediate – MTA Open Mail Relaying Allowed

1. Introduction

An open SMTP relay is a configuration error on an email server that allows anyone to send emails through it, regardless of whether they are authorised users. This lets spammers abuse your system for mass mailings, damaging your network’s bandwidth and potentially getting its IP addresses blacklisted. Mail servers are commonly affected, especially those with older configurations or default settings. This issue can impact confidentiality by allowing unintended message transmission, integrity through spoofed emails, and availability due to resource exhaustion from spam traffic.

2. Technical Explanation

The root cause is typically a lack of access controls on the SMTP server, permitting relaying without authentication or proper authorisation checks. An attacker can exploit this by connecting to your mail server and sending emails with forged sender addresses. The preconditions are an accessible SMTP port (usually 25) and no restrictions on relaying. CVE-1999-0512, CVE-2002-1278, and CVE-2003-0285 describe related vulnerabilities.

• Root cause: Missing or inadequate access controls allowing unauthenticated mail relaying.
• Exploit mechanism: An attacker connects to the SMTP server (port 25) and uses commands like HELO, MAIL FROM, RCPT TO, and DATA to send emails through it. For example, an attacker could use telnet to connect and craft a simple email message.
• Scope: All mail servers running vulnerable versions of software or with misconfigured relay settings are affected.

3. Detection and Assessment

Confirming vulnerability involves checking if your server accepts relay requests from untrusted sources. A quick check is to see if the server allows connections without authentication. Thorough assessment requires a port scan and attempting to send test emails through the server.

• Quick checks: Use telnet to connect to port 25 of your mail server and attempt to send an email without authentication.
• Scanning: Nessus vulnerability ID 10873 can detect open SMTP relays. Other scanners may have similar signatures.
• Logs and evidence: Check mail server logs for relay connections from unknown IP addresses or failed authentication attempts. Log file locations vary depending on the mail server software (e.g., /var/log/mail.log for Postfix).

telnet your_mail_server 25
Trying [your_mail_server]...
Connected to your_mail_server.
HELO example.com
250 your_mail_server Hello example.com [your_ip_address], pleased to meet you
MAIL FROM: [email protected]
250 2.1.0 Ok
RCPT TO: [email protected]
250 2.1.5 Recipient OK
DATA
354 End data with .
Subject: Test email
This is a test email sent through your server.
.
250 Ok: queued as [message_id]
QUIT
221 Bye.

4. Solution / Remediation Steps

Fixing this issue requires reconfiguring the SMTP server to restrict relay access and enforce authentication. Follow these steps carefully.

4.1 Preparation

• Ensure you have a valid method for restoring the original configuration in case of issues. A roll back plan is to restore from backup.
• Changes may require a maintenance window and approval from IT management.

4.2 Implementation

1. Step 1: Configure your SMTP server to only accept relay requests from trusted networks or authenticated users.
2. Step 2: If using Postfix, edit the main.cf file and add or modify the following lines:
3. Step 3: Restart the mail service to apply the changes.

4.3 Config or Code Example

Before

# main.cf (example - insecure)
relayhost = 
mynetworks = 0.0.0.0/0

After

# main.cf (example - secure)
relayhost = 
mynetworks = 127.0.0.0/8 [your_trusted_network]/24
smtpd_reject_unauth_destination = yes

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Least privilege limits the impact of exploitation, while input validation blocks unsafe data. Safe defaults ensure a secure configuration out-of-the-box.

• Practice 1: Implement least privilege by restricting access to mail server configurations and logs.
• Practice 2: Use input validation on all email inputs to prevent injection attacks.

4.5 Automation (Optional)

If using configuration management tools like Ansible, you can automate the changes.

# Ansible playbook example - use with caution
- name: Configure Postfix relay access
  lineinfile:
    path: /etc/postfix/main.cf
    regexp: '^mynetworks = '
    line: 'mynetworks = 127.0.0.0/8 {{ trusted_network }}/24'
  notify: Restart Postfix
- name: Ensure smtpd_reject_unauth_destination is set
  lineinfile:
    path: /etc/postfix/main.cf
    regexp: '^smtpd_reject_unauth_destination = '
    line: 'smtpd_reject_unauth_destination = yes'
  notify: Restart Postfix
handlers:
  - name: Restart Postfix
    service:
      name: postfix
      state: restarted

5. Verification / Validation

Confirm the fix by checking if relay access is now restricted and authentication is required. Re-run the earlier detection method to verify the issue is resolved.

• Post-fix check: Use telnet again to connect to port 25 and attempt to send an email without authentication. You should receive a rejection message (e.g., “503 Authentication required”).
• Re-test: Repeat the test from Section 3, attempting to relay emails through your server. It should now fail.
• Smoke test: Verify that legitimate users can still send and receive emails without interruption.
• Monitoring: Monitor mail server logs for rejected relay attempts or authentication failures. Look for error messages related to access restrictions.

telnet your_mail_server 25
Trying [your_mail_server]...
Connected to your_mail_server.
HELO example.com
250 your_mail_server Hello example.com [your_ip_address], pleased to meet you
MAIL FROM: [email protected]
503 Authentication required
QUIT
221 Bye.

6. Preventive Measures and Monitoring

Update security baselines and implement checks in CI/CD pipelines to prevent recurrence. A regular patch or configuration review cycle is also sensible.

• Baselines: Update your mail server security baseline to include restrictions on open relaying, following CIS benchmarks or similar standards.
• Pipelines: Add static analysis tools (SAST) and infrastructure-as-code checks to identify misconfigured relay settings during deployment.
• Asset and patch process: Implement a quarterly review of mail server configurations to ensure compliance with security policies.

7. Risks, Side Effects, and Roll Back

• Risk or side effect