Skip to main content

7. Security Considerations

7.1. Mail Security and Spoofing​

SMTP mail is inherently insecure due to:

  • Lack of built-in authentication
  • Trivial forgery of sender addresses
  • No encryption in basic protocol

The MAIL FROM and RCPT TO addresses can be easily forged. Additional protocols like SPF, DKIM, and DMARC help mitigate spoofing, but are not part of core SMTP.

7.2. "Blind" Copies​

BCC (Blind Carbon Copy) recipients MUST NOT appear in the message header. This is typically handled by:

  • Creating separate SMTP transactions for BCC recipients
  • Removing BCC header fields before transmission

7.3. VRFY, EXPN, and Security​

The VRFY (verify) and EXPN (expand) commands can be used to harvest valid email addresses. Servers MAY:

  • Disable these commands
  • Require authentication before use
  • Return generic responses that do not confirm address validity

7.4. Mail Rerouting Based on the 251 and 551 Response Codes​

Response codes 251 (user not local, will forward) and 551 (user not local) can be exploited:

  • To discover forwarding addresses
  • For address harvesting
  • For traffic analysis

Servers SHOULD be cautious about automatic forwarding and the information disclosed in these responses.

7.5. Information Disclosure in Announcements​

The server greeting (220 response) and EHLO response SHOULD NOT disclose:

  • Detailed software version information
  • Internal system architecture
  • Security configuration details

Attackers can use this information to target known vulnerabilities.

7.6. Information Disclosure in Trace Fields​

Received header fields contain:

  • IP addresses
  • Hostnames
  • Timing information
  • Internal network topology

While necessary for debugging, this information can be used for:

  • Network mapping
  • Traffic analysis
  • Identifying security infrastructure

7.7. Information Disclosure in Message Forwarding​

When forwarding messages, servers SHOULD:

  • Avoid disclosing internal addresses
  • Sanitize trace information when crossing trust boundaries
  • Consider privacy implications of automatic forwarding

7.8. Resistance to Attacks​

SMTP servers SHOULD implement protections against:

Denial of Service (DoS)​

  • Connection limits per source
  • Rate limiting
  • Resource consumption limits
  • Timeout enforcement

Buffer Overflows​

  • Strict input validation
  • Length limit enforcement
  • Safe string handling

Command Injection​

  • Proper parsing of commands
  • Validation of arguments
  • Rejection of malformed input

Directory Harvest Attacks​

  • Rate limiting RCPT TO commands
  • Delayed or generic responses
  • Logging and blocking of scanning behavior

7.9. Scope of Operation of SMTP Servers​

SMTP servers SHOULD:

  • Clearly define their operational scope
  • Implement appropriate access controls
  • Distinguish between:
    • Internal message submission
    • External message relay
    • Final message delivery

Open relays (servers that accept and forward mail from anyone to anywhere) MUST NOT be deployed, as they:

  • Enable spam distribution
  • Facilitate abuse
  • Harm Internet mail infrastructure
  1. Use TLS/STARTTLS: Encrypt connections when possible
  2. Implement Authentication: Require SMTP AUTH for message submission
  3. Deploy SPF/DKIM/DMARC: Add sender authentication
  4. Rate Limiting: Prevent abuse and DoS attacks
  5. Access Controls: Restrict relay access appropriately
  6. Logging: Maintain detailed logs for security analysis
  7. Regular Updates: Apply security patches promptly
  8. Monitoring: Detect and respond to suspicious activity
Last updated on