"Wasted" CSV-DNA lookups

Hector Santos <[email protected]> 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" <[email protected]>
> 
>> 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 <[email protected]>