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

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.