Re: Make CSV backwards compatible with SPF? (new revisions)

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. 

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" 


On 9/21/2004 11:57 AM, Douglas Otis sent forth electrons to convey:

>
>The great thing about rehabilitating the EHLO name, is that this name is
>provided early in every SMTP session.  The EHLO name is captured within
>the message headers to allow tracing.  There is no need for submitter or
>to invent new mail headers to discern where the message is originating
>with the use of CSV applying the post-mark so to speak.                 
>  
>
Well put.

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

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



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.


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.

The fix in these cases would be make a 'proper' CSV record. 

Also, a pass relying on such records would carry slightly less weight than a pass based on a 
'proper' CSV record.  But let's keep the definition tight enough that the weight be only slightly less.

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.