So, the *motivation* for this was simplification: if you allow 302s, you have to specify a bit more clearly what the behavior is for things like a 302 to a HTTP URI, max redirect depth, etc.
In truth, though, I've never been super happy with the prohibition on 302s, since it seems to make policy delegation (i.e. "My MX points to Microsoft; use their policy as well") easier than having your mail provider also host a policy for you using SNI. I could personally be convinced that we *should* allow 302s. I seem to recall Binu felt more strongly in the converse, though, so I will let him chime in and maybe correct me. ;) On Sun, Aug 20, 2017 at 7:17 PM, Viktor Dukhovni <[email protected]> wrote: > > > On Aug 20, 2017, at 1:08 PM, Daniel Margolis <[email protected]> > wrote: > > > > Policies fetched via HTTPS are only valid if the HTTP response code is > 200 (OK). > > HTTP 3xx redirects MUST NOT be followed, and HTTP caching (as specified > in > > RFC7234) MUST NOT be used. > > I forget, is non-support of redirects intended to simplify the policy > retrieval > code at the sending MTA , or is it a security concern? I am all for making > the service accessible to bare-bones HTTPS implementations, and so am not > asking > for redirect support, just wanted to check the motivation... Perhaps the > rationale > should be stated in the draft? > > -- > Viktor. > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
