"Eric A. Hall" <ehall(_at_)ehsco(_dot_)com> wrote:
There are other problems with reusing SMTP -- the biggest one I can think
of is the excessive number of round-trip times, which imposes significant
latency considerations. Connect->HELO->POLICY-> to a laden serve behind a
slow link in ~Ukraine can be expensive.
It's one more SMTP command/response transaction, but that process
can be shortened. e.g. As a hack, putting a hash of the policy into
the EHLO name. If the recipient recognizes the hash, then the server
knows the policy, can apply it, and SMTP proceeds unchanged. If the
server doesn't recognize the hash, it can respond with a "policy"
request, while simultaneously doing a DNS lookup for the key which
signs that policy.
In that case, the policy exchange imposes a latency once, and then
it can be cached. All that has to go into DNS is a key for signing
policies, and a statement saying "yes, we have an SMTP policy: please
use SMTP extensions to ask for it."
If rogue clients claim association with a domain, they either won't
supply a policy (and thus get rejected, due to the domains published
requirements), or they can supply a non-signed policy (and thus get
rejected), or they can supply the domain's policy, and thus have that
policy applied to them.
Probably the best generalized approach to the "where's the policy" issue
(assumng such a design is taken) is to use a URI syntax, and to define
things like SMTP:host and SMTP:MX:domain as eligible candidates (those
syntaxes would be useful for other things anyway).
Sounds reasonable. That way we can kill two birds with one stone:
DNS will supply information that "our policy is at URI foo", and
that policy can be fetched via HTTP, FTP, or supplied in-line in SMTP,
if there's an "in-line SMTP" URI.
Alan DeKok.