Thanks Viktor for the additional feedback. Trying to close out on the HTTPS fetch timeout issue. Do you have any additional feedback to Dan's question?
Reposting Dan's comments and question. Ah, thanks for explaining the Postfix bit. It's a fair point about determining who is out of spec. Like I said, though, it wasn't clear to me what is generally done in such specs; some (e.g. 2821) seem to specify specific values, whereas others (821, AFAICT) do not. I agree with the point (which I think you and Alexey are suggesting) that in the MTA STS case, a timeout on the HTTPS connection has a sort of cascading impact (i.e. the recipient domain now cannot assume the sender actually has the policy if the recipient was not reliably serving it, etc) whereas in some other cases (e.g. HTTP by itself) the connection timeout manifests in a user-facing way. So that may be a reason to err on the side of specifying it. http://kb.mozillazine.org/Network.http.connect.timeout makes me think that someone who has previously worked on a browser thought 30s was a reasonable connection timeout (which I suppose doesn't include any additional time post-connect). Libcurl seems to default to no request timeout, though there are some other timeouts for specific things (connects, I guess?), if I read correctly: https://curl.haxx.se/libcurl/c/CURLOPT_TIMEOUT.html. The connect timeout seems to default to 300s (https://curl.haxx.se/libcurl/c/CURLOPT_CONNECTTIMEOUT.html). So given that, 5s seems a bit on the low side to me. But I'm really doing the handwavy thing here. Half a minute to a minute sort of seems roughly reasonable. Thoughts? -----Original Message----- From: Uta [mailto:[email protected]] On Behalf Of Viktor Dukhovni Sent: Tuesday, September 13, 2016 7:07 PM To: [email protected] Subject: Re: [Uta] MTA STS and HTTPS fetch timeouts On Tue, Sep 13, 2016 at 09:43:53AM -0700, [email protected] wrote: > I'm going to start in an unusual place: The validation pseudocode in > Appendix 1. From there I'll go on to other stuff. But I think the > pseudocode, done right, will be enormously helpful to implementors, so > that's going to be my starting point. My repeated admonitions to write up a more detailed state-machine were an attempt to make the same point you're making. The description of the requisite client-side logic is far too sketchy. The description needs to be quite explicit, modulo flexibility on whether failure policy refresh and retries are synchronous (fetch new policy and retry immediately) or asynchronous (schedule policy refresh and defer the mail). Either approach is legitimate. -- Viktor. _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
