----- Original Message -----
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
To: "MXCOMP" <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Thursday, September 23, 2004 10:50 AM
Subject: Re: WG to close ; Re: Make CSV backwards compatible with SPF? (new
revisions)
CSV is a solution based on two methods: CSA vs. DNA.
CSV is a suite of specifications that also includes DNA.
The assertion that there is a "versus" between CSA and DNA is quite
simply wrong.
I assert the lookup method needs to be refined.
Let me clarify.
As it relates to CSV, there are two distinctly different concepts in the
total paradigm of trust. Overhead, wasted DNAs for example when in fact the
exposed client domain name was illegal. You only need to do a accreditation
lookup if CSA result is positive (passes). However, your lookup method
requires a DNA lookup first.
Anyone not clear about the roles and functions of components in the the
CSA specification is strongly encouraged to asked detailed questions
about them. That way, we will know what needs to be changed in the
specifications, to improve their clarity.
The point is that the specification is well understood. You are trying to
implement a total product, but the product parts doesn't fit well in
practical opertions. The "parts" of the product have conflicts as it fits
into the total model. If it did not, it would of been adopted long ago.
The EHLO/MAIL FROM validation is
useless if RCPT TO is invalid.
CSV allows the construction of name based relationships to relate
mailbox domains with the mail channel, as example, without requiring
subsequent lookups.
Invalid Rcpt-to? I suspect that was meant to refer to RFC2821.mailfrom.
No Dave, I 100% meant the forwarding address RCPT-TO. If it is invalid,
everything else doesn't matter. It is wasted overhead to perform expensive
DNS based validation. This is 100% proven to the the case in the spam world
with an average of 35% reduction in EHLO/MAILFROM validation requirements.
In any event, the RFC2821.helo/ehlo parameter is is per-session and is
used to validate the OPERATOR OF THE MTA. The other SMTP parameters are
per-message. MailFrom validation mechanisms pertain to the SENDER OF
THE MESSAGE.
These are entirely different entities, and validating each of them has
entirely different benefits.
The entities 2821.EHLO/HELO, 2821.MAILFROM, including 2821.RCPTTO are SMTP
transport parameters and are all involved in the total equation
validation/trust paradigm at the transport level. Until you recognize this,
your proposals impose wasted overhead in systems.
Your proposal (as well as others) all are designed on the presumption that
the 2821.RCPTO forwarding address is valid and that the payload will be
acceptable. The presumption is weak in the today's real world of anti-spam
operational requirements.
See RFC 2821 Section 3.3:
| 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 is probably the most powerful concepts in RFC 2821 for anti-spam
operations. It opens the door for Mail From Validation and it offers
performance enhancement and overhead reductionn. We are probably among the
first, if the the only product in the market to have implemented this
recommendation.
There is no way on earth we will add anything else to break this excellent
mode of anti-spam oepration.
Learn from REAL Deployments in the market place.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office