Hector Santos <hsantos(_at_)santronics(_dot_)com> wrote:
I assert the lookup method needs to be refined.
Hector seems to be reacting to the "Overview" section in
http://www.jlc.net/MARID/CSV/draft-ietf-marid-csv-intro-01.html
This overview is there because people complained they didn't understand
how to use CSV. It is _an_ example. Please note there isn't a single
"MUST" in the entire Overview.
In fact, there are rather few "MUST"s in the entire CSV series:
In csv-intro:
- A sending SMTP client MUST supply a published domain name as the
parameter to an SMTP HELO or EHLO.
- If an EHLO is issued, the entire CSV process MUST be restarted without
needing to make a new connection.
- CSV participants MUST use the method defined in Client SMTP Authorization
(CSA) [ID-CSVCSA].
- Accreditation services MUST publish DNA-conformant records.
In csv-csa:
- DNS administration, servers and clients MUST support SRV queries.
- Client MTA's MUST put their registered domain name in EHLO announcements.
- Server MTA's MUST implement the validation procedure described in this
specification.
In csv-dna:
- A direct accreditation service MUST publish its listings using the
following record and format...
- The Accreditation Report string MUST contain a report for a particular
service, encoded as...
- Strings which do not match this format MAY have meaning outside the
scope of this specification and MUST be ignored by DNA parsers unaware
of such meaning.
- For MARID-CSV, the "service accredited" MUST be "MARID" and the "level
accredited" currently MUST be "1".
- Any CSV queries MUST discard any PTR records returned which do not
contain that prefix ["_VOUCH._SMTP."].
That's it, folks...
In fact, there's no requirement that the receiving MTA do any DNA
test whatsoever: merely, that if they do, they must ignore PTR replies
which don't start with the magic string, and must ignore TXT records
which don't match the DNA report format.
(Doug has already explained why we thought the example given in the
Overview was _a_ good way to do things.)
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.
Hint on reading Standards: if it's not a MUST, it's not "required".
(I really don't want to belittle Hector, but Standards _must_ be
written as standards, and must be read as standards.)
In fact, Hector's preferred way of implementing CSV is 100% permitted.
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
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.
We are not trying to "implement a total product": we're trying to
write a standard.
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.
"Wasted" is in the eye of the beholder. We need to write a standard
which is workable in today's environment and also workable in a future
world where spammers don't bother to send as much junk as they do today.
And, though I hate repeating myself, the CSV proposal doesn't "impose"
any DNA overhead whatsoever.
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.
This is simply not true. SMTP was designed with the assumption that
RCPT-TO would "usually" be useful. We have done nothing to strengthen
_or_ weaken that assumption.
The presumption is weak in the today's real world of anti-spam
operational requirements.
"Today's" world -- yes. Tomorrow's world -- who knows?
The standard _cannot_ only be for today's world.
--
John Leslie <john(_at_)jlc(_dot_)net>