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/
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: Re: draft-ietf-marid-protocol-03, (continued)
- Re: Re: draft-ietf-marid-protocol-03 - scope questions and comments, Commerco WebMaster
- Re: Re: draft-ietf-marid-protocol-03 - scope questions and comments, Koen Martens
- Re: Re: draft-ietf-marid-protocol-03 - scope questions and comments, Commerco WebMaster
- Re: Re: draft-ietf-marid-protocol-03 - scope questions and comments, Greg Connor
- Re: draft-ietf-marid-protocol-03 - scope questions and comments, Roger Moser
- Re: Re: draft-ietf-marid-protocol-03 - scope questions and comments, william(at)elan.net
- Re: Re: draft-ietf-marid-protocol-03 - scope questions and comments, wayne
- Re: Re: draft-ietf-marid-protocol-03 - scope questions and comments,
Commerco WebMaster <=
- Re: Re: draft-ietf-marid-protocol-03 - scope questions and comments, william(at)elan.net
- Re: Re: draft-ietf-marid-protocol-03, David
- Re: Re: draft-ietf-marid-protocol-03, william(at)elan.net
- Re: draft-ietf-marid-protocol-03, Frank Ellermann
- Re: Re: draft-ietf-marid-protocol-03, Mark Shewmaker
- Re: draft-ietf-marid-protocol-03, Frank Ellermann
- Re: Re: draft-ietf-marid-protocol-03, Tony Finch
- Resent-* (was: draft-ietf-marid-protocol-03), Frank Ellermann
- Re: Resent-*, Graham Murray
- Re: Resent-*, John A. Martin
|
|
|