On Sun, Apr 10, 2016 at 04:19:03PM +0200, Daniel Margolis wrote:
> Right, I was thinking of it the same was as you. If you're using
> smarthosts, you're already not using the email domain's MX, so of course
> you can't use its STS policy, either.
Postfix need not know or care which transport overrides are
"smarthosts" and which are alternate nexhtops negotiated with a
remote peer. The same security mechanisms apply in both cases.
> What we didn't define is whether the STS policy mechanism should be used in
> this case. But does this even make sense?
Yes, it does. You're securing a delivery channel between a sending
relay and a set receiving relays with possible MX indirection.
> STS is fairly closely coupled to
> the notion of a valid set of MXs; in the case of a smarthost setup where
> you've manually configured a relay server, it's a bit hard to see how a
> "per domain, validate MXs this way" kind of policy could be applied. Is it
> the domain of the smarthost?
RFC5321 explains how mail is routed in the absence of MX hosts.
Delivery to a non-MX destination is equivalent to delivery to a
destination with a single preference 0 MX record where owner-domain
an the MX exchange are the same.
If MX records are out of scope (non-MX smarthost, then the MX
pinning of STS is not needed, and the policy only specifies the
use of PKI and reporting addresses). If MX records are used
to select the actual relay, then transport security policy is
the same as with mail that is addressed to the relay domain.
> Obviously you could craft a policy semantic to support this (perhaps by
> making per-host policies explicit), but is it worth the complexity? In the
> static relay case you could conceivably manually encode security policies,
> though maybe that doesn't scale well to some complex setups?
Absense of the STS DNS record that triggers policy acquisition via
HTTPS suffices to cover cases where no policy is desired or published.
However the nexthop is determined, STS and DANE should apply to
secure SMTP traffic to the nexthop. In most case the nexthop
domain and the recipient domain are the same, but this is not
always so.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
