Hi Viktor, On Wed, Apr 06, 2016 at 22:40:40 +0000, Viktor Dukhovni wrote: > * Is it enough for delivery via just the first MX tried to succeed? > Or does the initial delivery need to confirm more than one MX host? > > * Is delivery to a second MX host after failing the first a "success"? > > * How about a site only some of whose MX hosts match the STS policy > constraints?
What about considering STS to be a mechanism that verifies something that should always be true, and just generating a permanent failure if you encounter something that doesn't match that policy? Like a sort of "assertion check" on what you see following the normal processing path. > As STS evolves the requirements may change, but we'd want to nail > down the delivery-agent to STS-agent protocol, so that STS-agents > can be add-ons that evolve largely separately from Postfix, without > requiring new C-code in new Postfix releases to stay current with > the protocol. You could design a protocol that is very similar to the postfix access policy delegation protocol: - Postfix SMTP connects to the chosen next hop and does the handshake - It gives via policy protocol all information that it has about the connection (hostname, IP, TLS information, etc.) - In case something is bad, the policy demon can return "REJECT" with a reason (and initiate reporting by registering the failure in some database). > It may also be helpful to explain that the "domain" for which the > STS client is doing policy lookup is not necessarily the domain > part of the recipient address(es) in the message envelope. While > these are typically the same, in some cases the nexthop domain may > be a "smarthost" relay or a manually configured nexthop for a set > of designated recipient domains. I don't understand this: why would the STS client do a policy lookup not on the recipient address? I understand that you can have a different nexthop specified in your transport map, but why look that up instead of the recipient address domain? > Another one of the things that DANE "gets right", is that TLSA > records are service-endpoint-specific. MTAs may at times be > configured to relay some or all mail via nexthop:port with a port > other than 25. > > The certificate on port 587 (or whatever) may be different than > the one on port 25 and the desired TLS policies may be different > for the different (by port) SMTP services. Maybe you should be able to disable the STS check in those cases where you do some local override? > To avoid deliver pipeline stalls we'd expect the out-of-process > STS delivery agent to reply immediately with no policy when it does > not already have at least an embryonic unvalidated policy cached, > and to schedule a policy fetch in the background. The policy would > only be used and validated on the first delivery *after* it was > already cached locally (as an unvalidated policy). Yes, that's really a problem in the policy-delegation idea. I guess you could return a "DEFER" and thus force the mail to be back in the queue, waiting for the fetching of a current policy to finish? But then you have the problem that postfix is going to retry with another hop... Cheers David _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
