[ietf-dkim] Thoughts on latest SSP draft
dotis at mail-abuse.org
Wed Jul 25 12:12:04 PDT 2007
On Jul 25, 2007, at 7:54 AM, Arvel Hathcock wrote:
> Hi all!
> I believe that the algorithm specified in the latest SSP draft
> (section 4.4) is the best compromise possible and that it will
> cover the largest percentage of use cases. However, I agree it's
> not perfect. Algorithm steps #4 and #5 are the problem as there is
> no definitive list of TLDs available and yet these steps call for
> the use of such. As an implementor I'm worried about how I can
> comply with this part of the algorithm. These steps suggest the
> use of a locally maintained or implementation specific TLD list.
> But such lists would necessarily differ from one deployment or
> implementation to another leading to inconsistent application of
> SSP in the wild. This worries me greatly.
> I'd like us to at least consider the possibility of removing the
> steps associated with querying the immediate parent of the domain
> in question (steps #4 and #5). Admittedly, this causes more
> administrative hassles for certain classes of senders but no
> solution to this question will be perfect in all cases.
> I keep coming back to this: some of the brightest people I've ever
> meet are members of this WG yet we are still grappling with this
> issue. I think this points to the fact that maybe we can't solve
> this one and that we should accept that and move forward with an
> even simpler algorithm (by removing these two steps).
> Anyway, I bow to the collective wisdom here of course but I'm
> hoping we can at least discuss this some.
No organization is able to impose changes to SMTP without the general
consent of those creating and using the protocol. Nevertheless, to
deal with an emergence of IPv6, cryptographic assurances offered by
DKIM should prove helpful provided:
1) Common use of multiple signatures is avoided.
2) Per user signatures is avoided.
3) DKIM has an explicit single transaction means to associate SMTP
clients with signing domains.
4) DKIM has an explicit single transaction means to associate
originating email-address domains with signing domains.
(A common mechanism can deal with #3 and #4 and also deal with
multiple originating domains.)
5) Email acceptance is predicated upon the originating email-address
domain publishing an MX record or A record.
At this point in time, it should be rather rare for incoming SMTP
servers to depended upon a AAAA record for locating their servers.
The DKIM WG should push to have A or AAAA record discovery
deprecated. Deprecating address record discovery techniques will
eventually simplify where policy needs to be published. At some
point in the future, not publishing an MX record for the originating
domain might cause a message to be rejected. Either publishing
policy at every A or AAAA record is required, or domain transversal
(even limited transversal) would be otherwise required. Even limited
domain transversal should be avoided.
Points #3 and #4 can be fulfilled by placing a hash label below the
_ssp._domainkey record of the domain being associated.
Query for either MX or A or perhaps ANY record at the originating
domain in question.
When no MX or A is discovered, the message is suspect.
When signed by a third-party domain, query for a
<hash>._ssp._domainkey at the originating domain.
When the hashed SSP record is not found, the signing domain is not
When not authorized or not signed, query for the _ssp._domainkey record.
When no (non-hashed) SSP record is found, there is no policy for the
When there is a policy for the domain, and it is strict but the
message is not signed by either an authorized or first-party domain,
the message is suspect.
The use of explicit authorization is vital:
a) to handle possible replay abuse
b) to handle possible compromised keys
c) to avoid administrative complexities
More information about the ietf-dkim