Dave Crocker wrote:
Jim Fenton wrote:
To the extent that the above is not sufficiently clear:
There is not way to properly enforce or even discover the semantics of
this flag, in the general case of sub-domains. This option needs to
removed or be specified in a way that works.
This does not address the wildcard issue.
(Has the s flag been vetted with DNS experts?)
Not specifically. The s flag doesn't affect the number or nature of DNS
queries at all. All it does is determine whether a parent domain SSP
record, once retrieved, should apply to a child domain. It is analogous
to (but not the same as) the "s" flag in RFC 4871 (section 3.6.1, under
the "t" tag).
The s flag, like its counterpart in RFC 4871, can be used to limit the
effect of the record in which it is contained to only the specific
domain in which it occurs. It was created to allow example.com to
publish SSP without necessarily having it apply to sub.example.com. In
other words, it allows the subdomains to take the default "unknown"
practices without actually publishing a record. I am personally
ambivalent as to whether or not it is needed.
The parent-domain checking is done primarily to ease SSP deployment for
domains having large numbers of hostnames. Without this feature, a
domain needs to publish an SSP record for every label in the domain, so
that it's not possible to trivially bypass SSP by using a hostname as
the domain part of a From address.
Since a sufficiently nested sub-domain will still permit bypassing
SSP, the s flag gives the appearance of extra protection but not the
fact of it.
Presumably you mean the lack of "s" flag, since that flag constrains the
effect of an SSP record not to affect subdomains. In any case, section
4.2 of the draft is quite specific about what records need to obtain, in
your words, "protection".
Perhaps you are referring to the one-level upward lookup for an SSP
record. More on that below.
This mechanism does not address deeply-nested From domains. Either such
domains really do exist (in which case they need SSP records), or they
do not (in which case the domain query will return NXDOMAIN), or there's
a wildcard, in which case a deeply-nested address will probably just
look non-Suspicious.
If this is acceptable for deeply nested domains, why isn't it
acceptable for shallow-nested ones?
It isn't clear which "this" you mean, but I'll assume you mean, "Why
doesn't SSP address deeply-nested From domains, but has a special
mechanism for shallow nested ones?"
As has been much discussed, hostnames can be legally used as domain
names in email because of the fallback to do an A record lookup if the
MX fails. Many domains have thousands of hosts, and therefore if one
wanted to publish SSP for each one (e.g., www.example.com, so that mail
from user(_at_)www(_dot_)example(_dot_)com would be subject to SSP other than
"unknown"),
it would be necessary to publish an SSP record alongside each A record
in the domain. I'm told there's not a scaling problem with this, but
I'm not aware of tools that would help one do this. It's not good if
SSP is vulnerable to this sort of attack until new tools are widely
deployed.
The one-level upward search is a compromise. Earlier versions of the
SSP specification contained multiple levels of upward search, and there
seemed to be wide consensus that "tree walking" of this sort is
harmful. Instead, the current draft limits this to one level (a maximum
of one extra DNS query). The rationale for this is that single level
names are quite common, but multiple level names within a zone (e.g.,
foo.bar.example.com published within the example.com zone and not
bar.example.com) are considerably less commonplace. So the requirement
is that foo.bar will need its own SSP record, but www will not.
Subdomains (as distinct from the isolated foo.bar label) should have
their own SSP records regardless.
The idea here is to solve 90%+ of the problem of having to publish LOTS
of SSP records and without increasing the load on DNS significantly.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html