SPF Archive?, Re: ANNOUNCE: I-D draft-ietf-marid-SPF3-00, etc.

First: Have any of the folks who've done surveys of the DNS for SPF 
records archived the actual records they found?
I hope so; they may turn out to be useful down the road.


On 9/17/2004 3:16 PM, Douglas Otis sent forth electrons to convey:

>On Thu, 2004-09-16 at 21:58, Matthew Elvey wrote:
>
>  
>
>>Comparison of SPF3 and CSV+MPR:
>>    
>>
>
>  
>
>>Of bind, GoDaddy and ZoneEdit, only BIND supports what CSV requires. 
>>Technically, it's inferior, in that its usage of DNS is less efficient 
>>and less standards-based.  MPR also has the cool bit-mapped fields for 
>>explicit protection of 2822.From:, etc.  This could be added to SPF3.
>>    
>>
>
>Are you referring to web-based GUI interfaces for DNS entries to support
>services?  
>
ASPs providing DNS services.  (Same thing said differently?)

>Looking at their documentation, it was not clear that it was
>possible to enter a TXT record either.
>
They support TXT records.

>  I would imagine do-it-yourself
>providers will offer needed interfaces for elements supporting their
>service once it becomes prevalently needed.  CSV is simple enough to
>have it defined without any user intervention other than selecting the
>host.
>  
>
In the case of SPF1, coming up with reasonable data to feed the wizard 
at pobox.com is the main stumbling block.
Given a good result from the wizard and raw access to TXT, it's easy to 
put the former into the latter.
But again, the data required for a good SPF1 record (e.g that doesn't 
have ?0/0) is often difficult to determine.
CSV is simpler, so if raw access to the required RR type is available, 
we'd be good; with a wizard, we'd be great.
It would be a bit of a 'stub' wizard- one or two questions, tops.

>It is not clear what was being compared in this sentence.  I will assume
>you were saying CSV is inferior.  : )
>  
>
Uh, no.   I was saying SPF3 is inferior in certain tecnical respects in 
comparison to CSV+MPR!
It was clearer when it was in context.

>The SRV record is used extensively...  
>
>Use of a TXT record which encodes other
>domains, users, error messages, hostnames, addresses, settings, macros,
>and is extensible will require a forever evolving parser.
>  
>
>With more and more flavors of TXT records employed due to the example
>made by SPF, as well as adopting a practice of using wildcards, any use
>of an extensible text script is not without risk.  Unlike other DNS
>records with content defined by the record type, the TXT record should
>assume opaque text strings.
>  
>
Right; there's a risk-benefit evaluation to me made.  I'm sensing most 
people prefer to take the risk and get the benefit; but I wouldn't call 
it a rough consensus yet.

>Unlike SPF, names are consistently used and do not require the double
>entry of host addresses as SPF may.  The alternative to replicate
>address entry when using SPF, is to use record references and then cause
>subsequent DNS lookups to then obtain the addresses for each reference. 
>SPF is neither more standard or efficient.  The MPR name lists also
>removes the need for subsequent lookups which are the bane of the SPF
>approach.
>  
>
Yes, SPF is neither more standard or efficient, etc.
In SPF3, domains are consistently used, and it's more efficent than 
SPF/SPF1 or SenderID/SPF2.

>The MPR lists, being a separate from the MTA authentication and
>authorization, avoids the problems of "open" lists that invite
>spoofing.  MPR can be deployed with an "open" list as a SHOULD without
>any exploit concerns.  By marking or "coloring" the mail as being
>outside the nominal mail channel, this should offer better consumer
>protection than that achieved with Sender-ID's PRA algorithm yet not
>breaking mail forwarding.
>  
>
This would be so greatly clarified by specific sample M.A.R.I.D. 
illustrating such open lists failing!

>  
>
>>=-=-=-=-=
>>With respect to being able to outright reject forgeries without breaking 
>>forwarding: 
>>With HELO checks + A&R, I can see this becoming reasonable BCP.  Here's how:
>>Forwarders (and mailing list hosts) will be expected to be running 
>>MARID on their MTA.  If they are too lazy to do so, then they will be 
>>found to be forwarding on obvious (to anyone using MARID) forgeries, and 
>>thus their reputations will (justifiably) suffer.  It will probably not 
>>be fair to blame 'em for all spam they forward, but it will be fair to 
>>blame them for forwarding on obvious forgeries. The responsible 
>>forwarders running MARID can be expected to have good HELO reputations.
>>    
>>
>
>Is this in reference to CSV?
>  
>
It's in reference to any MARID scheme relying heavily on HELO, such as 
CSV, or SPF3.




I'd wager you're in agreement.

I put SPF3 up here:
http://elvey.com/it/sieve/draft-ietf-marid-spf3-00.txt
as it's not up at
iietf.org/internet-drafts yet.

To save folks time, I put up
http://asrg.sp.am/wiki?action=history&id=Spf3 .

Folks may want to look at that to see a quick diff showing the
"*Substantive Changes*" between my draft and draft-ietf-marid-prococol-03.