On Sat, 2007-06-02 at 10:35 -0400, Hector Santos wrote: > Doug, > > If I catch your drift, I will be opposed to any IANA or 3rd party > "registry" concept for SSP. Not sure how that relates to RR vs TXT > records SSP question. > > Anyway, wild card searches is something, IMO, most systems are simply > not going to need. And if required for a larger domain, they simply can > create multiple TXT records.
Hector, Random labels necessitate searching. An MX record can already utilize a wildcard. Mandate that an MX record be available for any email-address domain being signed. Why not? Searching upward from the domain in question may generate a large number queries not controlled by the domain questioned. It is a bit late to demand that DKIM signers MUST have such a record. > This can be solved very simply with a SSP syntax that has multiple text > records concept or one long, with tag or fields or attributes for each > sub-domain, if necessary. Right now, a TXT lookup will return all TXT > records. So all we need is a single organization domain lookup to > obtain all its sub-domain policies. In essences, you are now arguing to have records placed at some base domain below a prefix. When no record is found, recipients then search for this record. Starting from where the bad-actor suggests may involve several transactions before concluding. And when there is no record, where does this stop and perhaps even start? At the domain just below the TLD. If this domain is a SLD as with co.uk, then they will see a storm of traffic serving no purpose. Remember often >90% of email traffic represents bad-actors willing to do whatever it takes. What defense is there from all their recipients doing massive searches? What I am suggesting is a bit different. As this label must have a prefix, why not allow the prefix to associate with another domain via a hash? Check the existence of an MX record when no policy record is found. When policy record lookup fails and the MX record exists (we are at two transactions), a third lookup could be for _dkim-all.<email-address-domain> to determine whether a lack of an association is acceptable. This approach represents the same number of transactions as suggested by Phillip, but also provides a means to curtail a replay-abuse and broken-signature bounce problem. Doing this now ensures at most one additional transaction occurs. This seems well worth it. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
