Fwd: Re: [ietf-dkim] 2821bis and AAAA (was: Thoughts on latest SSP draft)

[SM]

This message has been forwarded to the DKIM list.

>Date: Thu, 27 Sep 2007 16:36:04 -0400
>From: John C Klensin <john+smtp at jck.com>
>
>(someone will probably need to forward this to the DKIM list;
>I'm not subscribed to it)
>
>--On Thursday, 27 September, 2007 12:12 -0700 Douglas Otis
><dotis at mail-abuse.org> wrote:
>
> >...
> > In addition to checking for a policy record of some sort, A,
> > AAAA, and MX records must also be queried.  Every message
> > referencing a randomly spoofed domain will thereby lead to a
> > series of expensive DNS transactions.  DNS overhead could be
> > reduced by 2/3 thirds at least by requiring an MX record for
> > acceptance.  This would preclude A or AAAA record for
> > acceptance.  The impact of this change should be limited to
> > message acceptance.
>
>I think you have the cart and horse turned around backward.  If
>(and I'm not going to express an opinion at this point), one
>really needs MX records if DKIM (and its near and distant
>header-signing relatives) are to be supported in a reasonable
>and efficient way, then it would be perfectly sensible to impose
>that requirement on DKIM users.  In other words, one makes
>provision, in the DKIM specs, that,
>
>         (i) if one is going to insert DKIM header records, one
>         MUST have MX records for the appropriate hosts.
>
>         (ii) if one encounters DKIM header records, does an MX
>         lookup, and does not get one or more MX records back,
>         then one SHOULD just give up and treat the DKIM records
>         as trash (whatever that happens to imply).
>
>This makes the "mandatory MX" issue a DKIM (and friends) issue,
>not a requirement that zillions of hosts that do "MX, then
>address" lookups consistent with 2821 (and 1123, and...) change
>what they are doing because of some proposed words in 2821bis
>that change a 20-odd-year-old spec.  Won't happen, whether
>2821bis is changed or not.
>
>#include <some cliche about rocket science>
>
>       john