Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

[Dave Crocker <[e-mail]>]

> Quite apart from the DNSSEC example that Patrik sent, underscore
> labels also cause problems and confusion when aliases are involved.
> The alias stuff is a corner case, of course, but it's still a basic
> problem with the approach of specifying policy for a target name at a
> different name than the target itself.  This trade-off might be a
> legitimate one (I certainly think it's preferable to the strategy SPF
> adopted, of stepping all over the TXT RRTYPE at a given name), but it
> won't do to dismiss the problem with a point-and-laugh argument.


Use of underscore names does impose some limitations.  Occasionally 
those limitations are noteworthy for real-world operations, but 
experience across a range of applications so far has not created any 
show-stoppers.

One of the more serious problems about using the underscore construct is 
that arguments against it sometimes are based on an insistence for 
pure-and-complete original DNS capabilities, rather than attending to 
the real-world utility.  It would be nice to have the construct impose 
no additional constraints, but 'nice' isn't the same as 'necessary', 
when evaluating pragmatic trade-offs.

In other words, the specific technical limitations being noted are 
unfortunate but (so far) not serious.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net