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.
http://www.santronics.com