1. Introduction
MTA Open Mail Relaying Allowed (thorough test) means an SMTP server is allowing unrestricted email relaying. This lets anyone send emails through your server, potentially for spam. It affects mail servers running common software like Sendmail, Postfix, and Exchange. Impact includes network bandwidth flooding and potential blacklisting of your server, affecting confidentiality, integrity, and availability of email services.
2. Technical Explanation
- Root cause: Insufficient access controls on the SMTP server allow any host to relay email.
- Exploit mechanism: An attacker connects to your SMTP server using a standard SMTP client (telnet or similar) and sends emails through it, spoofing sender addresses. For example, they can send an email with a forged ‘From:’ header.
- Scope: Affected platforms include servers running Sendmail, Postfix, Microsoft Exchange Server, and other SMTP software without proper relay restrictions.
3. Detection and Assessment
Confirming vulnerability involves checking if the server accepts relay requests from untrusted sources. A quick check is to examine the SMTP configuration file for relay access settings. Thorough assessment requires a full test of mail relay functionality.
- Quick checks: Check your SMTP server’s main configuration file (e.g., /etc/mail/sendmail.cf or similar) for lines allowing relay from any host.
- Scanning: Nessus vulnerability ID 10865 can detect open mail relays. Other scanners may have similar tests.
- Logs and evidence: Examine SMTP server logs (e.g., /var/log/mail.log or Windows Event Logs) for connections from unknown IP addresses attempting to relay email. Look for successful relay transactions without authentication.
telnet your.mail.server 25
Trying [your mail server IP]...
Connected to your.mail.server.
EHLO test.example.com
MAIL FROM: [email protected]
RCPT TO: [email protected]
DATA
Subject: Test Email
This is a test email sent through your open relay.
.
QUIT
4. Solution / Remediation Steps
Fixing this issue requires reconfiguring the SMTP server to restrict relay access. This involves limiting which hosts can relay and requiring authentication for all relays.
4.1 Preparation
- Changes require a maintenance window as email flow will be disrupted during reconfiguration. Approval from the IT manager may be needed.
4.2 Implementation
- Step 1: Configure your SMTP server to only allow relaying from trusted networks or hosts. This is usually done in the main configuration file.
- Step 3: Restart the SMTP service to apply the changes.
4.3 Config or Code Example
Before
# /etc/mail/sendmail.cf (example)
relay = * # Allow relay from any host
After
# /etc/mail/sendmail.cf (example)
relay = 127.0.0.1 # Only allow relay from localhost
authinfo_file=/etc/mail/authinfo # Require authentication for all relays
4.4 Security Practices Relevant to This Vulnerability
Practices that directly address this vulnerability include least privilege and secure defaults.
- Practice 1: Least privilege – restrict access to the SMTP server only to authorized users and networks, reducing impact if exploited.
- Practice 2: Secure defaults – configure the SMTP server with strong security settings by default, such as requiring authentication for all relay requests.
4.5 Automation (Optional)
Configuration management tools like Ansible can automate these changes.
---
- hosts: mailservers
tasks:
- lineinfile:
path: /etc/mail/sendmail.cf
regexp: '^relay = *'
line: 'relay = 127.0.0.1'
- service: name=sendmail state=restarted
5. Verification / Validation
Confirm the fix by checking that relaying is no longer allowed from untrusted sources. Re-run the earlier detection method to verify the issue is resolved.
- Post-fix check: Run the telnet test again (see section 3). The connection should be refused or require authentication.
- Re-test: Run Nessus vulnerability ID 10865; it should no longer report an open mail relay.
- Smoke test: Send a test email from an internal user to an external address to confirm normal email flow is still working.
- Monitoring: Monitor SMTP server logs for failed relay attempts from untrusted sources, indicating potential attacks.
telnet your.mail.server 25
Trying [your mail server IP]...
Connected to your.mail.server.
EHLO test.example.com
MAIL FROM: [email protected] # Connection should be refused or require authentication
6. Preventive Measures and Monitoring
Update security baselines and implement regular patch reviews to prevent this issue.
- Baselines: Update your server security baseline to include a requirement for restricted mail relay access, such as CIS control 10.2 (Configure Mail Transfer Agent).
- Asset and patch process: Review SMTP server configuration changes regularly (e.g., monthly) to ensure they comply with security policies.
7. Risks, Side Effects, and Roll Back
Restricting relay access may disrupt legitimate email flow if not configured correctly. A roll back involves restoring the original configuration file.
- Risk or side effect 2: Restarting the SMTP service will briefly interrupt email delivery. Mitigation is to schedule changes during off-peak hours.
- Roll back: 1) Stop the SMTP service. 2) Restore the original configuration file from backup. 3) Restart the SMTP service.
8. References and Resources
Link only to sources that match this exact vulnerability.
- Vendor advisory or bulletin: Check your specific SMTP server vendor’s website for security advisories related to mail relay restrictions.
- NVD or CVE entry: https://nvd.nist.gov/vuln/detail/CVE-1999-0512
- Product or platform documentation relevant to the fix: Refer to your SMTP server’s