[Top] [All Lists]

Re: Advancing RFC2821 to Draft Standard -- outline of work

2007-01-23 07:43:32

Frank Ellermann wrote:
Lisa Dusseault wrote:

Charter-bashing should be done *early* if you disagree

However there's no way that this rest can be a "draft standard"
without fixing another major problem in RFC 2821, the design
flaw to favour "accept and bounce" instead of "reject".

Frank, I agree with you, but IMO, in reality this is an implementation dependent and local policy issue.

This requires SMTP level validation in order to provide instant rejection gratification and we can only justify a SMTP level validation in reference to today's high speed computers and enhanced scaling of SMTP servers.

In other words, we can't mandate "Integration and Performance Requirements" on SMTP developers and their customers installed operations.

There are two part:

1) A host may not be able to validate a RCPT TO. But it SHOULD be
   highly recommended if it can.  For us, we realize at least
   60% rejection rate purely on RCPT TO: rejections.  The
   harvesting red herring does not apply.

2) AVS processing may not scale well.  Note, a few months back
   I spoke with the CTO of an AVS company and we touched base
   on the ideas of dynamic SMTP vs delay post SMTP vs active (background
   process file I/O monitor) mail processing.  He was highly convinced
   that dynamic SMTP processing does not scale well and he indicated the
   abandonment of long time AVS vendors with command line scanners
   as evidence of the preferred direction.  Unfortunately, he also
   seem to be totally oblivious about the non-bouncing of accepted
   post SMTP mail rejections.

At best, we can add hindsight to encourage SMTP level validation and to also make it the recommended default choice for operations to use in their local policies. It can probably be part of the security section.

Other points:

1) On a related note, we should "focus" and "strengthen" the idea that return path MUST be a valid address. The Bounce system can only work if the Return Path is valid. A growing number of systems have implemented MAIL FROM validation concept. In my view, one of strongest points in 2821 that has help tremendously in MAIL FROM validation technology is the following:

| 3.3 Mail Transactions
|    .....
|   .............  Despite the apparent
|   scope of this requirement, there are circumstances in which the
|   acceptability of the reverse-path may not be determined until one or
|   more forward-paths (in RCPT commands) can be examined.  In those
|   cases, the server MAY reasonably accept the reverse-path (with a 250
|   reply) and then report problems after the forward-paths are received
|   and examined.  Normally, failures produce 550 or 553 replies.

This allowed us to justify the delay of MAIL FROM response until the RCPT TO validation was completed. As indicated above, with a 60% RCPT TO rejection rate, this provided us with a matching savings of 60% MAIL FROM validation overhead. The DNS overhead was drastically reduced.

2) We should also remove old school legacy statements like this:

  7.1 Mail Security and Spoofing


   This specification does not further address the authentication issues
   associated with SMTP other than to advocate that useful functionality
   not be disabled in the hope of providing some small margin of
   protection against an ignorant user who is trying to fake mail.

Its no longer a small ignorant user, but a Multi-Billion dollar industry.

3) I also think we should steer away from the term "Authentication" since it is more like "Message Acceptance Technology" since acceptance comes in many forms. Authentication is too heavy handed with politics, conflict of interest and multi-discipline conflictive subjective reasonings. By thinking of terms of Message Acceptance, it allows us to focus on the requirements and BCP we use for accepting and/or rejecting mail. For example, and I am just using this for an example, Message Acceptance in terms of SMTP 3.0, implies:

     Valid HELO/EHLO
     Valid MAIL FROM
     Valid RCPT TO
     Local Policy DATA acceptance

That should be the first level.

Hector Santos, CTO
Santronics Software, Inc.

<Prev in Thread] Current Thread [Next in Thread>