Subject: WG to close ; Re: Make CSV backwards compatible with SPF? (new revisions)

From: Matthew Elvey <[email-masked]>
Date: Wed, 22 Sep 2004 17:16:55 -0700

On 9/22/2004 12:52 PM, The IESG sent forth electrons to convey:

>The MTA Authorization Records in DNS (MARID) working group in the
>Applications Area has concluded. 
>
>  
>
: (     (more fully expressed by Greg Connor, with whom I fully concur, at
       http://article.gmane.org/gmane.ietf.mxcomp/5240 .)

Thanks to all those working to produce a good MARID standard.

>The mailing list will remain active.
>  
>
: )      (Bryce: unsubcrlbe!)  BTW, how many subscribers do we have (peak?)

>The Area Directors intend, therefore, to request that the
>experimental proposals be reviewed by a focused technology
>directorate. This review group has not yet been formed but, as with
>all directorates, its membership will be publicly listed at
>http://www.ietf.org/u/ietfchair/directorates.html once it has been
>constituted.
>
I believe that a directorate being so tasked would be contrary to the 
goals of the IETF. 
It puts undue power in the hands of the directorate and its appointers.  
Spamfighting inherently presents a great challenge to achieving rough 
consensus.  But the IETF consensus-building process is going to do a far 
better job achieving it than a directorate appointed by the area 
directors.  This is evidenced by the ill-advised (and/or poorly made) 
decision push SenderID to last call.  This decision was made by folks 
who were appointed by the the same folks who will appoint the 
directorate, yes?  What a recipe for disaster!  I'm opposed.  Avoidance 
of deleterious effects is not something that creation of such a 
directorate would make any easier. (It also is the case that a good 
MARID will by design, have deleterious effects on certain traffic, e.g. 
email from most members of the DMA.)
It seems to me that CSV and SPF were (are) both more ready for last call 
than SenderID ever was.

=-=-=-=-=-=

On 9/22/2004 1:01 AM, Douglas Otis sent forth electrons to convey:

>On Tue, 2004-09-21 at 19:45, Matthew Elvey wrote:
>  
>
>>Doug, still hoping to hear back from you - on 9/14, I asked:
>>
>>    
>>
>>>Doug, did you get my email - of a possible broad, strong example 
>>>showing [SenderID] falling down. 
>>>      
>>>
>
>In general....
>
I was hoping for validation of the example, not generalities.  But 
thanks for the reply.

>
>  
>
>>and
>>
>>    
>>
>>>If foo.dom's SPF/SenderID record lists just MX, and doesn't send spam, 
>>>how/why would a reputation service blacklist foo.dom?
>>>e.g .
>>>foo.dom.    IN    TXT      "v=spf1 mx -all" 
>>>      
>>>
>
>In a simple environment exchanging messages end-to-end, the risks would
>be low.  There are risks accepting these types of records when a process
>walks through redirects, includes and arbitrary labels for several
>record types.  
>
Huh?  The question is about  the record given, which has none of these 
problems.
I conclude from your statement that given the proposed record, foo.com 
would be pretty safe from being blacklisted by an SPF reputation service.
I don't see a specific example of what would lead a reputation service 
to blacklist foo.dom that could not befall a CSV system.
Do you claim a server running CSV (and not using DNSSEC, of course) is 
not vulnerable to a poisoned cache?
As I said in private email, I'm trying to nail down as mainstream an 
example as possible.  I can't think of one, given this record.

Given a record *without* -all, or with entries like ?comcast.net, I can 
see how a domain could well get blacklisted.
Doug:

>Elvey:
>  
>
>>On 9/21/2004 11:57 AM, Douglas Otis sent forth electrons to convey:
>>    
>>
>>>On Mon, 2004-09-20 at 18:50, Matthew Elvey wrote:  
>>>      
>>>
>>>>On 9/20/2004 5:21 PM, Douglas Otis sent forth electrons to convey:
>>>>        
>>>>
>>>>>On Mon, 2004-09-20 at 16:33, Matthew Elvey wrote:
>>>>>
>>>>>          
>>>>>
>>>>>>Here's the idea in a nutshell: CSV makes use of extant SPF records
>>>>>>which already list tens of thousands of domains that are authorized
>>>>>>for use in HELO.
>>>>>>
>>>>>>Who supports/opposes this change?   
>>>>>>
>>>>>>            
>>>>>>
>>>>>Ney.
>>>>>
>>>>>This is a repeat of an older debate.      
>>>>>          
>>>>>
>>>>No, I'm making a different suggestion.  Please read the whole post!
>>>>I'm eliminating some or all of the records that you mention having a 
>>>>problem with below.
>>>>
>>>>I should have stated one thing clearly: only +type components of
>>>>records would be relevant; ~type and ?type would be ignored.   
>>>>        
>>>>
>>>As I said, this will allow the use of other record types to spoof the
>>>EHLO name.  
>>>      
>>>
>>I claim this is impossible.  Please provide an example of this (using a 
>>record of the kind that my proposal proposes using).
>>    
>>
>
>The label used to select the SPF record is normally based upon the
>mailbox domain to select a full set of outbound MTAs.  The EHLO name can
>be made to match any such mailbox domain provided one of the machines is
>permitted in this SPF record set.  This would be bad.
>  
>
I asked for an example.  I see no example here.  I can't extrapolate 
from what you have said to come up with an example, either.
Perhaps you're avoiding providing one.

>  
>
>>>The SPF type of record will normally be across an entire
>>>array of providers and not for a single host.  
>>>      
>>>
>>I don't see how this is possible using a record of the kind that my 
>>proposal proposes using. 
>>+include:comcast.net is not allowed, for example! 
>>+ptr isn't allowed either (we don't want to allow the likes of 
>>dialup-pool.234.234.comcast.net...)
>>    
>>
>
>One, you want to use existing SPF records that were not intended to
>provide the narrow selection of machines administered by the MTA
>operators.  Two, there is no means to restrict this list after the fact.
>  
>
1)Sort of. 
2)Nonsense. We ignore records or record components that don't meet our 
rules.
Would you argue that there is no means to restrict a CSV "Client SMTP 
Authorization SRV Record" from having illegal values (e.g. a Weight of 8)? 

>  
>
>>>One compromised system  within this vast region can then utilize one
>>>of these records to spoof the EHLO name then.  If reputations are
>>>based upon the MTA name and not the mailbox domain, then protecting
>>>the MTA name would be much more important.  It MUST not be possible
>>>to mix these records out of this concern.
>>>      
>>>
>>I don't believe my proposal does this.  
>><snippage>
>>    
>>
>
>Your approach was to prune the record set used just for the EHLO
>domain.  
>
I don't think so.  It's not clear what you mean by that, so I'm not 
sure, but your sentence doesn't make sense to me; I don't know what 
you're trying to say.

>That pruning can not differentiate between machines within a
>delegated domain or machines within the administered domain. This would
>be bad.
>  
>
I don't see where I'm saying something from which one could conclude 
that a record for aol.com would be non-differentiable from one for 
dhcp234.234.dialup.aol.com.

>  
>
>>>>>The host name used within the EHLO domain will require a separate
>>>>>record anyway, so why not use a record that achieves an answer
>>>>>within a single lookup?       
>>>>>          
>>>>>
>>>>We should, as my post makes clear.  But there are reported to be what, 
>>>>~300,000 SPF records?  Why not use them to the extent that I suggest?
>>>>        
>>>>
>>>These records are for a different purpose, and expose a different set of
>>>machines.  The EHLO record set must be kept narrow in order to serve the
>>>purpose of establishing accountability.  The broad and weak nature of
>>>the identities obtained using SPF/Sender-ID are not useful for this
>>>purpose.  SPF/Sender-ID should be viewed as informative for but a few
>>>exceptions.  
>>>      
>>>
>>Let's nail down what exceptions are appropriate then! 
>>(Again, I'm NOT suggesting using the identities obtained using 
>>SPF/SenderID!)
>>    
>>
>
>The exceptions would be with respect to those domains that feel it is
>okay to close their lists.  
>
That conclusion isn't warranted. It's incorrect.  In fact, I said:
 > [O]nly +type components of records would be relevant; ~type and ?type 
would be ignored.
I didn't say that the entire record containing in, e.g. ~all would be 
ignored, just that the ~all would be ignored.
So your follow-on conclusions are also unwarranted.

>
>  
>
>>Some refinements to my proposal based on stuff hashed out in private email:
>>
>>99% of the time, an MX query will return the A records for all the 
>>servers listed in the MX record as add'l records, all in one UDP packet.
>>Let's say that's a requirement for our purposes, where there's a +MX in 
>>the SPF record.
>>
>>"+a +mx -all" would
>>need 2 more DNS queries to resolve (unless a ALL query was done, which
>>is likely a bad idea). I think it's reasonable to accomodate a bit more
>>than 1 add'l DNS query.
>>    
>>
<snippage of rehashed arguments re parsers and DNS that are not applicable>

>>Let's not worry about the <<1% of records where the DNS servers are
>>known to return incomplete lists of Address records. Let's say that's
>>a requirement for our purposes that this not happen.
>>    
>>
>
>Once the IETF has expended their considerable efforts to endorse a
>method that is well considered and robust, I doubt there will be any
>trouble with the adoption of the standard.  The problem of spam is that
>great.  
>
Certainly, if those things are all true, then the following is true as 
well.  Todays events suggest otherwise.

>
>I still insist the SPF record should never be allowed to validate the
>EHLO domain.  It is a different data set for a different purpose.  
>
>  
>
>>Again, the reason for my proposal is not to change or obsolete
>>CSV records, but to make CSV work in some reasonable cases where it
>>can work without them without being significantly detrimental. 
>>    
>>
>
>Sorry, but I fail to see the point in using a TXT record and a parser to
>obtain a list of addresses through a dangerous and expensive set of
>lookups, when it can be done in one lookup safely.  Also where it will
>not accidentally allow other domains to spoof the EHLO identity.  This
>exclusion is needed to establish accountability.  
>  
>
WTF???
I have not suggested a dangerous or expensive set of lookups.
I have not not suggested a scheme that would readily allow other domains 
to spoof the EHLO identity.
I even asked you to provide an example disproving this and you were 
unable to.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 22 Sep 2004 20:44:21 -0700

On Wed, 2004-09-22 at 17:16, Matthew Elvey wrote:

The goals were obtainable, but obviously not in the time frame alloted. 
Perhaps diligently expressing concerns with various aspects of using
script within DNS, I deserve a fair amount of the blame for this
failure.  Some still see this as a wonderful innovation however.

When submitting CSV to the graybeards, DNS security was a primary
concern and they requested ensuring a random port was an added security
consideration.  A technical review was not something SPF/Sender-ID
advocates desired.  Not wanting to point out problems without offering
solutions was the motivation for creating the MPR draft.

Recognizing where a suite of protocols are weak and working on these
problems seems more fundamental than creating new features or complex
impediments when knowing every chink will be exploited.  These concerns
seem to pale when compared to promises from a large company destine to
change the landscape.  It is also ironic, as this type of amorphous
scripting in mail has largely caused the current situation.  Although
the goals were relatively well defined, there was still an ongoing
debate whether this was actually to prevent spam, spoofing, phishing or
whatever seemed to "fit" the solution touted. 

SMTP is a well crafted battle-scarred solution with a few odd bits
broken.  The EHLO name, acting as a type of post-mark is an obvious
example of something broken ever since machines used more IP addresses
than fit in a DNS query.  I know by being outspoken, this has been a
disappoint to Dave Crocker.  Both Dave and John Levine deserve a great
deal of credit for having a great deal of understanding in both the
inter-operation of the protocols and the IETF.

And now more of the same...

> Huh?  The question is about the record given, which has none of these 

There is a good overview here.
http://www.securityfocus.com/guest/17905

> not vulnerable to a poisoned cache?

By limiting the mechanism to a single DNS lookup to a single DNS server,
the exposure is much less.  The goal and results are the same, the
structure of the lookups are different.

For what it is worth, SPF "requires" more than a single record be read
perhaps from many different DNS servers.  This opens a sizable can of
worms.  This creates a setup for an attack, especially when needing a
parser to process the records.  A "safe" record is thus not as safe
owning to this.  Yes, the simple record in your example itself would not
have been useful for such an exploit.  The danger lies in the general
requirement to explore many different domains to resolve an address list
being compiled.  This problem vanishes had the list been of names rather
than addresses.

> see how a domain could well get blacklisted.

Few large organizations would wish to deal with the results of full
fledged SPF and closed records.
 
<snip>
> Perhaps you're avoiding providing one.

Example: Mailbox.tld has SPF records that define the entire address
space for three of their providers where they outsource some of their
mail, and their own.  I contend reputation should be based upon what you
have control over.  That would mean it would not be to your advantage to
include the machines of these other providers in a reputation
assessment.  

mailbox.dom spf cidr isp1, cidr isp2, cidr isp3, cidr for self.

ehlo.dom spf cidr for self

A compromised host in one of the ISPs or even perhaps some clever shell
program issues EHLO with mailbox.dom rather than the intended ehlo.dom.

The advantages of using this common DNS script structure vanish when you
wish to limit your exposure for EHLO reputation assessments.

<snip>
> 1) Sort of. 
> 2) Nonsense. We ignore records or record components that don't meet our 
>    rules.

The rules that accept only closed SPF components still do not achieve a
goal of assessing only the administrator accountable.

<snip>
> sure, but your sentence doesn't make sense to me; I don't know what 

Just removing open elements will not achieve the desired goal as it does
not provide the same set.

> dhcp234.234.dialup.aol.com.

SPF does not have the concept of administrative versus authorized. 
There is nothing in the syntax that would allow the differentiation.  In
addition, the EHLO name can express any label to select any record.

> well.  Todays events suggest otherwise.

Today is not a stellar day.

<snip>
> I have not suggested a dangerous or expensive set of lookups.

It is my opinion these DNS scripts are dangerous from the standpoint of
both security and network integrity.

> to spoof the EHLO identity.

By attempting to reuse the same SPF records for both EHLO validation and
the mail channel authorization, this exposes the EHLO reputation to a
larger set of MTA servers.  Labels to these records is not a means to
prevent their use for either purpose.

> I even asked you to provide an example disproving this and you were 

The line from Cool Hand Luke comes to mind.  It is not because I have
not tried.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 23 Sep 2004 01:18:10 -0400

Douglas,

I will be among the first to implement a solution that make sense.  In
regards to your CSV,  I commend you for excellent written proposals,
however,  I offer the following reasons for why they have an element that
prohibit consideration for implementation.

CSV is a solution based on two methods: CSA vs. DNA.  I understand all the
arguments for your design, however, I don't think you (among others) have
completely understood the deployment and real operations paradigm that makes
CSV conflictive:

First, this applies to all proposals.  The EHLO/MAIL FROM validation is
useless if RCPT TO is invalid.  We already covered this in our emails a few
months back.   I believe I concluded that it should be mentioned in the
specs.

Second,  it is possible to use CSA only for True Negatives.

What are true negatives?.

Here is my extended terminology for establishing the level of trust in the
email arena:

    False Positives - a Pass that was deemed incorrect upon inspection
    True Positives - a Pass that was deemed correct upon inspection
    False Negative - a Reject that was deemed incorrect upon inspection
    True Negative - a Reject that was deemed correct upon inspection

For example:

A EHLO check that results in a REJECTION is a 100% Trusted result.  This can
be fundamentally proven with local domain EHLO checks, i.e.,  An anonymous
IP trying to use your own domain(s) for the EHLO command is an easy spoof
check.

However, an EHLO check that results with a PASS is not a 100% trusted result
and needs further scrutiny.

This is where you use DNA as a well to check the trust of the result. What I
am saying, you only need to do this for a PASS, not a rejection.   What this
means is that your lookup method needs to take into  account this overhead
reduction concept.   Currently, the lookup says to do DNA first, then CSA.
I say CSA first because .....

Third,  DNA is too exclusive.

CSV will not get adopted unless it has ready DNA sites. The problem I have
is how to offer it to customers from a marketing standpoint.   We can't make
a claim for "new anti-spam technology using CSV" with a footnote that says
"requires double A batteries (DNA) in order to work."   If they are only 1
DNA site (MAPS for example), then this will critical some issues that need
to get worked out.  So at this point in time,  CSV is put on the back
burner.

I think overall, it will continue to have this DNA stigma.  But I think we
can use CSA by itself.  The same applies to SPF for EHLO "True Negatives"
checks.   But SPF suffers from its relaxed provisions.  SPF HELO checks can
only be TRUE or FALSE, not soft or neutral.  It is not logical.

Sincerely,

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office

----- Original Message -----
From: "Douglas Otis" <[email-masked]>
To: "Matthew Elvey" <[email-masked]>
Cc: "MXCOMP" <[email-masked]>; "John Leslie" <[email-masked]>
Sent: Wednesday, September 22, 2004 11:44 PM
Subject: WG to close ; Re: Make CSV backwards compatible with SPF? (new
revisions)

---

From: Matthew Elvey <[email-masked]>
Date: Thu, 23 Sep 2004 00:15:12 -0700

Aha!  I found the post with the relevant stats. 
They're from March, though.  Also, my recollection was off - domains 
using the ten most popular SPF records included only 1/2 of the total 
domains with records.
http://www.imc.org/ietf-mxcomp/mail-archive/msg00644.html  Something 
reasonably recent would be great.

Anyway, let's consider the top ten (which I've reordered a bit) from wayne:

1  1097 v=spf1 mx -all 
3   463 v=spf1 a mx ptr -all 
4   429 v=spf1 a mx -all 
9   131 v=spf1 a mx ?all 
6   306 v=spf1 a -all 
The above would generally take 1-3 UDP DNS queries to resolve. 
 
5   325 v=spf1 -all 
7   171 v=spf1 +exists:CL.%{i}.FR.%{s}.HE.%{h}.null.spf.example.com -all 
8   131 v=spf1 include:example.org ~all 
10  130 v=spf1 ?all 
These are equivalent to the null set, for the purposes of my proposal.

2   804 v=spf1 ip4:a.b.c.d/32 ip4:a.b.c.d/32 a ptr mx -all 
This is probably no longer in the top ten. 

On 9/22/2004 8:44 PM, Douglas Otis sent forth electrons to convey:

>>problems. (  foo.dom.    IN    TXT      "v=spf1 mx -all" )
>>
>
Yes, a good refresher.  Anyway it leads me to believe that the record 
only suffers from a problem that also afflicts CSV and that a good bind9 
or djbdns config can handle.

>the exposure is much less.  
>
Ok, it is a little less.  The risk is also low to start with. (Birthday 
attacks aren't common, AFAIK; I've never logged one.)  It's even lower 
to nonexistent given recent/patched/secure DNS software and systems 
(e.g. a split-split configuration).

>worms.  
Clearly, I need to better explain my scheme, as it still seems unclear 
to you that what SPF "requires" isn't relevant to my proposal!
Please, can you give up using this as an opportunity to bash SPF?  It's 
OT. (Note the changed Subject:).

>fledged SPF and closed records.
Doesn't matter; assuming this is true, it doesn't hurt my proposal.

>include the machines of these other providers in a reputation
Ah, I did say ip4 (and therefore CIDR ranges) might be OK.
(I did suggest subsequently in mail to John Leslie that perhaps just 
+ip4:a.b.c.d/32 might be OK, note the /32!)
Perhaps even that isn't a good idea, as

mailbox.dom spf   ip4:[isp1's smtp]/32,ip4:[isp2's smtp]/32,ip4:[isp3's smtp] -all

enables me to inappropriately stake my domain's reputation on the 
ability of ISPs 1-3 to keep their smtp servers from being used to spam.
HOWEVER:  It's already the case that such SPF records are 
inappropriate.  If I don't have high confidence in the ISPs, then the 
appropriate record would be:

mailbox.dom spf   ?ip4:[isp1's smtp]/32, ?ip4:[isp2's smtp]/32, ?ip4:[isp3's smtp] -all
and this record would be equivalent to the null set in my scheme: my proposal ignores ~anything and ?anything.
Similarly, anyone creating a record like 

>mailbox.dom spf cidr isp1, cidr isp2, cidr isp3, cidr for self.
will suffer the consequences of doing something so dumb, if one of the 3 
ISPs seriously fails keep their smtp servers from being used to spam 
using mailbox.dom.
The domain will get blacklisted (in other words, its reputation will 
fall), and the spoofing will stop.

>ehlo.dom spf cidr for self
may also lead to a poor reputation - someone in marketing might decide 
to send a bunch of spam, get zombie-infected, etc., etc.  So CSV-tied 
reputations won't be perfect either; it isn't reasonable to expect them 
to be.  They just need to be reasonably secure.

>program issues EHLO with mailbox.dom rather than the intended ehlo.dom.
Sorry, how is a clever shell program not in one of the ISPs going to get 
away with this? (No BGP hack/bogon/break into mailbox.dom's server 
scenarios, please!)

>goal of assessing only the administrator accountable.
The rules I am refining do achieve that goal. Arguably, they do so 
better than CSV, because they'll work for most domains that haven't 
bothered to set up a CSV record.  Heck, using the SPF 'best guess' may 
be appropriate where there's no SPF or CSV record - the A&R system will 
reflect reality if this guess allows much spam through.

>not provide the same set.
That's not a logical argument.  The ultimate desired goal is to address 
the spam problem.  It may or may not be material to achievement of that 
goal to get "the same set". 

>addition, the EHLO name can express any label to select any record.
a record for aol.com is still differentiable from one for 
dhcp234.234.dialup.aol.com!

>The line from Cool Hand Luke comes to mind.  It is not because I have
You hadn't provided an example.  Now you have.  Though I don't think it 
disproves this, as I argued above.
The example has enabled us to better discuss specifics.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 23 Sep 2004 02:27:15 -0700

On Wed, 2004-09-22 at 22:18, Hector Santos wrote:

<snip>
> CSV is a solution based on two methods: CSA vs. DNA.

CSV is a suite of specifications that also includes DNA. I would expect
DNA to become useful after inroads have been made to help promote the
use of CSV.  I would imagine typical white-listing services together
with rhsbl services would get the ball rolling. 

>   I understand all the arguments for your design, however, I don't
> think you (among others) have completely understood the deployment and
> real operations paradigm that makes CSV conflictive:
> 
> 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.  This alone is a significant advantage from several
perspectives.  The identity obtained from CSV relates directly to those
that administer the MTA and must be held accountable if to curtail
abuse. 

>   We already covered this in our emails a few months back.   I believe
> I concluded that it should be mentioned in the specs.
> 

I have shown in the marid-mpr draft, the results of these lookups
provide the same results over a scope of MAIL FROM, From, or even PRA. 
The basic difference is a deterministic DNS overhead that needs but a
few lookups.

>     True Negative - a Reject that was deemed correct upon inspection

I do not think you understand what it is that CSV provides by going into
these details.  You get the same results with three really major
differences.
  
1) CSV provides the strongest possible identity that DNS allows which
   happens to relate to the MTA administration.

2) The mailbox-domain/mail-channel association can optionally act in the
   role of a gate-keeper without an open-ended association being
   exploited.

3) The overhead is always low and deterministic.  

> and needs further scrutiny.

CSV provides the means to apply this additional scrutiny at the smallest
possible cost by using a simple name list.

> Third,  DNA is too exclusive.

DNA provides for a large market of white-listing services without
requiring a polling process across many to be made.  By no means does
CSV limit what can be used.  The drafts mention any rhsbl can be used. 
Of course rbls can be used as well, but it is my view a rhsbl would
over-ride the rbl.

> "requires double A batteries (DNA) in order to work."

Good point, but but you don't need DNA.  With CSV in place, the ability
to offer comprehensive name based information will change what can be
obtained from these types of services and the relative overhead needed
to maintain this information.  A lower cost of business in this area is
good all around.  It also means having a name that you can confidently
protect.  With Sender-ID and SPF, you must cross your fingers the
service provider you use gets it right, or you suffer.

>    If they are only 1 DNA site (MAPS for example), then this will
> critical some issues that need to get worked out.  So at this point in
> time,  CSV is put on the back burner.

Although they are small at this point, there are other rhsbl.  There are
other service providers that, for the most part, specialize in
white-listing.  CSV is ideal for both dropping the hammer and
white-listing the good guys.  You could not ask for a better tool.  

> only be TRUE or FALSE, not soft or neutral.  It is not logical.

I see CSV and an MPR approach removing one of the major stubbing blocks
found with SPF.  Among several that are all related to the same issue,
leaving the association "open" with SPF is an exploit waiting to
happen.  The CSV MPR method removes that invitation.  I feel like the
guy in the movie Graduate giving advice, but rather than saying
"Plastics", I am saying "Names".  "Names" is the future in DNS.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Thu, 23 Sep 2004 03:39:03 -0700

On Thu, 2004-09-23 at 00:15, Matthew Elvey wrote:
<snip>
> or djbdns config can handle.

I would agree that someone making an effort could protect their DNS
servers, but the risks parsing script in DNS TXT records traipsing from
DNS server to DNS server does not compare to a single lookup of a binary
record.

> (e.g. a split-split configuration).

This is entering a new territory where DNS is used to authorize
transactions with a cost incentive to defeat these protections.  Yes,
one could use carefully configured DNS servers to minimize this risk. 
This should not overlook the fact this risk was not necessary however.

> OT. (Note the changed Subject:).

Using SPF records is not relevant to what is required of SPF?

If SPF was limited to CIDR notation and the MX record, then the value of
SPF would increase significantly as a white-listing tool.  Much of the
label construction macros and exists syntax reduce SPF's value and will
likely serve to obfuscate a ploy that hides zombies.

> > mailbox.dom spf cidr isp1, cidr isp2, cidr isp3, cidr for self.

What you seem to miss is that SPF does not differentiate between
authorization and administration.  There is no way to know the
relationship of a record in another domain.  The cost of doing business
in this area is based in no small part on getting this right.  I see no
reason to blur the distinction nor do I think the motive for using SPF
records for this purpose is well founded.  If the MTA is not willing to
provide a significantly strong identifier, it does not make sense to
start guessing what is meant by the SPF records.  The fall back would be
using the address.  There can be no implied contract where a domain
becomes accountable for the actions of others trusted to send their
mail.

A provider lax in their security should not be allowed to hide behind
their customer's domains.  Should the provider wish to force the
customer to accept this risk, they can ask to have the customer setup a
CSV-CSA record that enables their servers.  You do not want this
accountability to be implied as you suggest.  

> [mailbox.dom] will suffer the consequences of doing something so dumb,
> if one of the 3 ISPs seriously fails keep their smtp servers from
> being used to spam using mailbox.dom. The domain will get blacklisted
> (in other words, its reputation will fall), and the spoofing will
> stop.

SPF requires the addresses of the entire mail channel.  It is odd that
you would call that dumb.  

> to be.  They just need to be reasonably secure.

You have missed the point of the example.  Attempting to use SPF records
for the dual purpose of creating an address list for the entire mail
channel versus an address list for just the MTA are not protected by way
of the label.  

> away with this? (No BGP hack/bogon/break into mailbox.dom's server 

I said IN one of the ISPs.  You are leaving your reputation exposed by
allowing the EHLO domain to reference an SPF record.  A CSV-CSA record
has but one purpose and is of a much more limited scope.

<snip>
> reflect reality if this guess allows much spam through.

I would hope it never comes to groping through various TXT script
records looking for a clue.  I understand what you are attempting, but
there are risks getting this wrong.  It is not worth the risk.

<snip>
> goal to get "the same set".

There are significant liabilities getting this wrong.    

> dhcp234.234.dialup.aol.com!

But either label may appear within the EHLO response.  You want a label
that can only be used for the single purpose of indicating the
administration of the MTA.  From this information, it is a small matter
to establish the mailbox-domain/mail-channel association.  The
mailbox-domain is too weak of an identifier for assessing reputations
however.  

> You hadn't provided an example.  Now you have.  Though I don't think
> it disproves this, as I argued above. The example has enabled us to
> better discuss specifics. 

Yes.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Thu, 23 Sep 2004 07:50:43 -0700

>  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.  

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 EHLO/MAIL FROM validation is
>  subsequent lookups.  

Invalid Rcpt-to?  I suspect that was meant to refer to RFC2821.mailfrom. 

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.

d/
--
Dave Crocker  <mailto:dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking  <http://brandenburg.com>

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 23 Sep 2004 12:03:17 -0400

Douglas Otis <[email-masked]> wrote:
> A technical review was not something SPF/Sender-ID advocates
> desired.

  In professional fora, it is entirely inappropriate to make
assertions about other people's desires, capabilities, and the like.

> broken.

  It does not warrant calling an infrastructure with a 30-year history
'broken'.

  Alan DeKok.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 23 Sep 2004 09:45:00 -0700

> Invalid Rcpt-to?  I suspect that was meant to refer to RFC2821.mailfrom. 

Hector was describing a decision tree where, of course, there would be
no point checking beyond the obvious.  The message will be rejected due
to the bad recipient. 

> per-message.  MailFrom validation mechanisms pertain to the SENDER OF 

Sorry, this is my fault for not being explicit with these references. 
CSV only validates the operator of the MTA.  With this operator name
established, it allows a safe construction of a name based relationship
of the mailbox-domain association with a mail channel.  This can be
something as simple as a name list.

>From the standpoint of a reputation service, this information is of
little use, but for those wishing to improve operations of a mail
filter, as I think Hector was describing, such information is helpful. 
This type of enhancement is what SPF et al aspires to achieve.  I was
simply attempting to point out some of the additional advantages CSV
offered to help achieve their goal safely.  There should be a symbolic
relationship achieving these two goals.

CSV does not do MailFrom, From, or PRA validation.  CSV simply makes
MailFrom, From or PRA validation safer. 

> entirely different benefits.

I can not agree more.  

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Thu, 23 Sep 2004 10:37:11 -0700

> assertions about other people's desires, capabilities, and the like.

You are right.  You were willing to engage in these discussions and I
should not have made such a generalization.  Sorry, my frustration was
showing in this statement.

>   It does not warrant calling an infrastructure with a 30-year history

I don't think this sentence was describing SMTP as broken in a broad
sense, meaning it does not work.  There are aspects within SMTP that are
broken.  It is safe to describe excusing an authentication failure of
the EHLO name as broken.  I view this piece of information is analogous
to the post-mark on a letter, as it tells you where the message was
sorted for delivery.  Currently this information is often bogus owing to
RFC2821 permissions.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 23 Sep 2004 17:53:46 -0400

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: "MXCOMP" <[email-masked]>
Sent: Thursday, September 23, 2004 10:50 AM
Subject: Re: WG to close ; Re: Make CSV backwards compatible with SPF? (new
revisions)

> The assertion that there is a "versus" between CSA and DNA is quite

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.

> 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.

> 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.

> 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

---

From: Douglas Otis <[email-masked]>
Date: Thu, 23 Sep 2004 18:00:37 -0700

On Thu, 2004-09-23 at 14:53, Hector Santos wrote:
> On Thu, 2004-09-23 at 10:50, "Dave Crocker" <[email-masked]> wrote: 
>

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.

> practical operations.  The "parts" of the product have conflicts as it fits

I wonder how many things would fall into that category.

> > > >  The EHLO/MAIL FROM validation is useless if RCPT TO is invalid.
> > >

I understand what you are saying, but I don't see how this relates to a
comparison of differing techniques.

> 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.

> 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.

> performance enhancement and overhead reduction.  We are probably among the
> first, if the only product in the market to have implemented this
> recommendation.
> 
> mode of anti-spam operation.
> 

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

---

From: Tony Finch <[email-masked]>
Date: Fri, 24 Sep 2004 13:06:55 +0100

On Thu, 23 Sep 2004, Hector Santos wrote:
>
> We are probably among the first, if the the only product in the market
> to have implemented this recommendation.

Exim has always worked in this way, i.e. accept the MAIL FROM command
unconditionally and perform all the checks after RCPT TO. The order in
which the checks are performed is immaterial except from the efficiency
point of view.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
LOUGH FOYLE TO CARLINGFORD LOUGH: NORTHWEST 4 BACKING WEST OR SOUTHWEST 4 OR 5
LATER IN DAY. FAIR DURING DAY, RAIN TONIGHT. GOOD BECOMING MODERATE. SLIGHT OR
MODERATE.

---

From: [email-masked] (Wietse Venema)
Date: Fri, 24 Sep 2004 12:26:57 -0400 (EDT)

> first, if the the only product in the market to have implemented this

The Postfix MTA does this by default since 19990510 (May 10, 1999),
according to the day-to-day log.

	Wietse

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 24 Sep 2004 13:37:42 -0400

Great.  Thanks for the feedback.

What sort of 2821.MailFrom validation was PostFIX doing back in 99?

So we have:

Exim SMTP server
PostFix SMTP server
WIldcat! SMTP server

all doing MAIL FROM delayed validation.  How about SendMail?

Sincerely,

Hector Santos, CTO

----- Original Message -----
From: "Wietse Venema" <[email-masked]>
To: <[email-masked]>
Sent: Friday, September 24, 2004 12:26 PM
Subject: Re: WG to close ; Re: Make CSV backwards compatible with SPF? (new
revisions)

---

From: Graeme Leith <[email-masked]>
Date: Fri, 24 Sep 2004 19:42:03 +0100

> all doing MAIL FROM delayed validation.  How about SendMail?

Sendmail does it if the delay_checks feature is enabled. I don't think
it's enabled by default.

---

From: Rand Wacker <[email-masked]>
Date: Fri, 24 Sep 2004 12:17:33 -0700 (PDT)

According to internal records here, it was in sendmail 8.10, released
3/1/00.

-Rand

---

From: John Leslie <[email-masked]>
Date: Sat, 25 Sep 2004 15:43:12 -0400

> 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.)

> 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.

> 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

   We are not trying to "implement a total product": we're trying to
write a standard.

> The entities 2821.EHLO/HELO, 2821.MAILFROM, including 2821.RCPTTO are
> SMTP transport parameters and are all involved in the total equation

   "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

   "Today's" world -- yes. Tomorrow's world -- who knows?

   The standard _cannot_ only be for today's world.

--
John Leslie <[email-masked]>

---

From: Matthew Elvey <[email-masked]>
Date: Tue, 28 Sep 2004 21:10:51 -0700

On 9/23/2004 12:15 AM, Matthew Elvey sent forth electrons to convey:

 >
 > Aha!  I found the post with the relevant stats. They're from March, 
though.  Also, my recollection was off - domains using the ten most 
popular SPF records included only 1/2 of the total domains with records.
 ><misformatted mess>

Arrgh - here's that without the rewrapping:

Columns are:
Popularity rank of such records; # of such records; record value.

1  1097 v=spf1 mx -all

5   325 v=spf1 -all

> DNS server to DNS server does not compare to a single lookup of a binary
I got that the first time you said it.
Matching to a fixed set of, say a dozen allowed strings does not make a
script.
That would allow a large fraction of SPF records to be used for the
purposes of my proposal.

> This should not overlook the fact this risk was not necessary however.

No there are already reasonable scenarios where there are cost
incentives to defeat these protections.
Phishing, for example - if http://www.marktwainbank.com points to a
phisher's site.
> likely serve to obfuscate a ploy that hides zombies.

So therefore you'd like to not use useful information that might be
found in SPF records, just because it might be seen as legitimizing the 
components of SFP records that you feel are unhelpful to the effort.

> I [DO NOT] think the motive for using SPF
> start guessing what is meant by the SPF records.  
I argue that it does make sense to do so, and can be done safely.

> The fall back would be
> using the address.  
The IP address?  Sure, that's an option.  (I note that RBL entries in a 
sense are MARID - they indicate MAPS' opinion as to whether a MTAs 
should be Authorized by MAPS' users to transmit mail to them, expressed 
as Records In the Dns.)

 > There can be no implied contract where a domain
<Insert previously provided argument that this is not what I'm asserting...>
> accountability to be implied as you suggest.  
I DO NOT SUGGEST THIS. WTF?  How many times do I have to say it?
> you would call that dumb.  
No, you still don't get it.  You ignore or don't understand the 
difference between + and ? in an SPF1 record, as defined in the I-D / 
explained a couple paragraphs down.

> there are risks getting this wrong.  It is not worth the risk.

Let's agree to disagree and move on.  (Or at least let's move this 
thread to
<http://mipassoc.org/ietf-clear/>) - Please reply there; I won't post 
further here on this thread.)
> There are significant liabilities getting this wrong.    

Well, duh.  That statement is true whenever one is doing something 
important.  So we proceed thoughtfully and get it right.

> > > SPF does not have the concept of administrative versus authorized. 
I would say it does.
I would say that ? is for servers that are tentatively authorized, and + 
is for servers that are administered by the entity owning the domain.  + 
normally indicates a server that the domain claims is administered 
responsibly; ? indicates a server that it isn't sure is administered 
responsibly, but neverleless does not want to deny the ability to use 
the domain.

> > > There is nothing in the syntax that would allow the differentiation.
See above.
> > >  In
> to establish the mailbox-domain/mail-channel association.  
For many domains this info isn't available.  And until CSV takes off, it 
makes sense to use the available info in a responsible manner as I 
propose.  Especially if the pressure to publish SPF records continues to 
increase.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 29 Sep 2004 22:53:39 -0700

> The above would generally take 1-3 UDP DNS queries to resolve.

This would take a minimum of 2 DNS lookups and require a script parser
which entails its own risks. Your goal of being able to use existing SPF
records overlooks the very important point SPF does not identify the
administrator of the mail transfer agent.  These SPF records are only to
authorize the sending of messages for specific mailbox domains. These
SPF records may entail addresses beyond the control the administrator of
the mailbox domain.  It is pointless to make proclamations regarding the
significance of the "+", the range of a label, or the scope of CIDR
notation and the mailbox domain administrator's implied acceptance of
liabilities.  You are the one guessing what is implied by the addresses.
You are the one alleging this implied agreement in supplying these
addresses.  You are the one that will take the full brunt of being
wrong.  At best, it remains a guess what is being declared by the
addresses.

SPF does not do this better. SPF does not do this in a safer way.  SPF
does not do this in a more expedient way.  These examples of SPF records
do nothing that can not already be assumed and do nothing to overcome
the reason this approach failed with SMTP, and why there is an
exception.         

> These are equivalent to the null set, for the purposes of my proposal.

What is the point excluding an "include" but not a CIDR address?  What
is the point suggesting the shorthand "mx" and "a" notation offers any
additional benefit. 

> On Thu, 23 Sep 2004 03:39:03 -0700, "Douglas Otis" wrote:
> script. That would allow a large fraction of SPF records to be used
> for the purposes of my proposal.

The translation of a set of textual constructs with specific syntax
constitutes script in my book.  Using a name list based upon the results
of CSV allows for both a safe and simple scheme that accomplishes the
same ends as SPF, but without having to express a single address.  No
addresses are entered for CSV, and no addresses would need to be entered
to define the mail channel for a mailbox domain using a name list. 
None.

There would be no need to daisy-chain new headers to connect MailFrom to
MailFrom either.  The Received headers logging the authenticated EHLO
information actually provides more reliable information without changing
a single element of SMTP.  All that is needed is CSV and a name list. 
This would allow anyone to know when the message was possibly being
spoofed without inviting spoofing and still allow mail to be accepted
from outside the mail channel. 

> components of SFP records that you feel are unhelpful to the effort.

You obviously do not understand the significant risk when making these
types of guesses or alleging acceptance of accountability. 

> > > and this record would be equivalent to the null set in my scheme:
> > > my proposal ignores ~anything and ?anything.

What happens when the scheme can not be defended beyond being used to
sort mail?  I doubt any reputation service would last very long making
these guesses and allegations.

> > The fall back would be using the address.
>   

The mechanism used for the reputation service does not need to be based
upon DNS.  But the identity does need to be as strongly authenticated as
the IP address.

> > There can be no implied contract where a domain becomes accountable
> > for the actions of others trusted to send their mail.
>

Ah, but it is what you are asserting. : ) 

> I DO NOT SUGGEST THIS. WTF?  How many times do I have to say it?

You can attempt to reduce the scope of the SPF records by tossing out
those elements that appear to be under different administrators.  How
does this help?  When you create a "maybe" condition resulting from a
culling of the information, who is at fault either way?  This scheme
becomes damned by the gray.  CSV is purely black and white.  Why add
uncertainty and risk to a mechanism?
 
> > mailbox.dom spf   ip4:[isp1's smtp]/32,ip4:[isp2'ssmtp]/32,ip4:[isp3's smtp] -all
>
> not this:
> > mailbox.dom spf   ?ip4:[isp1's smtp]/32, ?ip4:[isp2's smtp]/32,?ip4:[isp3's smtp] -all

If one of the goals is to still allow mail to enter outside the mail
channel, why would that be dumb?  Some would rather trade reliable
delivery and a signature for this "must fit" approach.  At least using a
name list still allows a safe way to note when a message is outside the
mail channel without inviting a world of spoofers taking a ride on your
reputation.

> I would say it does. I would say that ? is for servers that are
> tentatively authorized, and + is for servers that are administered by
> the entity owning the domain.  + normally indicates a server that the
> domain claims is administered responsibly; ? indicates a server that
> it isn't sure is administered responsibly, but never [the] less does
> not want to deny the ability to use the domain.

You are making assumptions how this syntax can be applied. Obviously the
manner of application is not under the control of the sender.  The
sender will be obliged to use whatever it takes to achieve their goal of
having mail accepted.  I do not see how the recipient can infer levels
of accountability for the mailbox domain administrator.  Do they get a
free pass when they declare their SPF records with a different domain
name than the mailbox domain, or in the case of CSV, a different HELO
name?  Reusing SPF records allows EHLO spoofing to use these records in
unintended ways.  

> > > > In addition, the EHLO name can express any label to select any
> > > > record.
> > >   

Once an authenticated HELO name is made visible to the recipient as a
type of postmark, there will be plenty of motivation to publish these
CSV records to earn greater trust.  Name based reputation will also
enable significant protection from filtering.  All of this while making
fewer DNS record lookups. : )

-Doug

---

From: "Matthew Elvey" <[email-masked]>
Date: Thu, 30 Sep 2004 00:03:30 -0700

On Wed, 29 Sep 2004 22:53:39 -0700, "Douglas Otis" :

made a large number of false statements and provided no new logic, but
rehashed a bunch of old arguments that previous posts already address.

I trust that folks reading the thread (if there are any) can make their
own evaluation as to whether this proposal makes sense.
I see only repeat performances of the exact same arguments if I continue
to argue.

Doug also failed to move the thread, which I requested, as it was
appropriate. 

What is to say here has been said.

Matthew said:
> > further here on this thread [assuming you do respect that request].)