ietf-smtp
[Top] [All Lists]

Hector's BCP summary outline for SMTP

2005-06-16 00:39:09

For what its worth, here is my idea of a good secured SMTP system with major
consideration for backward 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 considerations other than to
possible addressed compromised authorized senders using pattern recognition
methods.  So the following is purely based that the sender is not known to
the SMTP using any current BCP  authentication/authorization method
currently in place:

1) SMTP Servers SHOULD perform SMTP compliancy checking to the maximum
possible extent. These Include:

1.1) CONNECTION

SMTP servers SHOULD publish an extended line 220 greeting response
indicating the system server basic mail policy.

1.2)  HELO/EHLO checking

SMTP Servers SHOULD perform client machine domain syntax checking
(HELO/EHLO).  Syntax checking MAY include a Domain Literal Validation check.

Any advanced HELO/EHLO domain validation concept SHOULD be delayed until
Remote or Final Destination is determined in the RCPT state.

1.3)  MAIL FROM

SMTP Servers MUST perform MAIL FROM syntax validation.

Any advanced MAIL FROM validation concept MUST be delayed until Remote or
Final Destination is determined  in the RCPT state.

1.4)  RCPT TO

SMTP Servers MUST perform RCPT TO syntax validation.

SMTP Servers MUST perform LOCAL RCPT VALIDATION to determine FINAL vs. ROUTE
destination.

If ROUTE,  a 451 response should be issued for non-authorized transactions.

IF LOCAL, a HELO/EHLO and MAIL FROM validation SHOULD be performed.

Due to the nature of SMTP,  HELO/EHLO validation is relaxed.  Its
verification is weak.   However, by
SMTP 2821 requirements.  the MAIL FROM return path MUST be valid for
potential system notification.  A valid return path is a fundamental
requirement for proper mail flow.

Therefore, an SMTP server SHOULD highly consider to perform some form of
RETURN PATH validation.  How this is done is a "BLACK BOX" concept and is
subject to on going R&D.

If the RETURN PATH fails,  the response should be 451 or 551 depending the
type or rejection 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
that addresses SPAM or 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.

A 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



<Prev in Thread] Current Thread [Next in Thread>
  • Hector's BCP summary outline for SMTP, Hector Santos <=