Subject: Re: Comparing apples to multiple, hypothetical oranges

From: Greg Connor <[email-masked]>
Date: Wed, 30 Jun 2004 23:19:28 -0700 (PDT)

On Thu, 1 Jul 2004, Dave Crocker wrote:
> 
> By contrast, discussions about "SPF" frequently treat hypothetical
> capabilities, deployed capabilities, and multiple specifications of
> capabilities as if they were all the same, single, concrete
> technology. Perhaps other folks can keep clear what is concrete and
> what is vague, but I can't.

I heartily agree with Dave, that it's easier to collaborate on documents than 
ideas.  It's great to talk about ideas, but they must become documents at some 
point before meaningful consensus can be reached.

Thus, the idea of "Unified SPF" needs a draft behind it.

> It is always easy to appear to win an argument if one is not burdened
> with the requirement to be concrete and stable, and abstract
> hypotheticals are treated the same as reality. Easy, but not
> technically productive.

There is a healthy amount of disagreement and argument in our working group. I 
think this is overall a good thing.  But, I'm certainly not out to "win" and I 
don't think you are either.  We all "win" if we can all agree, or at least 
agree to support the group's output at the end.

If SPF is being molded and morphed to take on CSV-like qualities here and 
there, CSV authors and supporters should consider this a form of flattery. :)

> Specifications and undocumented concepts that are outside the working
> group ought to remain outside.
> 
> Undocumented concepts are, of course, fine to consider for inclusion
> in the working group, but a concept is always vague and its utility is
> typically not very high until it achieves relatively stable
> documentation. The draft-ietf-marid-submitter specification is a
> particularly good example of this process of incorporation. It went
> quickly from basic idea to clear, concise, concrete specification. Now
> folks can conduct concrete analysis on it.

While I agree that "unified SPF" really needs a draft in order to talk 
details, I don't see anything wrong with talking about it as an "undocumented 
concept" for a while.  Among other things, this is helpful in finding out 
whether there is enough interest in the idea to write the draft.  So I will 
totally agree that a draft needs to be coughed up, but I wouldn't go so far as 
to say "Stop talking about concepts for which there is no draft".  I don't 
think you are saying this either, but "restrict working group discussion to 
working group specifications" comes close.

--
Greg Connor
[email-masked]

Everyone says that having power is a great responsibility.  This is a lot
of bunk.  Responsibility is when someone can blame you if something goes
wrong.  When you have power you are surrounded by people whose job it is
to take the blame for your mistakes.  If they're smart, that is. 
                -- Cerebus, "On Governing"

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 1 Jul 2004 05:27:02 -0400

A few rudimentary questions first:

1) Are there any CVS test sites to test/compare results?

2) Are there any DNA sites to test/compare results?

3) Do you have a list of CVS ready domains I can use for testing logic?

4) Is Acceditation required for CVS to be useful? In other words, is it
useless without it?

Comments on draft-ietf-marid-csv-csa-00

| 4. Mechanism
|
|    The receiving SMTP server's authorization procedure is:
|
|    1.  Obtain a domain name that is associated with the sending SMTP
|        client.

A suggestion: A technical note should be added about possible syntax
checking and domain literals and how this an appropiate place for an optimal
and quick local domain spoof check.

For example,

- if the IP is a remote address and the client doman is santronics.com. I
don't need to bother with any CVS valdation DNS overhead.  Its an obvious
spoof.

- if the client domain is a bracketed IP liternal, it must match the sender
IP.  Its an obvious spoof.

Both represent atleast 10-12% of my rejection rate.

Comments on draft-ietf-marid-csv-intro-00:

| 3.  Design Goals
|
|    o  Identification by persistent domain name rather than transient IP
|       Address

At first glace the term "persistent domain name" when used as analogy to a
transient IP address, seem to imply that the client domain never changes
from hop to hop as oppose to a IP changing from hop to hop.

So if I understand the term "persistent domain name' it implies that a
consistent domain name is used for CVS publishing and for SMTP Sender usage
in its HELO/EHLO command?

I think the term "Consistent" better applies.

| Section 4.2  Authentication
|
|    ....
|    What is missing is a useful means of authenticating MTA-MTA exchanges
|    over the open Internet.  Prior arrangement between such a pair of
|    MTAs is antithetical to the history and operation of Internet mail.

Can you give an example of where this is antithetical provided we are not
talking about an open relay?  An Internal Domain MTA-MTA implies inherent
trust. An External domain MTA-MTA is an open relay.  I can only see to be
valid if the MTA-MTA are part of a "network" or network relationship.

|   Spontaneous communications are at the core of Internet design and
|   operation.  So the challenge is to develop an authentication
|   mechanism that permits the necessary amount of accountability,
|   without imposing undue overhead or restrictions.

Whats the suggestion for improving accountability?

I guess what I ask asking or saying is that CVS breaks down if the MTA-MTA
is not trusted so it might help to define what this means in terms of
"Spontaneous communications."

Is CVS authentication an "alternative" to the existing authentication method
currently used as requirement for routing?

| 9.  Working Group Evaluation
|
|    This section contains responses to the issues put forward by the
|    MARID working group chairs.
|
|    1.  Amount of change in software components
|
|        Client MTA's MUST put their registered domain name in EHLO
|        announcements.

In addition to this,  I see:

1)  How CVS is implemented to work with STARTTLS and/or AUTH.

It may require a delay until AUTH is established or the 2nd EHLO is sent for
STARTTLS situations or CVS may change the SMTP extensions response.   Your
input would be appreciated.

2) SMTP servers need to maintain a list of acceditation services available.
More be more available for my cheap sysop customers. <g>

3) How #2 is considered may change or introduce a "Check and Egg"
consideration. For example Section 1 says:

| 1.  Overview
|
|    3.  Query a chosen Accreditation Service for the EHLO domain name
|        (see Domain Name Accreditation (DNA) [ID-Marid-CSVDNA])
|
|    4.  Query DNS for a SRV record under the EHLO domain name (see Client
|        SMTP Authorization (CSA) [ID-Marid-CSVCSA])
|
|    5.  Check the flags returned and check for a match in the list of
|        returned IP addresses

It might be better to do 4 first before 3 and add SRV information to CSA to
supply the preferred DNA site for the domain.  The site must still be among
the servers list of chosen sites the server will honor.

If you don't to this, then the server will probably need to query server
list of DNA sites looking for CSA authorization.

Thats about it for now!  Hope this helps.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 1 Jul 2004 06:07:37 -0400

Follow up with my review of the DNA specs:

----- Original Message ----- 
From: "Hector Santos" <[email-masked]>
To: "Dave Crocker" <[email-masked]>; <[email-masked]>
Sent: Thursday, July 01, 2004 5:27 AM
Subject: CVS Questions/Comments [was Re: Comparing apples to multiple,
hypothetical oranges]

> Must be more available for my cheap sysop customers. <g>

Is this addressed in draft-ietf-marid-csv-dna-00 section

    "4.  Listing Pointer Service Record Template"

??

Based on what I reading in:

| 5.  Accreditation Procedure
|   A receiving SMTP server validates a sending SMTP client by:
|
|    1.  Obtaining the domain name of the client.
|
|    2.  Determining that the name is being used by an authorized party.
|
|    3.  Creating a list of accreditation services to query, both those
|        the client has registered and those obtained by the server
|        through other means -- such as those that perform block-listing
|        -- to query.
|
|    4.  Querying those services for assessments of the host associated

I would think that the CSA process is the best place for the domain to
define who he is "Paying Big Bucks" to in order to authorized what I
essentially call the domain "permit".   The server is going to have to run a
CSA process anyway so why have it go to DNA first?

I'm thinking on how to "zoom" in as fast as possible with the less number of
lookups.  Mind you, I trying to get this all straight to see how to code it.

Also, to reiterate,  I don't care if the domain says "MAPS" or
"ItsAllGood.Com" is its acceditation/DNA site.  If I don't trust them or
honor them, why should accept what the DNA site reports?  Maybe the DNA site
like MAPS who is profit oriented needs to have a profit-sharing strategy
like maybe 1% to honor its member mail?   I only raise this as one of the
potential "troubling aspect" of the coupling of a acceditation CSA
authorization agent.  I agree something is required, but......

Another point.

RBL works and is well established.  It is going to be very hard to replace
this with CVS.  How can an RBL site work in conjunction with CVS/DNA/CSA?

What if I run both and apply RBL,  CVS/DNA/CSA passes the domain with flying
colors but RBL is rejecting the IP?

Dave et al, these are valid questions for implementators. I don't think it
can ignored.  Your advice is appreciated.

---

From: Tony Finch <[email-masked]>
Date: Thu, 1 Jul 2004 13:43:11 +0100

> 4) Is Acceditation required for CVS to be useful? In other words, is it

No more so than any of the other schemes we are discussing. They all
assume that pervasive domain authentication will lead to accreditation and
reputation services based on domains (RHSBLs), in addition to or as a
replacement for the current IP address DNSBL schemes.

> I think the term "Consistent" better applies.

It's to do with persistence over time. An organization is likely to keep
its domain name longer than its IP addresses, especially if it is small.
This is made clear by the preceding paragraph:

      Increased topological, transfer and access complexities on the
      Internet are making IP Addresses increasingly problematic for use
      as identifiers.  Instead they are viewed as appropriate only for
      the most transient task of delivering individual packets.

> Can you give an example of where this is antithetical

Receiving email from someone who you have never corresponded with before.

> The server is going to have to run a CSA process anyway so why have it
> go to DNA first?

The checks can be done in either order or in parallel. If one of them
fails the other is moot.

> RBL works and is well established.  It is going to be very hard to
> replace this with CVS.  How can an RBL site work in conjunction with
> CVS/DNA/CSA? What if I run both and apply RBL, CVS/DNA/CSA passes the
> domain with flying colors but RBL is rejecting the IP?

I think this depends on the DNSBL in question. For example, if it's the
SBL (list of addresses allocated to known spammers) or the CBL (list of
known compromised machines) then CSV is moot. If it's a dynamic IP list
(dial-ups and DSL lines) then a CSV pass would beat the blacklisting. The
sysadmin will have to apply some intelligence to the configuration.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FORTH TYNE: SOUTHWEST BACKING SOUTH 3 OR 4 OCCASIONALLY 5. SHOWERS. GOOD.

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 01 Jul 2004 09:11:21 -0400

Dave Crocker <[email-masked]> wrote:
> The current effort to compare CSV "versus" SPF, prompts me to notice
> that there is no working group effort on a specification called "SPF",
> nevermind "Unified SPF", Sender ID, or whatever other variant names
> and versions might be used. There are a couple of IETF working group
> documents that derive from those outside efforts, but folks do not
> seem to be referring to working group documents.

  If the SPF + CallerId can't submit a document by the IETF meeting
cutoff (July 19, I think), then the chairs should declare all
SPF-related discussions to be out of scope for MARID.

  Alan DeKok.

---

From: Marshall Rose <[email-masked]>
Date: Thu, 1 Jul 2004 09:24:40 -0700

> SPF-related discussions to be out of scope for MARID.

here's what i think:

1. the working group should try to focus.

2. the working group doesn't need to tell the co-chairs how to do their 
jobs.

/mtr

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 01 Jul 2004 13:46:40 -0400

> 1. the working group should try to focus.

  I'm finding it difficult to follow the WG, because half of the
discussion involves a proposal which isn't well documented.

> 2. the working group doesn't need to tell the co-chairs how to do their 

  The co-chairs need to read my comments as having a less hostile
intent.  My comments weren't orders or demands; they were statements
as to my opinion of how the work should proceed.  Many working groups
have the participants offer suggestions to the chairs as to how the
working group should progress, so comments were *not* innapropriate,
as your response would seem to suggest.

  In this case, I agree with Dave.  I don't know what people mean by
the latest SPF variant, and if there's no documented proposal, I don't
see why we're discussing it here.  It will take time and effort away
from proposals which follow the IETF process.

  Alan DeKok.

---

From: Roy Badami <[email-masked]>
Date: Thu, 1 Jul 2004 20:25:42 +0100

>>>>> "Hector" == Hector Santos <[email-masked]> writes:

    Hector> - if the client domain is a bracketed IP liternal, it must
    Hector> match the sender IP.  Its an obvious spoof.

Stricly, that's not true, because the sender might be multi-homed.

Incidentally, AIUI, multihomed hosts are the main rationale behind the
prohibition in RFC1123 (carried forwards to RFC2821) against rejecting
mail because the source IP address doesn't match the HELO.

     -roy

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 1 Jul 2004 19:44:06 -0400

----- Original Message ----- 
From: "Roy Badami" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: "Dave Crocker" <[email-masked]>; <[email-masked]>
Sent: Thursday, July 01, 2004 3:25 PM
Subject: CVS Questions/Comments [was Re: Comparing apples to multiple,
hypothetical oranges]

> mail because the source IP address doesn't match the HELO.

Good point.  Its an option. Doing a quick grep in the logs, I have not come
across one yet that is a False Positive.  All of them were based on spoofing
our IP literal hence no explaining why spammers are not complaining.

What do you think about the following?

SASL should trump CVS.  For maximum capability without lost of
functionality, CVS should wait until SASL is established or not, thus
implying the CVS logic is initiated before or after the next command.   It
is the only way I can see implemented it.   Users using SMTP AUTH are not
expected to be CVS ready.

Thanks

---

From: Dave Crocker <[email-masked]>
Date: Thu, 1 Jul 2004 22:37:14 +0800

Greg,

GC> While I agree that "unified SPF" really needs a draft in order to talk
GC> details, I don't see anything wrong with talking about it as an "undocumented
GC> concept" for a while.

When the discussion is in the context of whether to "merge CSV into
SPF" then I'm afraid there is quite a lot wrong with comparing a
concrete specification to an abstract idea.

It also does not help when the abstract idea is used in the form of
"Unified SPF can do that", as if everything were entirely settled and
no concerns could possibly exist.

GC> to say "Stop talking about concepts for which there is no draft".

You are right.  So it is a good thing, that's not what has been said.

What has been said is "stop comparing a hypothetical, undocument
concept of an evolved SPF with the concrete, relatively stable
specification of CSV."

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: John Leslie <[email-masked]>
Date: Fri, 2 Jul 2004 10:13:24 -0400

> 1) Are there any CVS test sites to test/compare results?

   I wouldn't quite call it a "test site", but I have placed CSV records
for JLC.net.

   Most of our mail goes out through "mailhost.jlc.net"; thus there are
DNS records (in bind format):
" 
" mailhost        IN      A       199.201.159.9
"                 IN      PTR     _vouch._smtp.csv_vouch
" _client._smtp.mailhost  SRV 1 2 0 mailhost

- saying that mailhost.jlc.net is authorized as an SMTP client, and that
  the list of IP addresses is not empty; and
- saying that the csv_vouch.jlc.net reputation service will vouch for it.

   (Not surprisingly, csv_vouch.jlc.net reports an "excellent" rating.)

> 2) Are there any DNA sites to test/compare results?

   CSV_vouch is a separate zone:
" 
" $TTL    7200
" @               IN      SOA     jlc.net. tech.jlc.net. (
"                                 1
"                                 7200 ;
"                                 900 ;
"                                 86400 ;
"                                 7200 )
"                 IN      NS      ns1.jlc.net.
"                 IN      NS      ns2.jlc.net.
" mailhost.jlc.net        TXT     "MARID,1,A"

> 3) Do you have a list of CVS ready domains I can use for testing logic?

   No. (Perhaps I'll get a round tuit...)

> 4) Is Acceditation required for CVS to be useful? In other words, is it

   "Accreditation is in the eye of the beholder."

   CSV certainly is not "useless" without formal accreditation services.
Without any accreditation service at all, it can report, "This domain
operates no mail-servers" based upon a "SRV 1 1 0" record.

   Without a real-time accreditation check, you're at risk trusting a
CSV report of "authorized"; but until spammers adjust, it would be
relatively safe to let this override an IP-based blacklist.

   And surely the authorization info, recorded in a Received header,
should prove helpful in directing spam reports.

--
John Leslie <[email-masked]>>