[This is a followup and cleaned up version of my original post.]
SMTP Mail Hosting and Transaction Management
and Security Recommendations
version 1.1 - June 16, 2005
Hector Santos, Santronics Software, Inc.
For what its worth, here is my idea of a good secured SMTP system to
help address the "email problem" with major considerations for backward
compliancy considerations:
This will be presented in sequence as a SMTP STATE flow process. The
basic assumption is ANONYMOUS sender which means:
- No ESMTP AUTH is taken place by the client.
- The IP is not within Local IP relay tables.
- The client is not white listed.
In other words, the sender is unknown to the SMTP server. In my view,
an authorized sender does not need any extended TMS consideration other
than to possibly address compromised authorized senders using pattern
recognition methods.
So the following outline is purely based that the sender is not known to
the SMTP using any current BCP authentication/authorization method
currently in place:
1) SMTP Client/Server Compliance.
SMTP Servers SHOULD perform SMTP client compliancy checking to the
maximum possible extent. These include:
1.1) CONNECTION
The SMTP Server MAY perform peer IP address analysis at the
connection level.
Aggressive clients with mass connections SHOULD be analyzed for CLASS
C patterns.
DNS based lookup methods such as DNSRBL methods SHOULD be delayed
until the RCPT state is reached.
SMTP servers SHOULD publish an extended line 220 greeting response
indicating the system server basic mail policy.
1.2) HELO/EHLO
The SMTP server SHOULD perform client machine domain syntax checking
(HELO/EHLO).
Syntax checking MAY include a Domain Literal Validation (IP vs
domain IP literal comparison).
The SMTP server SHOULD perform SHOULD a Local Domain Network IP
validation check (The IP address does not accurately reflect the
client domain presented). Since a local domain is under control
of the SMTP server, the spoofing of the domain is 100% detectable.
This is a lightweight SPF-like check with no DNS process involved.
Any advanced HELO/EHLO domain validation concept with considerable
overhead potential SHOULD be delayed until Remote or Final
Destination is determined in the RCPT state.
1.3) MAIL FROM
The SMTP server MUST perform MAIL FROM syntax validation.
Any advanced MAIL FROM validation concept with considerable overhead
potential MUST be delayed until Remote or Final Destination is
determined in the RCPT state.
1.4) RCPT TO
The SMTP server MUST perform RCPT TO syntax validation.
The SMTP server MUST perform LOCAL RCPT VALIDATION to determine
FINAL/LOCAL vs. ROUTE destination.
If ROUTE, a 55x response SHOULD be issued for non-authorized
transactions.
IF LOCAL and the session is not authorized, a HELO/EHLO and/or MAIL
FROM validation SHOULD be performed.
Due to the nature of SMTP, HELO/EHLO validation is relaxed and its
verification is weak. There are legitimate reasons as to why a
client machine domain does not match the IP address.
However, by SMTP 2821 requirements, the return path (MAIL FROM) MUST
be valid for potential system notification mail flows. A valid return
path is a fundamental and essential technical requirement for proper
mail flow,
Therefore, the SMTP server SHOULD highly consider to perform some
form of return path validation. How this is done is a SMTP system
implementation dependent and considered as a "BLACK BOX"
concept and is subject to on going R&D.
If the return path validation fails, the response SHOULD be 451 or
551 depending the type, reason or nature for rejection.
1.5) DATA
If the SMTP server implementation incorporates a Mail Filter Agent
(mail content analyzers) concept using 3rd party rule based messaging
technology addressing SPAM or malicious VIRUS mail content, the SMTP
server SHOULD perform the dynamic analysis of the mail content during
the DATA state, after it is received and before the DATA response
code is issued.
Any rejection should use a 45x or 55x depending on the 3rd party Mail
Filter Agent response.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com