On Jun 9, 2008, at 9:21 PM, Jim Fenton wrote:
Douglas Otis wrote:
On Jun 9, 2008, at 3:38 PM, Jim Fenton wrote:
Dave Crocker wrote:
So we need to be careful about assuming that any of these tests
are likely to be "free". In fact, one bit of feedback I got was
explicit about these additional tests as costing too much. They
had tried and found they added too much delay.
In view of the fact that there is incremental cost, I would like
to suggest that we change the SHOULD [check MX & A/AAAA] to a
MAY. With that change, I'm happy with the text John proposes.
When the desire is to get the draft completed ASAP, eliminate it
having any domain validity check. When a domain validity checks
becomes MAY, publishers can not be assured of any sub-domain
protections anyway.
Since it apparently isn't clear: I am proposing retaining the
NXDOMAIN domain validity check as a MUST. It is only the MX and A/
AAAA check that I'm proposing be changed from a SHOULD to a MAY.
The situation created by MS Exchange creates a problem where just an
NXDOMAIN check is still problematic. While NXDOMAIN might occur for
any leaked X.400 address or typical "somebody(_at_)something(_dot_)invalid",
NXDOMAIN results might also occur with any proxy SMTP addresses
assigned by MS Exchange. This occurs since MS Exchange assignments
and routing do not depending upon DNS records. Such an NXDOMAIN test
would disrupt messages created by the company where I work, for
example. In addition, unless the test goes one step further to
determine whether a domain appears to support SMTP, this would offer
far less utility in preventing address spoofing. Nor could just an
NXDOMAIN test offer protection for non-SMTP domains.
Domain validity tests will impose systemic changes to SMTP, so any
desire to see evaluation of this process hastened seems wholly ill
advised. Mitigation strategies will be required. Getting an ADSP
draft in place can occur quickly by removing both domain validation
and ADSP sub-domain assertions. Those wishing to reduce From address
spoofing further should propose a separate SMTP related draft that
stipulates a safe algorithm for assessing whether a domain appears to
support SMTP. This separate draft might also recommend that this test
be made prior to issuing other SMTP related transactions, which could
include those supporting DKIM or ADSP as well. The SMTP domain
validation draft should also recommend mitigation strategies for
handling any possible disruption that might be caused by the change.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html