spf-discuss
[Top] [All Lists]

Re: Re: draft-ietf-marid-protocol-03 - scope questions and comments

2004-09-30 11:17:36
Wayne,

Thank you for your post. This is the closest I have gotten to the answer for which I am (and perhaps others may be) looking.

At 09:43 AM 9/30/2004, you wrote:
.. snip ..
I don't understand the point of this.  Section 3.1 of the specifies
quite clearly how to deal with SPF records of different versions.
Basically, if there are records with multiple versions, you are
supposed to use the highest version that the implementation
recognizes, but fall back to the lower versions if appropriate.  So,
if, as in the example above, there are no difference between the SPF
records between version 1, 2 and 3, you would just need to publish the
v=spf1 record.

See: http://www.ietf.org/internet-drafts/draft-mengwong-spf-01.txt

The only question I still have is what constitutes "appropriate"? If I publish a v=spf1 record and it contains something like
"v=spf1 ip4:1.2.3.4 -all"
and then I include an spf2.0 like
"v=spf2.0 ip4:1.2.3.5 <and more here> -all"
should I reasonably expect that the spf1 record will still be looked at in an additive way at even though both records share a common ip4 syntax? Perhaps an easier answer might be to have the consumer application of any spf TXT by necessity be required to look at all versions supplied by the sending domain's DNS server to determine operation and context.

The additive nature of the above seems to violate a part of Section 3.1, but members on this list have already made good points that sometimes spf parameters may have different meanings in their syntax between different spf versions, so logically a top down approach to processing from the most recent version back to the earliest version might be the best course to achieve the results a given publisher of SPF records intended.

In this way SPF adopters will need do the least amount of work in publishing and maintaining the records to achieve their desired results. It is human nature that less work to implement and maintain SPF may result in even greater acceptance for SPF. In other words, in many situations, spf1 is a simple and elegant solution that requires no additional extensions to achieve its purpose, so users of spf1 records should feel comfortable that their efforts to adopt will work now and into the future without constant or further maintenance to accomplish what the publisher intended by their spf1 record (all other things remaining constant).

For example, the owner of DOMAIN.TLD simply publishes a v=spf1 TXT record for DOMAIN.TLD that specifies DOMAIN.TLD does not perform any outgoing email. An MTA receives a message with DOMAIN.TLD in the FROM, so it must *always* recognize this as a case of domain identity theft and must never deliver the message... Even if the receiving MTA in question is aware of and handles SPV v=spf12.

Is the above example a correct presumption on my part? If so, perhaps a large portion of adopters will fit into the current structure and for those others who don't fit yet, spfx.x may become their answer. The message to prospective spf implementors? Don't wait to publish your spf records if you fit the vast case where spf1 can work for you today, your efforts will not be wasted or require additional work to support.


The problem with the current SenderID specs is that this section has
been dropped.  Both Meng and Mark have been quite explicit that they
do *not* want to standardize SPFv1 and do not want to include support
for SPFv1 records in SenderID.  They want to keep SPFv1 records open
for changes that they develop.

-wayne

One other note, I am unfamiliar with the formal process for publishing Internet Drafts, so please excuse my ignorance here, but I noticed that the document http://www.ietf.org/internet-drafts/draft-mengwong-spf-01.txt actually expires today. I don't know what impact that has, if any, as regards the formal status of SPF. From a propaganda perspective, others who might wish to see or cause the demise of SPF might point to that and say, "well spf has died, move along". Can that date somehow be extended or a new document be published to avoid any misperceptions which could conceivably be spread by any parties intent on subverting SPF progress?

Best,

Alan Maitland
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/