Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

[Douglas Otis <[e-mail]>]

On Wed, 2005-12-14 at 07:06 -0800, william(at)elan.net wrote:
> On Tue, 13 Dec 2005, Douglas Otis wrote:
> 
> You can do setup that involves multiple CNAME and NS redirections
> with DNS and it all could come to those 100 lookups.

Few would expect this to work, nor would that be a _required_ depth. 


> In practice setups do not exist though and neither have I seen any
> serious of SPF records that cause 100 lookups (your tests that setup
> these records on purpose is not good indicator of how administrators 
> enter spf records).

Actually there was case that came close to this limit by an access
provider, but was rewritten into CIDR notation to reduce the number of
records, increasing their chances for error.  At the email
authentication summit in NY, there was a large company that complained
they could still not fit into this large limit.  DNS is well designed to
resolve host names and sub-sets of hosts for a domain.  SPF wants this
to always be a complete set, even for multiple domains.


> Funny how you forget to mention that what is called BATV was invented
> by people working on SPF - at first as advanced version of SRS, which
> was thereafter released as SES [1] and anybody with technical knowledge
> will quickly see that BATV basically implements subset of SES (although
> I agree that is the more useful subset of that proposal).

The idea of tagging the Return-path was not invented by the SPF group.
Something like VERP could be an example.  It would be incorrect to
describe the simplicity of BATV as having a genesis from the SPF group.
RFC2304 could be called the genesis for the idea.  : )

BATV would be the correct choice in my view.  SES attempts the same
everything and the kitchen-sink complexity that could be seen as the
hallmark of SPF, which also makes SPF with its problems an integral
component.

-Doug



_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf