On Apr 25, 2008, at 12:22 AM, Eliot Lear wrote:
Here's the question I wonder about here: how do we follow as best we
can the principle of least astonishment in this case?
Bad-actors run an overwhelming majority of SMTP clients. Each SMTP
set-up expediency, even under a guise of least astonishment, creates
additional burdens on the Internet. Not only should each domain
seeking SMTP policy protections publish records at each SMTP domain,
each SMTP domain should also publish MX records in conjunction with
the SMTP policy. When an MX record is not published, uninvolved
domains can then be assured recipients of spoofed SMTP messages will
stop at not finding MX records and not climbing up their domain tree
looking for what might become a plethora of various message policies.
After all, the _only_ public message exchange protocol to benefit from
ADSP policy is SMTP. Denials that ADSP is not tightly bound to SMTP
are astonishing. While other public message exchange protocols
_might_ incorporate DKIM, _each_ and _every_ public exchange protocol
requires _separate_ policy assertions to signal when DKIM becomes
fully incorporated. Separate policies for each public exchange
protocol offers the least astonishment and avoids significant
disruptions that can be caused by the ambiguous application of
policy. Publishing policy at each domain holding evidence of
supporting a corresponding public message exchange protocol is not
astonishing. Once such a concept is embraced, policy only needs to
occur in conjunction with the service discovery records. Of course,
expecting negative domain existence to always provide a valid result
would also be astonishing.
ADSP is intended to offer a few phished domains added protections.
Rather than requiring additional steps for each message that crosses
over the transom, require those seeking added protections to carry the
additional burden of publishing policy where protection is being
sought. Domain reputation can only be enforced within the forward DNS
zone. Limited PTR sets in the reverse zone requires forward/reverse
name mismatch be overlooked. A practical means to confirm that a
domain supports the SMTP service is the MX record. MX records should
become the touch-stone for domain reputations and policies.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html