On Thu, 2004-09-23 at 14:53, Hector Santos wrote:
On Thu, 2004-09-23 at 10:50, "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
wrote:
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.
To reduce time expended validating a session, simultaneous queries could
be made for the CSV-CSA record and likely, (at least in the early stages
of deployment) an rhsbl and rbl list server. With the exception of the
CSV-CSA record, these queries would be to known servers. For large
ISPs, a majority of these names will be already known and placed within
a protected category as part of a business model. The remainder will
not have established a local reputation and will require a check against
the name or address for ongoing abuse.
The use of a name helps track histories of the entity better than just
an address and allows them a freedom to change addresses with less
concern about having the IP address previously blacklisted, as the rhsbl
should supersede the rbl.
Use of DNA will likely come somewhat later as the adoption rate
increases. The use of a reputation service is not needed for there to
be a value in validating the EHLO domain. If this validated name is
made visible to the user, then just this alone helps thwart spoofing and
phishing. So without any reputation service, there remains features
that you should find useful.
1) The ability to safely relate the mailbox-domain with the
mail-channel. (No reputation service needed.)
2) The ability to discourage spoofing and phishing attacks.
(No reputation service needed.)
Should there be a crime, this identity indicates which logs need to be
discovered. And of course, the use of CSV provides an identity strong
enough to permit a name based reputation service that can both open or
close the door.
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 operations. 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.
I wonder how many things would fall into that category.
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.
I understand what you are saying, but I don't see how this relates to a
comparison of differing techniques.
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.
Most will attempt to compress the time it takes to handle a message to
permit resources to be freed to handle the next message. Comparing CSV
(even together with a name list) against SPF et al lookups offers a
dramatic improvement with respect to overhead. Should the EHLO fail
validation and cause a rejection, then little has been wasted in terms
of either time or bandwidth. That is not true with SPF et al as the
number of record lookups may be very large, whereas the same information
is now available within a single name list.
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.
If this is true, then holding off these checks still costs less than the
alternatives. Wide spread adoption of CSV will not cause additional
lookups over today's efforts to validate EHLO.
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 reduction. We are probably among the
first, if 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 operation.
Learn from REAL Deployments in the market place.
How these checks are staged seem immaterial to the value of these
checks. If various extended services depend upon name validation prior
to running other processes, then publishing these records becomes just
an extremely minor cost of doing business. The cost of these records
also requires far less maintenance as well, as they are name based and
not address based. (The address generation is automated.) : )
-Doug