[ietf-dkim] Re: Single Organization TXT Lookup with Multiple TXT
dotis at mail-abuse.org
Sat Jun 2 09:07:07 PDT 2007
On Sat, 2007-06-02 at 10:35 -0400, Hector Santos wrote:
> 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.
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
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.
More information about the ietf-dkim