> On Mar 24, 2016, at 12:16 PM, [email protected] wrote:
>
> In addition to the possible difficulty in migrating a domain off
> a server (particularly in a multi-tenant config), we also felt
> that introducing a new SMTP verb might be dramatically more complicated
> than deploying in parallel, because at least the DNS/webpki reporting
> can be added offline without changes to the core MTA.
>
> Was that not a concern in DEEP? Or simply unavoidable?
Implementing a new SMTP verb is easier than parsing new DNS records
or adding an HTTPS stack to a sending MTA.
That said, an out-of-band protocol might possibly be supported via
a mostly "generic" policy lookup interface that allows the sending MTA
to fetch TLS policy for a delivery and report results, while
in-band signalling might require somewhat more mechanism-specific code
in the MTA.
The key difficulty is of course doing policy revocation in-band, it is
not obvious how to do that. If STS is defined more narrowly as a protocol
for sending mail to just the domains "too large to implement DNSSEC" (such
as those of the draft's authors), then the hosting issue goes away, and
in-band signalling works. If STS is to cater to smaller hosted domains,
then signalling that securely signalling that SMTP to one's domain is no
longer secure becomes difficult without a parallel out of band secure
channel.
If STS-enabled SMTP servers were required to be able to disavow support
for a no-longer hosted domain in-band via SMTP, that might work. The
client would have to signal the domain to which it wants to deliver
email before "MAIL FROM", and the server would respond with the policy
for that domain, or an invalidation.
This would mean that the cached data for a domain would include the
most recently seen MX hosts (not just the wildcard patterns), and
that when new MX hosts in DNS don't match any of the cached patterns,
a connection is made the cached ones for the purpose of a policy revocation
check. This sounds a bit tricky... Will the "losing" provider have
proper incentives to make the appropriate configuration changes in a timely
manner?
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
