I wrote: > I have some ideas about a few sentences which could be added to your > draft, which would eliminate most timing issues between any two > compliant implementations. But I'm about to be almost late for a > meeting, so I'll write that part tomorrow or during the weekend.
Here they are: * If the client receives an incomplete 558 reply, the client should process normally any of this reply's subreplies which were received in their entirety, and should process any incomplete or unreceived subreplies as if they had been 451 subreplies. (Rationale: If clients ignored all the subreplies in an incomplete 558 reply, there would be no forward progress if the connection gets broken while the server is in the middle of processing a message with many recipients. Conversely, if clients were expected to process incomplete subreplies, users could be exposed to SMTP reply text which has been truncated. Truncation can change the meaning of text.) * The server should attempt to minimize the time between committing a delivery to safe storage, and sending a subreply to acknowledge that delivery. The server should make an effort to avoid committing a delivery if it can determine that the subreply cannot be sent to the client. (Rationale: This is meant to avoid the RFC 1047 race condition. The method suggested in RFC 1047 (minimize the time between the final "." and the reply, by doing accept-then-bounce) is no longer feasible.) * While receiving a 558 reply, the client must implement a timeout of at least 10 minutes per subreply. It MUST use per- subreply timeouts rather than trying to time the entire 558 reply. This means that the overall timeout is approximately proportional to the number of recipients. (Rationale: I chose 10 minutes because that's the suggested minimum timeout for processing a message body, in the middle of section 4.5.3.2 of RFC 2821. The second and third sentences above are adapted from the first paragraph of that same section of the RFC.) (Discussion: In today's environment, with real messages outnumbered by spam, when you ask a server to accept a message (especially one with many recipients) you are asking that server to perform substantial computation on your behalf. You should at least be willing to allow sufficient time for the computation to be performed!) * While sending a 558 reply, the server should take no more than about 5 minutes to send each subreply. If individual users administer their own filtering software, it would be advisable to use a timeout mechanism to force a decision after 5 minutes. (Rationale: if a user's filter always takes too long, and triggers the client's 10 minute timeout, other users might not ever be able to receive the message.) (Discussion: Of course the server is free to set this internal timeout faster than 5 minutes, and in practice most subreplies will be fast anyway. But the speed is controlled by the server; the client must not timeout any subreply faster than 10 minutes. Note: The appropriate server timeout could be calculated by starting with 10 minutes, subtracting the maximum expected network delay, and subtracting a safety factor. I didn't do that; I just guessed 5 minutes because it's half of 10 minutes. It's probably good enough.) ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
