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 [EMAIL PROTECTED] 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
